Date: Mon, 16 Jun 1997 08:48:22 -0700
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Latest stub
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Cc: Robert Hoehne <robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de>,
        djgpp-workers AT delorie DOT com
Reply-to: billc AT blackmagic DOT tait DOT co DOT nz
Message-id: <33A56046.B16@blackmagic.tait.co.nz>
Organization: Tait Electronics NZ
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <m0wcVKT-000S1kC AT ciati DOT edu DOT ar>
Precedence: bulk

Salvador Eduardo Tropea (SET) wrote:
> 
> > On Fri, 13 Jun 1997, Oberhumer Markus wrote:
> > > DJP comes with an option ('-s') to put the decompression code into the stub -
> > > in this case it will be 2560 bytes long.
> > >
> > > The PMODE stub is > 10kB and I remember having seen some other stubs
> > > (DLM ?) that are even longer.
> 
> And Robert replied:
> > Ok. But I do you handle such files with any of the binutils?
> [snip]
> 
> We saw a lot of post in this thread but the main point wasn't exposed.
> Please Robert can you clarify why do you need to make fixed the size of the
> stub? Is to simplify the code? can't you create a library function that:
> 1) Guess the size is 2048 and tries to find the COFF signature.
> 2) If (1) fails makes a brut-force search skiping chuncks of 512 bytes (that's
> the alignment of the stub, right?).
> And use it in all the places that needs that.
> Perhaps that's impossible but if you don't put all clear ...

Hey, what about the fact that the size of the stub is coded into the exe
header of the file (`dos image load size' or whatever it's called)?  Use
that to skip to where the coff image should be and work from there.

Bill
-- 
Leave others their otherness.