From: muta...@gmail.com   
      
   On Thursday, December 1, 2022 at 12:46:25 PM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
      
   > Well, is real OS the big thing is device drivers. If you   
      
   Ok.   
      
   > In compilers hard part is optimization. When I compare gcc-4.8   
      
   Ok.   
      
   > Both of the above are quite different than MSDOS, so let   
   > me mention another aspect. "Bug compatibility" with   
   > different system is hard.   
      
   Ok, thanks.   
      
   I'm happy to bypass all of those things, basically.   
      
   > For MSDOS there are some specific troubles:   
   > - interfaces were specified in assembler   
      
   Another problem I am happy to bypass by creating   
   an API.   
      
   > - 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.   
      
   And I'm also happy to bypass the "small" issue.   
      
   > do this and some that actually did. But there is also   
   > business aspect: Microsoft from the start used "tax" method.   
   > Namely, manufactur had to pay moderate fee for each PC they   
   > sold. So even if you got alternative to DOS you effectively   
   > payed for DOS.   
      
   I see.   
      
   > 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. 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.   
      
   And here's a comment from someone in one of the groups:   
      
   https://groups.io/g/hercules-os380/message/16004   
      
   As I said, I encourage you to work on your PDPCLIB. You've obviously   
   put a huge amount into it already; you are without question one of the   
   most productive people I know, even when I disagree with what you're   
   doing. There are all kinds of things you could do that would further   
   the ability to port existing programs. Just because I think many of   
   your proposals are wacky doesn't mean that I don't respect your work   
   and skill and "get it done" approach.   
      
   (That's an MVS-related group, and that was after he watched me   
   work on PDPCLIB and related for about 15 years)   
      
   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".   
      
   A lot of the things I was doing I was told were impossible.   
   Even by the people who were doing some of the coding.   
   Gerhard was writing the 370 assembler in PDPCLIB and   
   constantly telling me that it wouldn't work, and then it   
   started working, and I showed him the result, and he   
   mustn't have realized what I was showing him, and he   
   still insisted that it wouldn't work, and I told him I was   
   surprised that he was still saying it wouldn't work when   
   I had just showed him that it was already working.   
      
   > Frankly, it seems that you spent quite a lot of time to   
   > get to the point were you are now. And IIUC substantial   
   > part of your codebase came from other folks.   
      
   Probably about 30% came from others. I managed to get   
   FAT12 and 16 reading, but writing was terrible. I managed   
   to get FAT16 writing working after many years. Then   
   someone else (Alica) came along and voom, FAT32 existed,   
   writing of all worked, LFN worked.   
      
   The transition into PM32 came from someone else too. I   
   wrote the code, but it wasn't working. Someone else   
   figured out what I was doing wrong. There were no   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)