Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E7868E9.19949F8E@phekda.freeserve.co.uk> Date: Wed, 19 Mar 2003 12:56:09 +0000 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: DJGPP 2.04 release? [Was: Re: nmalloc revisited] References: <10303182107 DOT AA24101 AT clio DOT rice DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Charles Sandmann wrote: > > > > 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. If you ignore the new maths functions and the wide-character functions, then we're pretty close to C99 compliance. Use of restrict and the updates to strto* are the only things left for the non-maths and non-wide-character functions AFAIK. > > Apparently stat doesn't return the same inode each time on Win2k/XP. > > OK. I don't think this will be difficult to fix. It would be similar to the proposed fix for fstat. The fstat fix uses the stored file name from fd_props, which is the true name of the original file name, then uses _invent_inode on that. There is a problem that hasn't been solved yet, where we need to do something about UNC drive letters, if we have a mapping for the drive. I can't remember if we can distinguish Win2k & XP from everything else. If not, we could always use this code for directories. > > 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. OK. I'll update the 2.04 status page. > > 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. I've added that to the issues on the 2.04 status page. > > > 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. OK, that sounds a lot safer than it did at first! > > 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 ... [snip] Perhaps we could just dump backwards compatibility on DXEs. How many people actually use DXEs as they stand? Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]