From: muta...@gmail.com   
      
   I have been mulling over the possibility of a minimal   
   change to PDOS/386 to support 16-bit-only programs,   
   starting with command.exe.   
      
   The interrupt I am using to determine available memory   
   only allows me to get a total of 64 MB of memory, and   
   that is what real hardware I have used always returns.   
   (I am aware that older machines had some holes).   
      
   By using 16-bit segment shifts I can basically get a   
   flat address space, which will potentially simplify   
   things. Having nearly 1000 64k mallocs should be   
   sufficient for what I am doing, although it will play   
   havoc with any editor that allocates a line at a time.   
      
   However, I will have difficulty getting my memory   
   management routines to align on a 64k boundary.   
      
   I probably need to switch to huge-memory-model-only,   
   and use an extended DOS call that returns offset, not   
   just segment.   
      
   And then I realized I have another problem. I previously   
   thought that I just needed to ensure a single object file   
   didn't cross a 64k boundary, but now I realize that when   
   ds is loaded with DGROUP, that DGROUP variable is not   
   known to the executable (and thus OS), and that needs   
   to be aligned on a separate 64k boundary.   
      
   So I would need to either pad the executable to a 64k   
   boundary or mark up the executable to the location   
   of DGROUP.   
      
   Actually, I don't suppose DGROUP can be identified by   
   some other mechanism, since it will be located sort of   
   last.   
      
   There may be a general problem that I need to identify   
   places that need to reside on a segment boundary.   
   So if I had a 640k executable I could potentially have   
   10 places marked as segment-aligned, and not need to   
   pad the executable with NULs to align them.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)