Date: Sat, 02 Sep 2000 11:59:15 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <6503-Sat02Sep2000115915+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b Subject: EXE header in DJGPP programs Reply-To: djgpp-workers AT delorie DOT com 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 ;-).