From: mutazilah@gmail.com   
      
   On 29/02/24 21:16, Jasen Betts wrote:   
      
   > On 2024-02-21, Paul Edwards  wrote:   
   >> On 21/02/24 15:06, J.O. Aho wrote:   
   >>   
   >>>>>> And it is not important to maintain the same value   
   >>>>>> as Cygwin, because Cygwin creates PE executables,   
   >>>>>> while mine is for ELF executables.   
   >>>>>   
   >>>>> Are you just trying to keep your Linux source   
   >>>>> source-compatible with your (Cygwin-based) Windows   
   >>>>> source? Or are you actually looking for the functionality   
   >>>>> behind the O_TEXT flag?   
   >>>>   
   >>>> The latter. Functionality on PDOS/386, not Linux.   
   >>>   
   >>> Think you need to look into the windows source code, as open() already   
   >>> exists in windows   
   >>   
   >> There is no such syscall. kernel32 exports CreateFile.   
   >>   
   >> Regardless - Windows won't run the Linux ELF binary -   
   >> not even the one I produce myself - regardless. Although   
   >> if you install WSL it would, but that's installing   
   >> Linux - and of course Linux programs run under Linux.   
   >>   
   >> It is PDOS/386 that will run it. And receive the   
   >> INT 80H. And check for the flag.   
   >   
   > so make you library figure out which OS is running and   
   > remap the flags given to the to open() function call as   
   > apropriate when translating to int80   
      
   Why would anything need to be remapped? Whenever   
   Linux binaries are run, I use standard Linux   
   values for everything in every system call. With   
   one single exception, which is an addition, not   
   a change - I add the O_TEXT of 0x4000 0000, which   
   I want ignored on Linux (only), and is indeed   
   ignored (on Linux).   
      
   Anyway, PDOS/386 now runs 32-bit MSDOS (by some   
   definition), Win32, Linux and OS/2 binaries. A   
   subset of valid binaries. Enough to run my   
   toolchain, and use my toolchain to rebuild my   
   toolchain.   
      
   OS/2 still has some gaps in the toolchain though.   
   I don't have a linker to build OS/2 executables   
   and I don't have the microemacs editor working   
   for OS/2 32-bit yet. Both are being worked on   
   currently.   
      
   And none of the executables I produce are dependent   
   on the registers or stack at entry, which clears   
   the way to introduce the PDOS-generic ABI, where   
   instead of DLLs, you are given a pointer to a   
   structure with callback functions for a C library.   
      
   BTW, another development was UC386L, a 50k Linux   
   executable, with no external dependencies, not   
   even libc, is capable of running that same subset   
   of valid Win32 and OS/2 executables.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)