From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10303182107.AA24101@clio.rice.edu>
Subject:	Re: DJGPP 2.04 release? [Was: Re: nmalloc revisited]
To:	djgpp-workers AT delorie DOT com
Date:	Tue, 18 Mar 2003 15:07:34 -0600 (CST)
In-Reply-To:	<3E7772C8.EF7B8584@phekda.freeserve.co.uk> from "Richard Dawe" at Mar 18, 2003 07:26:00 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> > I have no objections to these, but they seem less critical than other
> > things.
> 
> Hmmm, I though C99 compliance was a goal of 2.04? In which case isnan, strto*
> are important. fchdir less so, since that's POSIXy.

Does this make the library fully C99 compliant?  If so, great.  I was under
the impression there were other things were still needed.

> Apparently stat doesn't return the same inode each time on Win2k/XP.

OK.

> AFAICT the main reason for new DXE is to support NLS without eating up disk
> space. Is NLS a killer feature for 2.04?

It's actually much more than NLS - that's just one example.  But right now
there isn't a standard toolkit for building shared modules which everyone
has - so noone is doing it.  You have to get the toolkit into a release
before it will be used. 

> I guess it comes down to: What do we (or the users) want from DJGPP 2.04? (Has
> anyone asked them?) What do we have time to do?

Smaller images seems to be a common FAQ on the newsgroup/mailing list.

> > How about considering making all djdev executables link to a dynamic libc,
> > and having libc have it's own version/releases?
> 
> Blimey. That sounds like a DJGPP 3.x thing to me.

Actually we are about there in a test version.  One new call to crt0 which
is stubbed in the standard libc and loads dynamic libc if so required.  If
the new crt0 is in V2.04 - then it can be layered.

> My concern is that it's going to take another year or so to get it out. We
> haven't even got an alpha release to Simtel.NET for testing yet. I expect it
> has got a fair bit of testing, based on Andrew's builds on clio.

DXE's not that much work - and the only thing in the library which uses it
is the FPU emulation loader.  So getting it in, even buggy, is low risk.
We are struggling with compatiblity issues and things you might not want
to live with long term that aren't standards ...

> I'm wondering if there should be some kind of vote. Or maybe DJ could decide?

You get to make the call.  If you are convinced you want to release before
it's in, it's your call.  But I plan to make a race for the deadline. :-)

> Having said that I'd be release manager I haven't actually managed a release
> yet. Oh well.

You's get there ...

- Raw text -