home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 #1
/
monster.zip
/
monster
/
HAM
/
BPQ407A.ZIP
/
QEMMPROB
< prev
next >
Wrap
Text File
|
1993-09-22
|
2KB
|
39 lines
Received: from n1bee.ampr.org by switch.bedford.ammr.org with SMTP
>> WA1PHY General Purpose SMTP-> Mailbox Server.
I recently had a bug report on one of my own programs which is designed to
interface to your packet switch. The program had been working for some
time under QEMM 6.x, but failed startup under QEMM 7.x.
In certain cases, it seems that QEMM 7.x will hide the interrupt vector
table from the executing application and will replace it with its own
synthetic local interrupt vector table. The replacement table has the
form where each vector will contain an address SSSS:00NN, where SSSS is
some descriptor used by QEMM and which is the same for all vectors, and
where NN is the hexadecimal interrupt vector number. For example, the
contents of the Int 14h vector might be E012:0014.
Normally, this would be transparent to an application which actually
executed an 'int' instruction, since QEMM would use the protected mode
facilities to trap and redirect control appropriately. However, the
install checking for the G8BPQ switch, as you well know, involves
obtaining the contents of an interrupt vector and using it as a pointer
to read the nearby memory for the 'G8BPQ' signature. With the vector
actually pointing at an arbitrary protected mode descriptor, this test
completely fails.
This problem only seems to arise under QEMM 7.x when it is running a
program in Ring 3. Other than when coupled with DESQview, I don't
know of any way to be sure of the privilege level at which a program
executes. Under DESQview, running an affected program at Ring 2 or
a more privileged level corrected the failure. Other than the install
check, all other functions which involve actual transfer of control to
the interrupt handler seem to work.
You might want to make some mention of this in the documentation. I
had a terrible time figuring out what was happening and why.
-- Mike, N1BEE @ WA1PHY.#EMA.MA.USA.NA