From: muta...@gmail.com   
      
   On Sunday, July 18, 2021 at 4:22:15 AM UTC+10, James Harris wrote:   
      
   > >>> What is important is whether write() calls __syscall_write()   
   > >>> or whatever that is vectored in from the parameter after   
   > >>> envp rather than doing an INT 80H.   
   > >>   
   > >> I don't know what you mean by "the parameter after envp" but it sounds   
   > >> important to your plans.   
   > >   
   > > vsyscall. Here is code (posted in this thread) that uses it after   
   obtaining it:   
   > >   
   > > mov eax,4   
   > > mov ebx,1   
   > > mov ecx,msg   
   > > mov edx,szmsg   
   > > call [vsyscall]   
      
   > IMO that's still the wrong way for an application to operate. Will say   
   > more below.   
   >   
   > ...   
   > >>> You missed my point above. My point was that UEFI   
   > >>> provides a parameter to the executable at startup   
   > >>> rather than using INT instructions like the BIOS, or   
   > >>> Windows-style DLLs.   
   > >>   
   > >> Is that what you call "the parameter after envp"?   
   > >   
   > > No. The UEFI passes 2 parameters instead. Not sure why   
   > > 2 are required and whether that implies that all environments   
   > > should ideally be using 2 also.   
   > >   
   > >> If so, what does it   
   > >> provide and what will you do in environments which don't provide it?   
   > >   
   > > I think you're not understanding my proposal.   
      
   > Quite likely. My newsreader tells me I have over 200 unread messages in   
   > this newsgroup - perhaps half of which are from you - and I don't get to   
   > read them all thoroughly.   
   > >   
   > > First thing is that Linux executables should be built using   
   > > vsyscall to get the INT 80H out of the executable.   
   > >   
   > > Once that is done, PDOS-generic can feed the Linux   
   > > executables with an appropriate vsyscall, and regain   
   > > control, instead of the executable bypassing PDOS   
   > > and going to whatever is in the interrupt tables (which   
   > > I may not have control of if I am running unprivileged).   
   > >   
   > > So long as everyone follows "the rules" (which I just   
   > > made up), everything should work.   
      
   > 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.   
      
   As far as I can tell, both of those methods are clean   
   and portable. The dynamic linking means you can add   
   new DLLs. The UEFI approach means you are dependent   
   on someone else to update the API.   
      
   And you could have a combination of both.   
      
   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.   
      
   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   
   > >>   
   > >> where the OS library (in your case, clib, AIUI) is shipped with the   
   > >> compiler but is portable; and the OS interface presents a well-known   
   > >> interface for programs to interact with. I see that layer as   
   > >> implementing the OS's 'personality'. Beneath that, there could be any   
   > >> number of layers before one gets to the hardware but apps and the   
   > >> libraries with which they are distributed would be well insulated from   
   > >> the implementation details. That should allow a given program to run on   
   > >> any machine.   
   > >   
   > > What is wrong with a well-known interface called "fwrite"?   
   > > What possible advantage is there in renaming that to   
   > > DosWrite() in OS/2 and WriteFile() in Windows?   
      
   > 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.   
      
   > 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.   
      
   > 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?   
      
   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.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)