From:	"Michael Allison" <michael DOT allison2 AT sympatico DOT ca>
Newsgroups:	comp.os.msdos.djgpp
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010305093728 DOT 23825M AT is>
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:	<yULo6.312037$Pm2.4597997@news20.bellglobal.com>
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" <eliz AT is DOT elta DOT co DOT il> 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.

- Raw text -