Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA993C7.31AE27B8@phekda.freeserve.co.uk>
Date: Fri, 25 Apr 2003 21:00:07 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
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: 2.04 status page / 2.04 alpha 1 release schedule
References: <10304241523 DOT AA17372 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:
> 
> > 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.

Done.

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

Done.

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

Done.

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

Since you can explain it better than me, I quoted this on the page. ;) I also
moved it to the "could be fixed in" section.

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

OK.

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

Great! I moved that to the fixed section.

But I don't understand how a child can mess up the parent's environment. If a
child program closes inherited file descriptors, how does that affect the
parent program? Maybe I'm missing something here. I'm also not sure how the
parent would notice, unless __setup_file_rec_list is called after the child
has terminated. (I don't think it is.)

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]