ahess@obelix.Utrecht.NCR.NLD (Marco Hess) (07/02/90)
Summary: Issuing interrupts from MS-Windows 3.0 while running in
Standard or Enhanced mode results in a General Protection
Violation.
The situation is the following:
We have a TSR loaded before MS-Windows. This TSR (we call it the Data
Dictionary or DD) is intended for a sort of mailbox for inter program
communication. You can store variables (DD_PUT) in it and retrieve those
variables (DD_GET) by name again. The idea is greatly analog to the DOS
environment variables, except that this Data Dictionary can also store
binary variables and is global.
You communicate with the Data Dictionary TSR through a software interrupt
(currently set at Int60H) and pass a function code and pointers in the
registers as below:
AH = function number
CX = length of buffer
ES:DI = pointer to buffer
DS:SI = pointer to element
AX = return code after the interrupt.
To the old DOS type applications we have two library functions linked in
that are called the DD_Put and DD_Get and those functions would use the
interrupt for talking to the TSR.
Now the idea was to create a MS-Windows DLL with two functions that are
functionally identical to the old DOS library functions but allow the
windows applications to talk to the TSR loaded before windows. This scheme
would allow both Windows and oldapps to share the information in the Data
Dictionary TSR.
The problem is that while we are running in standard mode or enhanced mode,
windows will not allow us to change the values in the segment registers
(which we need in order to pass the pointers). Under CVW the debugger
complains about a "Segmentation violation". Without the debugger it results
in a "Terminating current application" error.
Questions:
- How can generate an interrupts as described above without running
into the protection vault trap?
- Windows internally would have virtual memory addresses and the
Data Dictionary TSR is expecting real addresses. How can this be
circumvented?
[Start of Microsoft Response]
A TSR loaded before Windows is started will always be executed in real mode
(or virtual 86 mode). Because of this fact, the addresses passed to the TSR
should be usable (accessible) in real mode. For the standard real mode
software, BIOS and DOS, Windows is translating the calls and map the calls
to real mode. For a TSR that provides an interface via an arbitrary
interrupt, the calling application would need to do the necessary mapping
itself before making the call.
Take your example,
AH = function number
CX = length of the buffer
ES:DI = pointer to buffer
DS:SI = pointer to element
The calling application would need to do two things.
1. Make the pointers usable in real mode. To do so, the application
should call GlobalDOSAlloc to allocate the buffers. Please refer to
the SDK documentation for this call. The higher order word of the
return value from GlobalDOSAlloc is the segment/paragraph address,
that can be passed to the TSR.
2. If the application attempts to load a real mode segment (as opposed to
a selector) into a protected mode segment register, a protection
violation happens. To pass a segment address in the segment register
to the TSR, the caller should use DPMI (DOS Protect Mode Interface).
DPMI is supported by standard and enhanced mode Windows. One of the
useful services that DPMI provides is Simulate Real Mode Interrupt.
Using this service, the caller sets up a Real Mode Call structure, in
which specifying the register values for the TSR, and make the call
down the real mode TSR. In this way, the caller can safely pass real
mode segment addresses in the segment registers.
It is advised that DPMI services to be used with care, since using the DPMI
in a Windows application may affect future compatibility.
DPMI specification is available from Intel by calling (800) 548-4725.
[End of Microsoft Response]
Although the answer sheds some light on the problem, I am still kind of
stuck. I still can not do an interrupt while running in protected mode.
It might be solved by the Intel documentation (I have no idea what this
document is about), but I suspect that getting this DPMI specification here
in europe will take me at least a couple of weeks.
If you have comment on the problem described above or experienced the same
sort of problems, please drop me a message through E-mail to:
Marco.Hess@Utrecht.NCR.NL
or
...!ncrlnk!ncr-ut!obelix!ahess
Regards,
Marco Hess, System Engineer, Branch Automation Europe, SE-Utrecht
Marco.Hess@Utrecht.NCR.NL ...!ncrlnk!ncr-ut!obelix!ahess
VOICE: +31 (0)3402-76(449) FAX: +31 (0)3402-39125
--
Marco Hess, System Engineer, Branch Automation Europe, SE-Utrecht
marco.hess@utrecht ...!ncrlnk!ncr-ut!obelix!ahess
VOICE: +31 (0)3402-76(449) FAX: +31 (0)3402-39125