Date:	Tue, 8 Feb 94 21:23:25 EST
From:	peprbv AT cfa0 DOT harvard DOT edu (Bob Babcock)
To:	pgf AT Cayman DOT COM
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: unsupported int redux
Reply-To:	babcock AT cfa DOT harvard DOT edu

> i guess i still don't understand why the int86 handler can't go ahead and
> do a go32_dpmi_simultate_int() for the ints it doesn't expect.

Some of the unsupported interrupts require a (possibly large) buffer in the
lower 640K, so go32 would have to recognize the unsupported interrupts and
set things up for them.  Once it starts doing that, they aren't _unsupported_
ints any more.  Also, an unsupported interrupt might be used to talk to a
nonstandard device driver.  Go32 might not be able to know how to support the
interrupt.

> as someone porting DOS code from other compilers to the djgpp environment, i
> now need to find all my int86 calls, and either figure out which ones are
> supported as int86()

Things are much better than they used to be.  Before 1.11, the only way to
implement an unsupported interrupt was to build a custom version of go32.
And, particularly in the debugger version, go32 was pushing the limits of the
small memory model.  A custom go32 complicated the distribution terms (not to
mention the debugging).  As far as figuring out which interrupts are
supported, you can either look at the source code in exphdlr.c or else assume
that everything is supported and let go32 tell you which ones weren't
supported wwhen it crashes.  Symify will then tell you where the offending
call is in your source code.  It would be nice to have a list of supported
and unsupported interrupts.  Maybe I'll compile one tomorrow if we get snowed
in.  The obvious ones unsupported are the FCB functions which no one seems to
care about except me.  (With go32_dpmi_simulate_int I can now use the
standard go32.)

- Raw text -