ed@odi.com (Ed Schwalenberg) (01/02/91)
I'm writing a virtual device for a 386-enhanced mode program using the 3.0 DDK. Sometimes this virtual device (running in ring 0) needs to cause the System VM (running in ring 1) to execute arbitrary Windows code; I do this by using the Simulate_Call family of services. It mostly works. Sometimes the routine I'm calling is in a segment that is not present at the time I call it, typically because nobody has called anything in that segment since Windows was booted or Windows has discarded the segment. If this happens, the IRETD instruction that returns control to the System VM faults, and the VMM doesn't know what to do and crashes Windows. (If an ordinary ring-1 CALL instruction faults, Windows traps the fault, loads the segment and reexecutes the instruction, but it appears that there is no corresponding handler for ring-0 faults.) I can get around this problem by using Simulate_Call to call a special, fixed, nondiscardable segment which then calls the desired routine, but this seems to be a kludgy fix for an outright bug. Anybody else been bit by this? Is it a bug? Has it been fixed? How can I get the fix? Is there a better workaround? Or am I just daft? Happy New Year.
davidds@microsoft.UUCP (David D'SOUZA) (01/08/91)
In article <1991Jan1.170327.26117@odi.com> ed@odi.com (Ed Schwalenberg) writes: >I'm writing a virtual device for a 386-enhanced mode program using the 3.0 DDK. >Sometimes this virtual device (running in ring 0) needs to cause the System VM >(running in ring 1) to execute arbitrary Windows code; I do this by using >the Simulate_Call family of services. It mostly works. STOP. NO. Don't do that. Let me just repeat myself in case it wasn't clear the first time. STOP. NO. Don't do that. Couple major things going wrong here. First, you mention a bit of trivia about the System VM running at ring 1. Good... Well, forget you know about that. Next time, we'll PROBABLY be running at ring 3 and any ring level assumptions you made are gonna bite you. Note this shouldn't effect Windows apps at all. Unless, of course, you ignored what those bozos at Microsoft have said since Win 1.0 and didn't bother to GlobalLock any GMEM_MOVABLE memory before using it. Now as for VxDs calling Window's APIs... Er, let me start by saying, a VxD isn't a Windows app. A Windows app isn't a VxD. Please don't try to tell the system it isn't so cause bad things will happen. What you are seeing isn't a bug... Let's step back and see exactly what's going on... You bring up Enchanted Mode, and run Windows. Perhaps the Windows VM is painting Progman icon, or perhaps calcing an Excel spreadsheet, or perhaps printing your WinWord document (you have been using those Microsoft apps, right???) Then along comes the Enchanted mode scheduler which suspends Windows, and schedules some other dos box. Then some VxD. And eventually your VxD. Your VxD now does a Simulate_Far_Call to some arbitrary Windows API. Er, just where was Windows when it got suspended? I have no clue, do you? So, just what stack was Windows running on before it was suspended? I have no clue, do you? So, is there enough stack space to execute whatever api you called? What task does windows think is currently running? What ds is available? Have we been suspended while in the middle of changing critical globals and you come in and call some random api? Basically, you are forcing a call into Windows at a non-synchronous time and will totally confuse the heck out of it. About the only Windows API you can call like this is PostMessage. I am really suprised you didn't crash the system... I would suggest you not do this... If you want to use the Windows API, you need to write a Windows app. --Dave