From: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id: <200009120705.JAA27117@lws256.lu.erisoft.se>
Subject: Re: stub text shift
To: djgpp-workers AT delorie DOT com
Date: Tue, 12 Sep 2000 09:05:29 +0200 (MET DST)
In-Reply-To: <200009111537.LAA02963@envy.delorie.com> from "DJ Delorie" at Sep 11, 2000 11:37:43 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

> Why is this needed?  Unless random chance has that pointer pointing to
> a valid "new exe" signature, we shouldn't need to worry about zeroing
> it out.

It's not needed in the way that it doeesn't work, but Eli said:
> 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.

So we have a bug. And we should fix that bug.


Right,

						MartinS