Date: Mon, 15 Sep 1997 15:03:12 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Transfer buffer device driver
In-reply-to: <199709150240.WAA05042@delorie.com>
To: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Message-id: <199709150308.PAA17666@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization: Tait Electronics Limited
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <199709150203 DOT OAA17313 AT teleng1 DOT tait DOT co DOT nz gatekeeper.tait.co.nz>
 (message from Bill Currie on Mon, 15 Sep 1997 13:58:35 +1100)
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On 14 Sep 97 at 22:40, DJ Delorie wrote:
> As much as this is an interesting idea to pursue, making the user
> install (and run) yet another program is not a good idea.

I actually agree.  That's why I made the stub behave as before if 
there is no driver.

> If we change 2.02 crt[01] to locate a previous stub (even from 2.00
> or 2.01 programs) and, if found, use it and resize its own stub to
> minimum size, I think we'll have the best solution.  That lets us
> expand one stub to 63.5K and leave the rest at 0.5k (or less?),
> without any of them suffering from too-short-tb syndrome.

The trouble is: how?

> Not changing the stub means no problems with stubify, strip, or ld
> changing the stub to an old version on us.

Yes, this is definitly a risk.

I did the changes partly to show it could be done and also so that 
the code is at least there.  I didn't actually EXPECT it to be 
accepted (hoped, yes).

It was fun anyway and I learned a lot about device drivers.  Anyway, 
it helps demonstrate the structure support I added to djasm.
Bill
--
Leave others their otherness.