From: james.harris.1@gmail.com   
      
   On 15/07/2021 00:27, muta...@gmail.com wrote:   
   > On Wednesday, July 14, 2021 at 9:25:56 PM UTC+10, muta...@gmail.com wrote:   
   >   
   >> I have 3 combinations I wish to eventually support.   
   >>   
   >> Unprivileged PDOS, unprivileged programs.   
   >> Privileged PDOS, unprivileged programs.   
   >> Privileged PDOS, privileged programs.   
   >   
   > I forgot to finish my chain of thought there.   
   >   
   > For number 2, when the unprivileged call does an fwrite(),   
   > it will go to code outside of its executable, that is   
   > controlled by the OS, and then it's open slather. The   
   > next function, also called fwrite, or similar, will do an   
   > INT something where the privilege gets changed,   
   > and then a little bit more assembler will handle that   
   > and switch back to yet another function called fwrite,   
   > or similar, but now running in the OS, privileged.   
      
   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   
      
      
   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.   
      
   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.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)