Date:	Tue, 8 Feb 94 19:17:19 -0500
From:	DJ Delorie <dj AT ctron DOT com>
To:	pgf AT cayman DOT com
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: unsupported int redux

> 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.

Because only go32 knows which ones it supports, and the int86() and
_go32_* code are both in the application.  The application would have
to be clairvoyant to know in advance if go32 was going to support the
request it was about to make.  Either that or I, as the library/go32
provider, needs to be clairvoyant and just "know" in advance what all
possible uses for all 256 interrupt vectors will ever be, and code
that into something that fits on a hard drive.

> at the very least, could we have another entry point for
> go32_dpmi_simulate_int that would take the same args as int86?  then a
> macro would be trivial.

Sorry.  The problem happens when you need to pass *pointers* in
registers.  _go32_* is designed to take seg:ofs pointers, assuming
that you (before calling) copied the relevent data to real-mode memory
and figured out what seg:ofs points to it.  The int86() code is
designed to take 32-bit pointers in general registers and let go32 do
the copying for you.  They just don't mix.

> 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() and which need to be translated to
> go32_dpmi_simulate_int().  (or, of course, translate them all)

Yup, that pretty much sums it up.  Welcome to protected mode
programming.  It's not trivial to port DOS 16-bit programs to 32-bit
land.

- Raw text -