muta...@gmail.com  wrote:   
   > On Thursday, December 1, 2022 at 12:46:25 PM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > - OS hand to run acceptably on small and by modern standard slow   
   > > machines   
   >   
   > Slow should not be a problem for an OS. Applications   
   > should be bottlenecked in the application, not OS calls.   
      
   You write "should".  Toi have this OS must be efficient enough.   
   As an example let me mention Chi-Writer.  This was an editor   
   running under MSDOS on 8086 class machines.  Saving files to   
   floppies were quite slow.  I looked at clock during saving   
   and time to save could be explained by assuming that Chi-Writer   
   wrote 1 sector per disk revolution.  Technically floppy hardware   
   was capable of continiousy writing data giving 9 sectors   
   per revolution on standard (low density) floppies and more   
   for high density ones.  But apparenty Chi-Writer issued   
   an OS call per sector and DOS/BIOS was too slow to immediately   
   write next sector after previous one and had to wait full   
   revolution.  Here blame was shared by DOS/BIOS and Chi-Writer,   
   IIUC it was possible to do full track read/writes using BIOS.   
   But Chi-Writer was not the only program with such a problem.   
   AFAIK this was common problem with MSDOS programs, I just   
   had first hand experience with Chi-Writer.   
      
   To put this into a bit different light, my first own PC was 486.   
   It was pretty fast compared to other machines from the same time.   
   At first I used MSDOS as my OS.  I got DJ GCC so I could do 32-bit   
   programming and avoid 16-bit limitations.  But I noticed that   
   many things were slower than I hoped.  I tried 386BSD and later   
   Linux on this machine.  And many things become much faster.   
      
   And do not be fooled by emulation.  When you run Hercules   
   emulated CPU may be 20 MIPS.  But major part of mainframe   
   is I/O subsytem and using Hercules you are in fact using   
   I/O subsystem of modern OS.  There is some overhead to   
   emulate IBM CKD discs, but compared to overhead for CPU   
   emulation I/O overhead is tiny.  So in Hercules you get   
   excelenet I/O performace.  There is no way that real 20   
   MIPS mainframe could match that.  Similar things applay   
   to Bochs: in Bochs emulated CPU is quite slow while I/O   
   runs with all modern improvements.  There is good chance   
   that program which runs fast enough under Bochs would be   
   dog slow on real hardware, even with faster hardware   
   processor.   
      
   Reiterating: to make your "should" resonably close to   
   truth requires serious work from OS implementer, in   
   particular in area of I/O.   
      
   > > Of course, there is also issue of size of whole enterprise.   
   > > MSDOS class system is approachable by single person, but not   
   > > in a weekend (and probably not in a month). Most people   
   > > lack sufficient motivation to spend needed effort given that   
   > > quite good alternative (Free DOS) is available with sources.   
   >   
   > Ok. Plus most people are unwilling to make the code   
   > public domain.   
   >   
   > > > Here is what I have for MSDOS for the 8086:   
   > > >   
   > > > PDOS/86 (OS): about 30,000 lines   
   > > > PDPCLIB (C library): About 17,000 lines   
   > > > SubC (C compiler): About 5,500 lines   
   > > > as86 (assembler): About 13,000 lines   
   > > > pdar (archiver): About 1000 lines   
   > > > ld86 (linker): About 3000 lines   
   > > > pdmake (make): About 2000 lines   
   >   
   > > The line counts look a bit high to me, given limited functionality   
   > > of what you have. Especially line counts for PDOS and as86   
   > > look high.   
   >   
   > Here are the biggest files in PDOS:   
   >   
   > 21/11/2022  09:38 am            20,480 ntdll.c   
   > 21/11/2022  09:38 am            23,724 format.c   
   > 21/11/2022  09:38 am            24,876 liballoc.c   
   > 27/11/2022  11:57 am            26,211 memmgr.c   
   > 21/11/2022  09:38 am            32,445 bos.c   
   > 21/11/2022  09:38 am            40,865 kernel32.c   
   > 21/11/2022  09:38 am            42,017 minifat.c   
   > 25/11/2022  04:59 pm            46,549 pos.c   
   > 25/11/2022  04:48 pm            47,529 int21.c   
   > 21/11/2022  09:38 am            58,808 exeloado.c   
   > 25/11/2022  05:00 pm            91,099 pcomm.c   
   > 27/11/2022  11:49 am           139,899 fat.c   
   > 30/11/2022  12:33 pm           179,584 pdos.c   
   >   
   > pdos.c is 6500 lines (that includes VM support which   
   > I have conditionally disabled). fat.c is 3800 lines (that   
   > includes LFN and FAT12-32).   
   >   
   > pcomm.c is the command processor.   
   >   
   > It all adds up.   
   >   
   > None of it is test code.   
   >   
   > > > I am not very good with algorithms,   
   >   
   > > Do you really mean "I am not very good with programming"?   
   > > When programming you all time deal with algorithms.   
   >   
   > Possibly. I'm pretty good at debugging, and can do it   
   > at the assembler level. In a typical workplace I'm the   
   > go-to guy. I make things work. But that's when an   
   > existing algorithm is not working due to a wild pointer   
   > or buffer overflow or something, not understanding the   
   > business logic. If the "business" is actually a utility, I   
   > can understand that, e.g. the most recent bug I fixed in   
   > a commercial setting was file synchronization. They   
   > had put in a 2 second delay to ensure processes   
   > didn't clash with each other.   
      
   With good algorithmic background such things immediately   
   "stink" when you read the code.  I does not mean that   
   with algorithmic background you will get things right   
   first time, but knowledge helps to concentrate on   
   critical parts and get them right faster.   
      
   > Another programmer had   
   > "solved" the problem by creating a hash to make   
   > filenames unique, which basically meant we were now   
   > playing Russian Roulette, and the manager had sensed   
   > that and asked me to look at it. I saw the original 2   
   > second delay, ie the original design, and wondered why   
   > it wasn't working as designed. It took a while because   
   > it all looked correct to me. And normal testing showed   
   > that it was working - the second process dutifully queued   
   > on the first. I wanted to see evidence of genuine clashing,   
   > because I didn't believe it wasn't working. I saw the   
   > evidence, so switched belief. I eventually figured out that   
   > they were deleting the original file after it had served its   
   > purpose, and that process of deletion was allowing a   
   > second task to reuse the same filename if the timing   
   > was right. I can't remember the exact algorithm. The   
   > only way I could solve it under the original design was   
   > to not auto-delete all the files. I think I had to leave one   
   > per "group" in /tmp. Like I said, I can't remember exactly.   
      
   I Unix standard way to solve such problems is to build   
   name from process identifier.  OS makes sure that   
   process identifiers of running processes are distinct, so   
   names produced from different processes can not clash.  Things   
   get more tricky is file is supposed to live after process   
   exit.   
      
   > Note that I wanted PDOS to work on S/370 too, and was   
   > looking for a common code base for all my systems.   
   >   
   > It took all that 15 years, and more, to understand AMODEs   
   > properly to the point that I could design PDPCLIB "properly".   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)