X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10205151746.AA22794@clio.rice.edu>
Subject: Re: emacs under w2k
To: eliz AT is DOT elta DOT co DOT il
Date: Wed, 15 May 2002 12:46:54 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com, lauras AT softhome DOT net
In-Reply-To: <8582-Wed15May2002202843+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at May 15, 2002 08:28:44 PM
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

> > is this a traceback type abort for us?  Or an NTVDM death?
> 
> I think it's just killed, no traceback, no nothin'.  You just get
> kicked back to the shell prompt (or, if you started Emacs from
> START->RUN, the DOS box closes).

If so, you can use the task manager to see if ntvdm.exe (for that 
window) went away.  If it did (it sounds like it) this is probably a
DPMI bug.  These are very much like the nesting bug.  Usually nothing
we can do about it other than to avoid doing what breaks it.

> Laurynas, is this true in your case?
> 
> > If it's dieing outside our code, it could be that Win2K has bugs in
> > the realloc dpmi call which is used for unixy sbrk.
> 
> Yes, that's a possibility, but shouldn't this actually happen during
> a call to sbrk (i.e., in a sense, _inside_ our code)?

Yes.

> > > Btw, Charles will probably ask this at some point, so I'll answer
> > > proactively: Emacs sets the Unixy sbrk bit in _crt0_startup_flags.
> > 
> > It would be interesting to see if clearing that caused it to behave
> > better (with the refresh fix to sbrk()...)
> 
> I thought Unixy sbrk was recommended for NT and its descendants, no?

It was previously.

> Or are the reasons gone with the changes in refreshed 2.03?

I think we've reduced the need for this with the refreshed 2.03.  Unix
applications which would still be unhappy with a return sequence of
100, 200, 150 for sbrk() return addresses might still break under some
very infrequent, hard to make happen cases.

Most (all?) of the Win2K testing has been done with the default sbrk(),
so I wouldn't be too suprised if something is flakey here.  It's even
possible that unixy sbrk() was broken in the refresh if the memory block
moves, but it's not very likely.