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
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>

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.

- Raw text -