From: Martin Stromberg Message-Id: <200009041026.MAA03469@lws256.lu.erisoft.se> Subject: Re: EXE header in DJGPP programs To: djgpp-workers AT delorie DOT com Date: Mon, 4 Sep 2000 12:26:49 +0200 (MET DST) In-Reply-To: <6503-Sat02Sep2000115915+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 02, 2000 11:59:15 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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