From: mutazilah@gmail.com   
      
   (possible double-or-more-post - google groups   
   stopped working and I have switched to using   
   eternal september using pdpnntp under PDOS/386)   
      
   I think we previously touched on NE executables,   
   but it wasn't a priority for me to continue at the time.   
      
   I also previously discussed limitations I saw on MZ   
   that would prevent my 16-bit executables suddenly   
   getting access to 16 MiB (80286) or even 256 MiB   
   (PM16 on 80386) or 512 MiB (PM32 with D-bit) or   
   4 GiB (theoretical maximum).   
      
   The solution appears to be to use the NE format.   
      
   So probably when PDOS/286 exists one day, I will   
   probably create a flavor of PDOS/86 that uses the   
   exact same NE executables.   
      
   And maybe I will distribute PDOS with 16-bit, 32-bit   
   and 64-bit versions of all executables, and the loader   
   detects which system it is on and loads either PDOS/86,   
   PDOS/286, PDOS/386 or PDOS/x64.   
      
   I have committed changes to PDOS to demonstrate a   
   simple NE executable working. It's crude and only for   
   demo purposes.   
      
   The executable I tested does a printf and then opens a   
   file and writes to it. When run on Windows 2000 the   
   executable is treated as a Win16 and the printf goes   
   nowhere but the file open happens successfully.   
      
   On PDOS/86 you get the printf too.   
      
   When the program terminates, PDOS/86 freezes   
   because of current limitations.   
      
   Only the NE format was changed - it's still unchanged   
   8086 code. Doing INT 21H etc. ie this is a DOS program.   
      
   So 16-bit DOS programs more-or-less already have access   
   to more than 640k/1MB.   
      
   But the writes to stdout are lost instead of appearing on the   
   console that launched the application. For no reason I can   
   see. So an intercept for INT 21H would need to be put in place   
   to get those writes sent to the console (if you want to use   
   32-bit Windows instead of 16-bit PDOS/x86).   
      
   Not sure what the requirements of the intercept would be,   
   and whether an existing TSR like ANSIPLUS might do the   
   trick, and solve the problem of ANSI output at the same time.   
      
   I have committed code changes to PDOS, but they aren't   
   active by default.   
      
   BFN. Paul.   
      
      
   P.S. I have since also got support for __AHINCR   
   (the non-existent kernel.dll will get a 0x1000   
   offset as required for RM16).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)