From: mutazilah@gmail.com   
      
   Hi rugxulo   
      
   >> 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.   
      
   > Have you heard of this? It used NE (and real mode) but limited to 640 kb.   
      
   > * https://en.wikipedia.org/wiki/MS-DOS_4.0_(multitasking)   
      
   Hey - that's great. I had heard of it, but didn't know   
   much about it. If it supported NE executables then that   
   gives me prior art.   
      
   >> OS/2 1.x uses a new API. I was talking about   
   >> getting INT 21H to work.   
      
   > Okay, so you want to "standardize" on NE and "int 21h" for PDOS for all   
   > x86 family of computers (8086, 286, 386)?   
      
   For 16-bit executables, yes. That's my tentative plan.   
      
   Perhaps you can say I want a mini clone of MSDOS 4.0,   
   which supported these "good" NE executables.   
      
   So - the maximum that INT 21H is capable of - which   
   is basically 4 GiB. But it really needs a memory   
   allocation function that accepts a 32-bit number of   
   bytes you want, instead of a 16-bit number of pages.   
   If you're restricted to the latter you can only get   
   to 4 GiB in 1 MiB chunks.   
      
   That would be more of a "demo" though. PDOS/86 is   
   already using INT 21H as a "demo".   
      
   Note that in some of my software, the output isn't   
   that important. So I could have an NE executable   
   with INT 21H calls in it, e.g. as86.exe that does   
   an assembly, and so long as there are no errors in   
   the assembler file, you would be able to run that   
   executable on Windows 2000. It is accepted as a   
   Windows 3.1 program and works. And if you ran on   
   MSDOS 4.0 you would presumably get the output too.   
      
   I was thinking more about MZ. So long as no segment,   
   including DGROUP, crosses a 64k boundary, it should   
   be possible to continue to use MZ. If the next segment   
   doesn't fit into the current 64k chunk, then pad with   
   NULs to the 64k boundary. I doubt it will be a big issue.   
      
   There would need to be some extra markup as an MZ   
   extension to zap any location with AHINCR and   
   possibly AHSHIFT. The locations would already be   
   set to x'1000' to support running as-is via normal   
   MSDOS.   
      
   But when run on PDOS/286 or 16-bit PDOS/386, the   
   OS would change all those locations to whatever is   
   suitable for the environment.   
      
   I believe I need a compiler that assumes that ds   
   is not equal to ss. And I think I will need the   
   compiler to also not assume that ds is set to   
   DGROUP in a function and to load that itself. Not   
   sure if that is possible. Otherwise I won't be able   
   to export my C library. Or at least, not as easily.   
      
   And I need startup code that doesn't attempt to   
   force ds and ss to the same value.   
      
   And post-demo I would essentially be throwing all   
   this away anyway, as what I really want is the   
   PDOS-generic interface where the OS provides a   
   pointer to its internal C library (plus OS functions   
   like mkdir()) as a stack parameter.   
      
   It's unclear to me what direction I should be going in.   
      
   I have bought Microsoft C 6.0 and it is currently in   
   customs, so hopefully I will get it soon. Cost a fortune.   
      
   So the first step is to just make sure that PDOS/86   
   can be compiled with this compiler. I have a Book 8088   
   so can do a real XT compile.   
      
   I guess I'm wanting to live within the limits of what   
   was available in 1990 or 1989. I only had an XT in 1988,   
   without a battery-backed clock, because I can remember   
   someone complaining that all my messages were posted   
   with a date of 1988-08-08 because I was sick of setting   
   the date, so I just set it to that in my autoexec.bat.   
      
   I can't remember when I bought my 80386. I think it was   
   circa 1992. I never had an 80286.   
      
   At least one of the lines of inquiry is living within   
   those limits. I have multiple lines of inquiry open.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)