From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304241523.AA17372@clio.rice.edu>
Subject: Re: 2.04 status page / 2.04 alpha 1 release schedule
To: djgpp-workers AT delorie DOT com
Date: Thu, 24 Apr 2003 10:23:43 -0500 (CDT)
In-Reply-To: <3EA65605.D387FADA@phekda.freeserve.co.uk> from "Richard Dawe" at Apr 23, 2003 09:59:49 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

> Please could people check the 2.04 status page, to make sure that I haven't
> forgotten any issues:
>     http://www.phekda.freeserve.co.uk/richdawe/djgpp/2.04/status204.html

Comments on the current version:
July 2003 has a goal of new DXE code, but that's in current alpha.  So
the only official goal for the next alpha would be fstat fixes - maybe
we should add new malloc to that goal.

Similarly, updated DXE could be moved from "could go in 2.04" to 
"already in 2.04"

It would be nice if issues were in priority order ...

The EMACS crash under Win2K is actually a problem with unixy sbrk and
disabling hardware (keyboard) interrupts.  (Same with NT).  They are
buggy and ignore the DPMI call to disable interrupts.  At least Win2K
seems to pay attention to CLI/STI as emulation as the patch.  Yes, we
need to test this before I commit it (worried it might break Win9x
or Win31 systems - I think ARDI did this to call to fix problems with
old Win9x which would sometimes forget to reenable interrupts?).  IIRC, 
there wasn't a fix at all for NT systems (short of unhooking the keyboard 
interrupt during sbrk calls).  Given the small number of unixy sbrk()
users - and the platform issues - I'm not sure what to safely do here.
By the way - this is an old bug - so I'm not sure if this should be
in the specific to V2.04 or the "could be fixed in" section.

I decided uclock() needs more work before a check-in.

Under the Perl 5.6.1 item, there is a note on stdprn and stdaux - this
is fixed in 2.04 libc (I did it quite some time ago).  But if
any old V2.03 children programs are called without the fix, it would
break. So I think this is an issue which is fixed, but the patch needs
to stay in Perl since old images are so pervasive (it has to be defensive
of the children messing up it's environment).