Date: Mon, 26 Feb 2001 17:57:47 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Michael Allison cc: djgpp AT delorie DOT com Subject: Re: Eradicating djgpp W2000 problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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!