Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,490 of 4,255    |
|    mutazilah@gmail.com to All    |
|    extending MZ    |
|    24 Nov 22 03:28:53    |
   
   From: muta...@gmail.com   
      
   I think I don't need to switch to NE format or anything   
   else in order to support greater than 1 MB address   
   spaces.   
      
   MZ can stay the same, with an implied 4-bit shift, and   
   so long as a single object file doesn't cross a 64k   
   boundary within the executable, the OS can   
   compensate for the 4-bit implied shift and give an   
   effective 5-16 bit shift (using selectors or real shifts)   
   when it loads the executable.   
      
   But executables would be limited to 1 MB in size   
   while ever an implied 4-bit shift exists.   
      
   What I could instead do is here:   
      
   typedef struct {   
    unsigned char magic[2]; /* "MZ" or "ZM". */   
    unsigned short num_last_page_bytes;   
    unsigned short num_pages;   
      
   when the num_pages is 2048 or more, I shift to   
   an implied 8-bit shift (for the segment relocation   
   data).   
      
   Actually, it's not going to work, is it? I would need to   
   relocate offsets too, forcing a large memory size, or   
   I would need to get the code generator to have an   
   alignment of something higher than 16 bytes.   
      
   Otherwise, originally my plan was that an implied   
   8-bit shift would mean an executable could be   
   16 MB in size, which is hopefully big enough. Or   
   else a 9-bit shift would use up all the available   
   bits, ie a file size of 65536*512, 32 MB.   
      
   The biggest executable I have is an unoptimized   
   gcc which is a bit less than 5 MB, but that's only   
   32-bit at the moment.   
      
   Hang on a second - it will work. Even if code is 16   
   byte aligned, you can just use one segment selector   
   for the entire nearly 64k before padding to the   
   boundary and moving on to the next object file.   
      
   So if a.obj = 40k, b.obj=30k, c.obj = 30k, you would   
   have a.obj occupying the first 40k, 24k of padding,   
   then b.obj and c.obj would share the next 64k.   
      
   For a very minor change to the actual MZ format.   
   Zero change in fact, except for implied values.   
      
   Will it work or not?   
      
   If it works, would it be best to max it out with an   
   implied 9-bit shift? That's a fun number to have,   
   really, and it doesn't do any harm to anything.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca