From: james.harris.1@gmail.com   
      
   On 14/07/2021 12:25, muta...@gmail.com wrote:   
   > On Wednesday, July 14, 2021 at 8:43:44 PM 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.   
      
   ...   
      
      
   >> 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.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)