Date:	Mon, 26 Feb 2001 17:57:47 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Michael Allison <michael DOT allison2 AT sympatico DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: Eradicating djgpp W2000 problem
In-Reply-To:	<f8sm6.234740$Pm2.3776410@news20.bellglobal.com>
Message-ID:	<Pine.SUN.3.91.1010226174356.24373J-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 26 Feb 2001, Michael Allison wrote:

> > I suggest to stop wasting time on this and start with a scenario where
> > the crashes are reproducible.
> 
> You will need to be able to produce a small sample that reproduces the
> problem if you want to file a report with Microsoft to have them
> actually fix it, which is what started this thread.  I don't think you're
> going to get much action from them if you tell them to download gcc and
> GNU make and then start compiling some non-trivial application.

I didn't say you should send them the case with Make.  I just said that, 
since _we_ are currently debugging this problem, we had better use a test 
case which reproduces the problem reliably.  When we zero in on the 
possible cause(s) of the crashes, we will then have to think how to throw 
together a simple test case.  Not the other way around.

> As far as using Make itself, has anyone been able to identify the
> last Make source line that was executing when the NTVDM crash took
> place?

IIRC, the last version, 3.79.1, was used when Charles Sandmann looked
at this problem a few months ago.

> Have all of the following reported NTVDM problems been ruled out:
> 
> http://support.microsoft.com/support/kb/articles/Q265/8/01.ASP

This sounds like it only referes to 16-bit Windows programs.  Otherwise I 
don't understand what ``child windows'' are they talking about.

> http://support.microsoft.com/support/kb/articles/Q264/3/20.ASP

This doesn't sound relevant: the problem described there can deplete the 
amount of memory available to a program, but should not crash it.

> http://support.microsoft.com/support/kb/articles/Q255/5/70.ASP

This is about the InDOS flag and Int 25h and Int 26h calls.  DJGPP 
programs don't use InDOS flag and don't issue Int 25h/26h functions 
unless the application calls them explicitly.  So I don't think this is 
relevant.

> http://support.microsoft.com/support/kb/articles/Q156/6/87.asp

This quotes a very specific error message; I don't think it has been 
reported in conjunction with the subject of this thread.

Anyway, thanks for the footwork!

- Raw text -