From: mutazilah@gmail.com   
      
   Hi rugxulo   
      
   It will be interesting to see what happens with   
   this reply. I still use google groups to read,   
   and I don't seem to be able to get the headers   
   like I used to, which means I can't attempt to   
   put in a proper reply thing. Also I am using   
   X-Comment-To in order to eventually support the   
   Fidonet software that comes with PDOS/386.   
      
   > Hi, glad to hear from you again.   
      
   Thanks.   
      
   >> 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).   
      
   > Didn't the 16-bit pmode stuff from Borland Pascal use NE?   
      
   All Win 3.1 programs do, as far as I know.   
      
   > Anyways, EMX (a.out) and DJGPP (COFF) have   
   > no problems with 100+ MB of RAM.   
      
   That's using PM32, not PM16.   
      
   > Or did you mean a pure 16-bit MZ .EXE   
   > was limited by default?   
   > (In other words, MZ by itself doesn't stop   
   > anyone, but I guess we're splitting hairs.)   
      
   Certain unchanged MZ could indeed access 4 GiB of   
   memory in an appropriate environment, sort of   
   maybe. E.g. if it was tiny memory model and did   
   a malloc of 3.9 GB and the OS being used returned   
   a far pointer, and then the executable used the   
   segment registers to read/write that data, then   
   that should work.   
      
   The big problem is resolving relocation information,   
   but that's not a problem with tiny memory model.   
      
   Another problem is finding a processor with   
   enough selectors to get to 4 GiB. That's why I   
   mentioned 512 MiB.   
      
   The relocation information in the NE is more   
   sensible, instead of having an implied 4-bit   
   segment shift.   
      
   There is no reason why MSDOS 2.0 couldn't have   
   used that NE format right from the start though,   
   and in that theoretical situation, you break   
   the 8086 limitation and move on the 80286,   
   then 80386 (still PM16) with no change to your   
   executable.   
      
   >> 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.   
      
   > I hear it's a complicated format (e.g. resources).   
      
   Are you talking about .res files? I'm not interested   
   in that. Just C90 console mode applications.   
      
   >> 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.   
      
   > Wasn't Win2k the last to support OS/2 1.x textmode apps?   
   > Try using OpenWatcom to build one.   
      
   OS/2 1.x uses a new API. I was talking about   
   getting INT 21H to work.   
      
   But yes, that's basically what I'm talking   
   about beyond that - putting (cut down) OS/2 1.x   
   or similar onto an 8086. As well as on the   
   original 80286.   
      
   >> On PDOS/86 you get the printf too.   
      
   > Surely you're aware of OS/2 family/bound apps too, right?   
   > The 1996 DOS + OS/2 build of mawk is one example.   
      
   Yes, but I'm not aware of what they did.   
      
   Did it require an 80286 processor, even though   
   it ran under MSDOS?   
      
   Or did they keep it in RM16 and get a stub to   
   get the DLL references resolved? I'm planning   
   on just getting rid of that stub and moving it   
   to the 8086 OS. The 8086 OS would then recognize   
   the pure NE OS/2 1.x.   
      
   >> 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.   
      
   > They already could with EMS or XMS. Jim Leonard (Trixter)'s 8088   
   > had 2 MB of real EMS (not emulated).   
      
   I looked up those terms. EMS involves paging,   
   which is not what I want to do. I just want   
   simple 8086 code to work. Also, my goal is not   
   to get more than 640k on an 8088 at all.   
      
   XMS is also obtaining memory above 1 MiB - not   
   my goal for an 8086.   
      
   > The HX extender's HXDEV16 should have some OS/2 emulation.   
   > So hdpmi16 and NE and DOSCALLS or whatever. (I don't know much.)   
   > Again, OpenWatcom is your friend.   
      
   The support I want would need to go into Freedos,   
   although HXDEV16 would also be fine if it stayed   
   in RM16 and used only 8086 instructions. Do you   
   know if it can run on an 8088?   
      
   That would then be conceptually the same as what   
   I want, and the only change is that I don't like   
   DLLs and intend to provide a new API (PDOS-generic).   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)