From: muta...@gmail.com   
      
   On Sunday, July 18, 2021 at 11:19:53 PM UTC+10, James Harris wrote:   
      
   > > My interest is narrowly focused on msvcrt.dll and   
   > > kernel32.dll. In fact, you even get a warning at the   
   > > moment if you directly use the latter, because it   
   > > means you are doing something outside of the   
   > > C90 spec. Well, nominally.   
      
   > Are you saying Microsoft's msvcrt.dll is part of the C90 standard? I   
   > can't see why it would be. C is supposed to be a programming language,   
   > not an interface to any particular manufacturer's software.   
      
   No, we're miles apart.   
      
   Microsoft created a C library, distributed with Windows   
   since Win 95.   
      
   mingw exists by targeting that. You get a pre-made   
   C library, meaning you can have very small executables.   
      
   For PDOS/386, Alica decided she would like the same   
   thing, so made some relatively small changes to   
   PDPCLIB so that it would become a mini-msvcrt.dll.   
      
   "mini" because I think Microsoft's version has a lot more   
   in it than just the C90 library.   
      
   I made PDOS/386 print out a warning whenever an   
   executable uses a DLL other than msvcrt.dll.   
      
   > >> There's nothing wrong with fwrite (if one is emulating Unix) and I'm not   
   > >> suggesting renaming it.   
   > >   
   > > Why did you mention Unix? This has nothing to do with   
   > > Unix, other than it inspired the name vsyscall.   
      
   > fwrite is specified by POSIX, although I should probably have   
   > generalised Linux into POSIX rather than just into Unix.   
      
   That transfers the question - why did you mention POSIX?   
   This has nothing to do with POSIX.   
      
   fwrite is specified by C90.   
      
   > > Yes, I want something like this. And where you say "carries   
   > > out the write" - actually I want every function involved in   
   > > that to be called "fwrite" too. Whether it is writing to a   
   > > particular sector of a FAT partition, or the FAT infrastructure   
   > > doing a special-BIOS-layer fwrite to write to a section of disk 0x80.   
      
   > I can't think why you might want multiple levels of software all to have   
   > the same name. I'm not arguing that you should do otherwise. That's your   
   > choice. But it does seem unnecessary and confusing.   
      
   I think it's very neat. If you want to write 1 byte to a   
   FAT partition at offset 372, you can use fseek and   
   fputc, rather than fwrite.   
      
   Why use names other than the C90-provided ones?   
   What advantage does calling fatWrite() have compared   
   to calling it fwrite()?   
      
   > AISI "fwrite" is what a program invokes in order to carry out the fwrite   
   > function. What the fwrite routine does to /implement/ that operation   
   > should, I would have thought, be immaterial.   
      
   It *is* immaterial. However, why not chuck those immaterial   
   things like DosWrite(), WriteFile(), fatWrite(), PosWriteFile(),   
   BosWriteSector() into the C library (as separate #ifdefs)?   
   Noting that some in the above list, already are, at least in   
   PDPCLIB.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)