From: muta...@gmail.com   
      
   On Friday, July 2, 2021 at 2:42:32 PM UTC+10, Frank Kotler wrote:   
      
   > > It may be, but I am certain there is no manipulation or use   
   > > of "fs" in the Win32 executables I produce, because I know   
   > > what goes into every byte of code,   
   > Excellent!   
   > ...   
   > > I don't care if there are 50 billion INT calls and syscalls   
   > > and manipulation of hardware and segment register   
   > > manipulation so long as it happens OUTSIDE my   
   > > executable.   
      
   > Okay. I can assure you that there is no "crap" in an ordinary Linux   
   > executable. The int 80h vector, ect. are set up by the OS. well outside   
   > of out executable. No special permissions.   
      
   No, you don't get my point. "int 80h" inside my executable   
   *is* "crap". It requires the *caller* to have special   
   permissions (they need to ensure an interrupt vector   
   table exists).   
      
   It may not exist.   
      
   I want to run Linux executables from PDOS/386, running   
   as an unprivileged program running under Windows 10.   
   I don't have access to INT 80H so the executable will   
   fail (unless I was to somehow scan the executable and   
   zap them all into callbacks).   
      
   Whereas if I run Windows executables from PDOS/386,   
   running as an unprivileged program running under Linux,   
   I do not have this problem. Because the Win32 executables   
   (at least mine) that follow the kernel32/msvcrt rules, have   
   address stubs that are filled in at load time.   
      
   I can easily get PDOS/386 to load the Win32 executable,   
   redirect those stubs to myself, and it doesn't matter that   
   there is no kernel32, no msvcrt, no Windows, and Linux   
   has no clue whatsoever about anything that is happening.   
   No interrupt table is involved either, although PDOS/386   
   will (nominally *) call INT 80H to get access to Linux services.   
      
   BFN. Paul.   
      
      
   (*) Then we get to making PDOS clean by offloading BIOS   
   calls to another abstraction layer, and then it is only at   
   the BIOS level that INT 80H is (nominally **) done.   
      
      
   (**) Then we get to the next abstraction layer where the   
   BIOS is implemented by calling the functions provided   
   by the parameter after envp, rather than mandating an   
   interrupt table. Then Linux itself can be running   
   unauthorized, under perhaps MacOS.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)