Mail Archives: djgpp-workers/2000/09/02/04:58:17
This might bite someone else, so I thought I'd spread the word.
I've just learned the hard way that we seem to be violating the EXE
file format, at least as it is documented in Ralf Brown's Interrupt
List. RBIL says (under D-214B, table 1594) that the dword at offset
3Ch in the executable file should be zero for plain MZ executables,
and non-zero for PE and other ``new executable'' formats. The
non-zero value is the offset of the new executable header within the
executable disk file.
Well, the stubbed executables produced by DJGPP don't have that dword
as zero. Instead, we have the stub blurb there ("stub.h generated
from stub.asm by djasm, on Thu Dec 9 10:59:31 1999" etc.). This
happened to confuse the heck out of the code (originally written by
Mark) in _check_v2_prog_internal for detecting a PE executable: that
code was trying to use a preposterously large offset computed from
ASCII text. The result was that every DJGPP program was failing
_check_v2_prog, and the ability to pass long command lines to child
programs was lost.
Mark, if you are using your modified functions, mail me for the patch.
It's possible that the antivirus programs which were unhappy with
DJGPP executables were also affected by this anomaly.
I'm not sure we need to do something about changing the stub; after
all, it was working fine for so many years. So this is just FYI.
I added a prominent comment in _check_v2_prog_internal, just in case,
so that this will not get forgotten, once the modified functions are
committed to the CVS repository (soon ;-).
- Raw text -