From: "Michael Allison" Newsgroups: comp.os.msdos.djgpp References: Subject: Re: Eradicating djgpp W2000 problem Lines: 55 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Mon, 05 Mar 2001 12:46:22 GMT NNTP-Posting-Host: 216.209.119.154 X-Trace: news20.bellglobal.com 983796382 216.209.119.154 (Mon, 05 Mar 2001 07:46:22 EST) NNTP-Posting-Date: Mon, 05 Mar 2001 07:46:22 EST Organization: Sympatico To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Eli Zaretskii" wrote in message news:Pine DOT SUN DOT 3 DOT 91 DOT 1010305093728 DOT 23825M AT is... > > On Sun, 4 Mar 2001, Michael Allison wrote: > > > Eli, you've made references to a special djgpp method used to pass > > really long command lines between djgpp programs such as make and gcc. > > Could the cause of this be in that code? [...] > Well, what's so surprising in that? Separate processes are created > for each program even on plain DOS. As long as the processes run in > the same Virtual Machine, we should be okay. (If they don't run in > the same VM, all heck will break lose on us much sooner...) If you're convinced that its a wild goose chase, I'll turn away from investigating that. > Even if this is true, we still need to explain how come it never > shows on any other platform, including NT4. Spawning child > processes is by far the most frequent thing people do with > DJGPP, since compiling programs involves it. A rather odd set of statements, since the same thing could be said of *whatever* is causing this problem. Something is obviously different under Windows 2000. What was your point here? Another group of people using some unrelated software were also having an ntvdm problem, and they did report it to Microsoft. Microsoft confirmed a problem with DPMI memory management, and issued a fix on February 27: http://support.microsoft.com/support/kb/articles/Q288/1/65.ASP The fix replaces the ntvdm.exe. I tried it out. While it does fix the problem the other folks were having, it does not fix the djgpp problem unfortunately. At this point I don't have any leads on where to head next, so I've turned my attention back to work-arounds. I'm using a patched copy of GNU-Make that I built with VC++ to work around it for now. My problem with the Windows32 GNU-Make default build was that Makefiles that did this: cd ../mydir2 do_something cd ../mydir1 wouldn't work, because the current directory context wasn't changed for subsequent commands. I've patched GNU-Make to do that correctly for my purposes now, and since I don't actually use long command lines in Makefiles myself, this suits my immediate purposes. If anyone has a new lead, I can put more time towards this, but I'm leaving it for now.