From: james.harris.1@gmail.com   
      
   On 18/07/2021 00:22, muta...@gmail.com wrote:   
   > On Sunday, July 18, 2021 at 4:22:15 AM UTC+10, James Harris wrote:   
      
   ...   
      
   >> I would go another way: have all apps invoke any service simply by   
   >> calling it, and dynamically link the necessary routines. That way the   
   >> source code and the executables would both be clean and portable.   
      
   ...   
      
   > 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.   
      
   >   
   > While I use normal dynamic loading for those DLLs,   
   > when I come to other environments I need to make   
   > a decision on whether to provide something like a   
   > vsyscall to give msvcrt functionality. I don't have the   
   > design finalized, especially until I find out the   
   > philosophy behind UEFI requiring 2 parameters   
   > instead of 1 vsyscall.   
   >   
   >>>> AISI one needs   
   >>>>   
   >>>> app --> language library --> OS library --> shim --> OS interface   
      
   ...   
      
   >> 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.   
      
   >   
   >> Taking fwrite as an example, I'd suggest:   
   >   
   >> * The app issues   
   >   
   >> n = fwrite(p, size, number, STDOUT);   
   >   
   >> * that invokes a dynamically linked library routine called fwrite   
   >   
   >> * fwrite calls fwrite_shim   
   >   
   >> * fwrite_shim invokes real_fwrite   
   >   
   >> * real_fwrite carries out the write   
   >   
   > 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.   
      
   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.   
      
   >   
   >> The idea is that app and fwrite are at the same privilege level -   
   >> normally user mode - and fwrite is a portable library routine. Further,   
   >> fwrite_shim knows what to do to invoke real_fwrite /on that particular   
   >> system/. And real_fwrite is the service routine for the fwrite system call.   
   >   
   > Yep.   
   >   
   >> That way, whether the app or PDOS is privileged or not won't matter at   
   >> all. You could develop everything as user mode and then, when happy it   
   >> is all OK, switch PDOS to kernel mode just by using appropriate shims.   
   >   
   > Yep, exactly.   
   >   
   > And are you happy with that interface you just described for an   
   > app doing an fwrite() call to be extended to the OS doing an   
   > fwrite() call into the custom-BIOS-layer?   
      
   Absolutely! The routine I called real_fwrite would invoke the BIOS or   
   UEFI or Windows or AmigaOS or Linux or whatever was the underlying system.   
      
   There could be one routine which knew how to call each different   
   underlying system or there could be a real_fwrite for BIOS, a   
   real_fwrite for UEFI, a real_fwrite for Windows, etc.   
      
   Logically,   
      
      real_fwrite would invoke one of   
        +-------------- BIOS   
        +-------------- UEFI   
        +-------------- Windows   
        +-------------- AmigaOS   
        +-------------- Linux   
        +-------------- anything else   
      
   >   
   > And for that in turn to potentially be unprivileged, running under   
   > some other OS itself. And as a result, potentially going up 57   
   > layers before someone takes charge of manipulating some   
   > actual hardware.   
      
   Yes.   
      
   The key, AISI, is (1) separating out the interface that's presented to   
   apps from whatever manages the hardware on a given computer and (2)   
   isolating apps from where any user-to-kernel transition is made. Then   
   the same apps would be able to run on any machine which has your software.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)