From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10210172220.AA19039@clio.rice.edu>
Subject: Re: stub.asm patch for 2.02 => 2.04
To: djgpp-workers AT delorie DOT com
Date: Thu, 17 Oct 2002 17:20:24 -0500 (CDT)
In-Reply-To: <200210171428.g9HES3525038@envy.delorie.com> from "DJ Delorie" at Oct 17, 2002 10:28:03 AM
X-Mailer: ELM [version 2.5 PL2]
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

> Ok, I have no problem with bumping it to 2.04.  I think the original
> reason was to provide something for tools to read to see if there was
> an API change (new stubbable variables in the header, mostly).  

This is what we originally planned, but the original design was 
so excellent it's never been changed :-).  The version jumped from
2.00 to 2.02 when changes were made for the 2.02 release.  So to
be consistent, we should only increment the number for even numbered
releases, and 2.04 is next ...

Now, if we want to allow for larger (LFN) base names or argv0 ....

> I don't think we need to try to be clever about bumping it for alphas
> or internal changes.

Agreed; the stub rarely changes (compared to go32 ...) - use the libc
build time and ident for that.

> I don't see much need for shrinking the stub any further, unless we
> need to add something else into the new space.  But feel free to post
> the patches anyway ;-)

Is the 2Kb rule documented anywhere?  Maybe that belongs on your history
of DJGPP wepage.

There's still some spare space anyway.  But size tweakers are always
welcome to hack cwsdstub too - I'm sure there's a few thousand bytes
to trim there :-)