From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10103060333.AA14810@clio.rice.edu>
Subject:	Re: Eradicating djgpp W2000 problem
To:	michael DOT allison2 AT sympatico DOT ca (Michael Allison)
Date:	Mon, 5 Mar 2001 21:33:05 -0600 (CST)
Cc:	djgpp AT delorie DOT com, eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To:	<015301c0a5d6$93d81450$9a77d1d8@mnr.gov.on.ca> from "Michael Allison" at Mar 05, 2001 07:36:18 PM
X-Mailer:	ELM [version 2.5 PL2]
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

> From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> > The lead I can suggest is to try to disable and/or modify the way DJGPP 
> > programs set up exceptions and hardware interrupts in their startup code 
> > (see the files dpmiexcp.c and exceptn.S in djlsr203.zip), as Charles 
> > Sandmann suggested here a few days ago.
> 
> Okay, I've got the djlsr203.zip sources.  Can you give me a little
> more guidance as to what you want me to try next?  I'll put some
> effort into this, but I lack the knowledge of these routines
> that might make the time spent worthwhile and productive.

The first step is to come up with a test that reliably fails.  One that
does that quite well is make/gcc/(cpp/cc1/as/ld).  Now, lets try to build
a makefile that does something simple but similar.  Build a program "test" 
which does something like:
  test a b c d
  for(i=2..argc)
    system("cp ",argv[1],argv[2]);
So cp could be from the file utils, or a simple similar example.

Then some makefile which could create say 100 files (a00 .. a99) via
a set of make rules - which would end up having make call test 30 times, 
with each test calling cp 3 or 4 times.  I would hope this fails like
make/gcc/(*) does - if not ... we've at least learned it is complicted ...

If this fails reliably, I would suggest then building your copy of make, test
and ld with modified libc routines.  In particular I would suppress the
hardware interrupt hooking, exception hooking, etc (dpmiexcp.c) as much as
possible.  Just start commenting features until it works (or badly breaks).
I would also be interested in removing the memory locks (which should be
OK when the hardware exceptions go away).

It would also be useful to know if using unixy sbrk (a crt0 flag) helps.
This changes the memory algorithm, which resizing might be more NT2000 
friendly.

If a castrated dpmiexcp.c still fails, I would suggest setting the crt0
flag to say nullok - this would remove a DPMI 1.0 call which NT may dislike
in some strange manner.

Try adding a wait state after the return from system.  Or right before the
final exit in crt0.s

Hundreds of things to try.  I'm willing to help; I have several Win2000 boxes
to test on.  I know the libc inside out.  I just can't afford to spend more
than a few hours on it here and there...  I just wish I'd had the time to 
mess with it 14 months ago when I first installed Win 2000 :-(
  

- Raw text -