DOS ain't dead

[BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX (Developers)

posted by DOS386, 24.01.2008, 02:21

BUG: should be in Developers, not Announce

Seems I found a criminal (sorry ) bug related to MZ DOS executable format.

0,1 "MZ" (or also "ZM" ???)
2,3 LastBlockSize
4,5 BlockCount

Size in bytes 2...5 covers the complete file with header (not explicitly documented, but seems to). 32 bits are used to define a size up to 512 KiB at best .. yeah, efficiency But the big confusion occurs about how the values LastBlockSize and BlockCount are calculated.

http://www.delorie.com/djgpp/doc/exe/ - that's what CWSDPMI-GO32-STUB follows, 2 KiB, BlockCount=8, LastBlockSize=0, means full block.

EOF - end of fun

Brewing a 512 bytes EXE using FASM's "format MZ" results in BlockCount=1, but LastBlockSize=$200 !!! Nobody did explicitly prohibit setting it to $200, or even more - a 32 KiB EXE file could have BlockCount=1, and LastBlockSize=$8000 !

Can it be even worse ? YES, it can

DPMIST32.BIN has 512 bytes, but BlockCount=2, and LastBlockSize=0 -> should be 1024 bytes instead ? Even more: DPMIST32.BIN did change several times in HX history, and, HX 2.5 had DPMIST32.BIN with BlockCount=1, and LastBlockSize=0 - used to be correct ? Is this change intentional ? What is the reason ?

Can it be even worse ? YES, it can

       /* get size of image */
        imageSize=headbuf.image_length_MOD_512+(headbuf.image_length_DIV_512<<9);
                // commented out because of DPMIST32.BIN
//        If (imageSize Mod 512) IsNotZero
//          Then
            imageSize-=512;
//          EndIf ;
        headerSize=(headbuf.n_header_paragraphs)<<4;
        relocSize= headbuf.n_relocation_items << 2;
        imageSize-=headerSize;

Besides of a funny programming language, Ladsoft recently implemented a horrible bug into VALX, to get around the BlockCount=2-problem !

Anyone has a valid and complete MZ EXE specification ? Or should one ask Mr. Mark_Zbikowski ?

PESTUB seems to ignore the stupid MZ header and use "GetFileSize" instead ... there is always a hack

Could this evil 2 get fixed back to 1 ?

PS: PESTUB (non-criminal) issue: accept "PX" besides "PE" on input

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Complete thread:

• [BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX - DOS386, 24.01.2008, 02:21 (Developers)
  • [BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX - Japheth, 24.01.2008, 06:05
    • since it works perfectly .. never change a running system ? - DOS386, 19.02.2008, 01:41
      • since it works perfectly .. never change a running system ? - Japheth, 19.02.2008, 19:21
        • since it works perfectly .. never change a running system ? - DOS386, 20.02.2008, 01:45
          • since it works perfectly .. never change a running system ? - Japheth, 20.02.2008, 08:16
          • since it works perfectly .. never change a running system ? - Japheth, 21.02.2008, 10:22
    • SnglFault ->DblFault ->TripleFault -> BOOM - unavoidable ? - DOS386, 19.02.2008, 02:00
      • SnglFault ->DblFault ->TripleFault -> BOOM - unavoidable ? - Japheth, 20.02.2008, 10:51
        • SnglFault ->DblFault ->TripleFault -> BOOM - unavoidable ? - DOS386, 21.02.2008, 02:33
          • SnglFault ->DblFault ->TripleFault -> BOOM - unavoidable ? - Japheth, 21.02.2008, 07:05
            • SnglFault ->DblFault ->TripleFault -> BOOM - unavoidable ? - DOS386, 22.02.2008, 03:09
  • [BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX - Laaca, 24.01.2008, 07:33
  • [BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX - rr, 24.01.2008, 08:18
    • [BUG] Criminal Mark-related bug | DPMIST32.BIN/PESTUB/ VALX - DOS386, 19.02.2008, 01:30