Mail Archives: djgpp/2000/10/12/02:02:58
In article <8011-Wed11Oct2000210042+0300-eliz AT is DOT elta DOT co DOT il>,
eliz AT is DOT elta DOT co DOT il says...
> > Date: Wed, 11 Oct 2000 13:09:18 -0400
> > From: DJ Delorie <dj AT delorie DOT com>
> >
> > It's in the NT 4 help file and MSDN. FORCEDOS disables the OS/2
> > subsystem (etc), forcing NT to run a program in a VDM even if NT
> > wouldn't normally have recognized the program as an MS-DOS program.
>
> Thanks for the info.
>
> > I'm not sure why this would solve the W2K nesting problem, though.
>
> I'm not sure; from your description it looks like it shouldn't.
> However, we won't lose anything if we try...
>
I just tried and it doesn't appear that it works (eg, "forcedos make"
still exhibits the crash problem).
On a side note, I found another thing that Win2K breaks: hardware
breakpoints. This isn't particularly a problem for gdb, as it defaults
to software (int3) breakpoints, but edebug fails to single-step (and
reports back error messages saying it can't get a DPMI breakpoint), and
fsdb just dies horribly (lock-up essentially).. and gdb fails when you
try to use hbreak, so it's not just the edebug-based code.
Another fsdb-related item: the method it uses to get the LDT causes FSDB
to crash under Win2K. I've managed to work around this by rewriting
that code to use the DPMI get LDT entry call, but it doesn't let you
read nearly so much :(. I also managed to fix the hardware breakpoint
problem by making the original code think that all the hardware
breakpoints have been already used as startup, at which point fsdb
defaults to using software breakpoints.
I can send patches for a "win2k-compat" version of fsdb to whoever the
current maintainer is, but unfortunately I doubt it would be good to
integrate them into the main source, as I don't believe there's a
reliable method to find out if the program is running under Win2K versus
NT4 (if I'm wrong on this, please let me know!).
--
Peter Johnson locke AT mcs DOT net
- Raw text -