Hi Reversers...

from inside a (full screened) DOS virtual machine under Win 9x, I want my program to be able to lock the display, i.e. prevent user, or Windows itself, from switching to the desktop or another VM. I don't want to prevent normal interrupt processing of course, nor even other tasks from getting CPU time but I can't release the screen. The reason is my program manipulates the super VGA in an undocumented manner & Windows, although it traps the IO ports in V86 mode, is incapable of restituting my screen if allowed to preempt it :=(

There really should be an API for this, but MS of course can't seem to admit of a program having a good reason to interfere with their notion of good "user experience"... The 1st place to look was in PIFs, and there is no such setting

My 1st idea was to use int 2F/ 1681 (which under the hood increments the infamous INDOS flag, see R.Brown's list), this does prevent switching but is no use in my situation, because it also prevents further int 21's being issued.

Any idea how to achieve this either by an API or hacking ? Can the VMM or another system VxD help ?

On a more general note, I've been seeking docs about the inner workings of Winoldap/Winoa386 in vain...

Has anybody ever hacked a better "DOS box" than Micros*ft's own ?

Curious about what you have to say

--
Czerno

At least you're reversing Win9x, which is much easier than any of the complicated NT-based systems...

Windows 9x, if I remember correctly, was designed to be a preemptive multitasking system, so that there is no way to prevent a context switch at the application level. What exactly do you mean by the "undocumented manner"?

The general architecture of Win9x isn't very clearly documented in general. The M$ site has some fragments of documentation, but it's unclear and inconsistent. Despite that, quite a few years ago (middle of 2000) our group had a small project that aimed at writing a new DOS emulator for Win9x. I'm not sure if any real progress was made, but if I remember correctly, there was some documentation, source codes (in Asm), and a binary produced from it.

I can't find the binaries nor their sources nor the dox, but from the only (archived on another server) picture I could find of it, it seems it was a complete emulator (with debugger too) instead of just a DOS box replacement. The picture (attached) allegedly shows it running tetris in 320x200 at 5.70MHz.

I guess that could be considered a DOS box replacement. (It's not a ZIP file, but a GIF with a ZIP extension.)

Quote :" Windows 9x was designed to be a preemptive multitasking system, so that there is no way to prevent a context switch at the application level."

Sounds much like commercial hype ;=) Of course there have to be ways...

Quote: "What exactly do you mean by the "undocumented manner"?"

Well... SiS (maker of my chipset) does not make technical docs available any more to developpers; those guys seem to firmly believe that the information necessary to establish a 132 columns wide text or any other video mode is a to be held tightly trade secret ! I've had a hard time gathering pieces and bits (pun intended) from old chipset docs and some *iX stuff. I'm done with it, made the new dispaly modes fully available under plain DOS; for allowing them to work in fullscreen WinDOS boxes though, I need to instruct Windows not to switch displays. This could also be of use in other projects.

Quote : " (middle of 2000) our group had a small project that aimed at writing a new DOS emulator for Win9x. I'm not sure if any real progress was made, but if I remember correctly, there was some documentation, source codes (in Asm), and a binary produced from it."

Nice picture. Not really a contender for DOS box replacement in my opinion, rather an emulation environment for old PC gamez was it ?

Thanks for your notes. Still seeking insights into Windows "enhanced" mode DOS box internals.

--
Czerno

Hello,

there is an API int 2Fh, ax=4000h /4007h to disable/enable video port trapping (+ some callouts which should be made if port trapping is disabled), but I'm not sure if this should work for dos boxes or the windows vm only.

Something which may be safer is to hook the keyboard IRQ in the IDT directly, but that would require to be in protected mode (IRQ 1 is mapped to INT 51h in win9x). And then there is still the possibility that it's not the user who switches screens.

Hello,


Interesting. I'll have to look into this VDD interface, although on the surface it looks like informative only, i.e. we can be notified of the screen switching in/out, but we cannot prevent it from happening. Anyway some reversing would not do much harm :~)

edited : Yep, looks like hooking 2F/4005 & 4006 will allow me to restore the screen when returning to the foreground. This is not what I wanted because it requires a TSR to watch for those callouts, but it's sort of neat, I may try to implement it as an exercise. However I prefer the set and forget, no TSR, method, and that requires locking the screen.



Indeed, happens all too often Every 4 minutes for instance on the box I'm typing this, there's a periodic scheduled task restarting a watchdog timer and it preempts the dosbox. Just an example of course.


Have phun, mate

--
Czerno

For whoever is still following this thread : did some testing last night, it appears int 2F/40xx is not the way to go : once this API is engaged, Windows gives up the burden of updating the screen on task switches alltogether (yes, I mean all display, including thewindows desktop) ! Even so after the DOS program that issued 2F/4000 exited ! (There appears to be no way to go back to Windows normal processing of the dispay :-( Oh no there is one, reboot! )

Evidently this API is for use by some exotic display drivers, not ordinary TSRs, even less by transient DOS programs !

My initial goal might be better served by hacking the (ring 3-) scheduler so only thread(s) belonging to the DOS box of interest are allowed to progress. Any ideas and/or examples accepted here !

--
Cz. <czernobyl AT mail.ru>

I've checked an older Win 9x box, with different dispaly hardware/firmware (viz. Cirrus Logics 54xx) and that has built-in 132 char wide text modes, both as VESA and regular (int 10h/00) modes.

What happens when a DOS box is switched to one of these 132c modes is :

1- auto-switches to full screen mode
2- locks itself spontaneously, preventing any switch to another app's screen or the desktop while the display mode is in effect.

But, hey! that is exactly what I want to achieve for my home brewed display mode ! So, it appears Windoze itself provides a means of doing it, no need to "hack" - except, uh, well, how do I set the proper flag(s) ? I guess the settings are maintained inside Winoldap (aka winoa386.mod).

in contrast to the above, when my home made mode is applied, (1-) happens but (2-) locking does not :-(

Any help, insights... greeted !

--
Cz.