Mail Archives: djgpp-workers/2000/09/04/06:29:02
> 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.
If that is the case, it's amazing that we aren't violating contents of
other fields in the header.
> 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.
Looking at the start of a DJGPP .EXE I see there seems to be room at
the end of the message and RCS tags(?) at offsets 0x1b9 - 0x1ff, so if
it's important perhaps we could shift the message a little with a
bunch of starting zeroes.
> 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.
Yes, but it'd be nice if we followed the specs...
Right,
MartinS
- Raw text -