segin / readexe Goto Github PK

Running the OS/2 build of readexe under HX Extender's DPMILD16 will result in the value of this->mxz->nextHeader being read/displayed as 0x00000000, where then read_next_header() chokes on reading the DOS MZ header again.

TODO: Validate behavior under Windows 2000 OS/2 subsystem

Invoking readexe with no arguments just says "Not enough arguments" but doesn't specifiy what those arguments should be.

A basic usage message should be included, to be invoked via -h or the like, as well as with no arguments (with the added "not enough arguments" message before the usage text, a la many UNIX utilities.)

Some executables contain multiple modules, or don't necessarily conform with the standard of a DOS stub followed by the "new" format.

Add a command-line flag to manually specify an offset to the next header.

More precisely, when invoking readexe without any arguments, the "not enough arguments" message is normally prefixed with the program's name; however, the included err.c functions instead get the message prefixed with nothing, or worse, random garbage, like this DOSbox screenshot of the Watcom 16-bit DOS build shows:

Ideally, it should read readexe or READEXE.EXE or something similar.

After the DOS MZ header readout, it crashes once identifying the LE/LX header, like so:

The instruction at 0x004022d0 referenced memory at 0x00000000.
The memory could not be written.
Exception fielded by 0x004051e0
EAX=0x000000c4 EBX=0x000000c4 ECX=0x00000031 EDX=0x000000c4
ESI=0x02290de8 EDI=0x00000000 EBP=0x0040ac2a ESP=0x0019fdd8
EIP=0x004022d0 EFL=0x00010202 CS =0x00000023 SS =0x0000002b
DS =0x0000002b ES =0x0000002b FS =0x00000053 GS =0x0000002b
Stack dump (SS:ESP)
0x00000000 0x00000001 0x000000c4 0x00000000 0x00000000 0x00000320
0x00000540 0x02290b50 0x004018ce 0x02290b50 0x00000220 0x00000000
0x00000000 0x00401a74 0x0229454c 0x00000320 0x00000540 0x02290b50
0x00000000 0x00000220 0x00000000 0x00401e60 0x00000200 0x0019fe4c
0x00402a06 0x00402a06 0x0019fe58 0x00000108 0x00406d64 0x0019ff68
0x001a0000 0x004042b1 0x000a3000 0x00000000 0x00000000 0x00000001
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0019ff60
0x00000000 0x00000000 0x00000002 0xffffffff 0x00000002 0xffffffff
0x00000002 0xc000001d 0x00000002 0xc000013a 0x00000002 0xc0000005
0x00000002 0xc000013a 0x00000002 0xc000013a 0x00000001 0xffffffff

Obviously, as this is a self-report/self-assign on a one-man project, this issue is more of a devlog than anything else.