Mail Archives: djgpp/1997/01/28/12:58:12
To any and all who can help answer this question:
I have a 32 bit extended DOS
app which uses Borland's no longer supported PowerPack DOS
extender. When run in a Win95 DOS box PowerPack app's blow up in a most
unsightly manner. I have used SoftIce to track the problem down
somewhat. The app uses window's PM IDT which, much to my dismay, sets
up several crucial INT's (including 10, 21, 31,...) as 286TrapGates.
PowerPack, for whatever reason, uses this windows PM IDT as it's own. When
I call INT 21 within my app, the 286 gate results in 16 bit pushes of flags,
cs, and ip - eflags and eip are lost and the IRETD causes a GPF.
Apparently MicroSoft did this to prevent Win32 apps from using the
old 'INT n' API. If I hook the int using VMM services, these services
install my handler as a 286 gate also and I am still dead. If I diddle the IDT
directly from within my VxD I can make it work but this technique is to
dangerous for general use.
On to the question then. In observing the behaviour of a Watcom 32 bit
DOS app using the DOS4GW extender I notice that this extender creates
and controls a new 3rd IDT to overcome my problem in a 95 DOS box.
This should not be possible as it requires use of the privileged
'LIDT' instruction from a ring-3 app in a VM. It appears they are
getting around this using an undocumented VMM service that allocates
space for an IDT, copies the contents of the active IDT into it, and
then activates the new IDT. Have you heard of this? Any advice?
Please don't suggest 'switch to DJGPP' as my app is gigantic and
conversion from Borland would require an excessive time investment - I
want a patch!
Dan Lenz
Electrical Engineer
LUNAR Corp.
313 W. Beltline Hwy.
Madison, WI 53713
PH: (608)274-2663 x471
FAX: (608)274-0853
- Raw text -