It's common knowledge that in Windows 3.x the system provides only a cooperative multitasking environment, where the native 16-bit Windows applications have to consciously yield control in order for the other programs to run. It is also common knowledge that Windows 95 provides preemptive time-sliced multitasking environment only to Win32 programs, whereas 16-bit components are still required to yield control voluntarily.
However, even Windows 3.x provides truly time-sliced multitasking to Virtual Machines, not to threads running in the context of the same Virtual Machine. You may not have noticed, but there is quite a bit of commercial software that takes advantage of such architecture. An obvious example of such software is Microsoft's 16-bit Visual C++, there are also some programming editors and other IDEs (Integrated Development Environments) that run some of their components in separate Virtual Machines (which can be 'hidden', that is windowless) and use some synchonization primitives to orchestrate communication between them. The most popular application for this technique is to run the program build in a hidden VM, trap the output and display it in some type of GUI window. As an additional advantage of this approach, there is no need to rewrite compilers and linkers. The old DOS-based tools run unmodified quite happily whether the DOS box has a window or not.
In this respect, WHIDVM.EXE is just such a program although it only serves demostration purpose. Whidvm uses Andrew Schulman's WINIO library as its GUI shell. You can enter certain commands from the keyboard, and the results will be displayed in a console-like window. The most important command here is 'run'. It takes a DOS command line as its only parameter, runs that command in a hidden Virtual Machine and displays the VM output on the console window. The GUI design was choosen to speed up development, which is exactly what WINIO was intended to do, but this has nothing to do with the program's concept. It could have been some sophisticated GUI window, or maybe a dialog box full of list boxes as well.
Whidvm's ability to create private Virtual Machines fully depends on another component called RUNHIDVM.DLL which is a genuine hidden VM server. It is this DLL that actually calls the operating system to create Virtual Machines, and it can create as many of them at the same time as needed for a particular application. RUNHIDVM is also self-sufficient in terms of handling communications between privilege rings, meaning that it doens't require a client application to provide it with a window handle for that. Check my technical note on desktop window handles to see haw easily this can be done. Because of its genericity, RUNHIDVM.DLL can be used in much more complex situations than the one set by Whidvm.
Each Virtual Machine is created with the background flag set, this lets all the hidden VMs to run simultaneously. RUNHIDVM is also a VxD in the same sense as Ringo is, except that because it uses some of the Ringo services, it doesn't need that many efforts to become one. As a VxD, RUNHIDVM uses Ring 0 semaphores (provided by the Virtual Machine Manager) to synchronize the VMs it has created as well as the System VM in which it's DLL part and the clients of the DLL are running.
At the VxD level, RUNHIDVM traps all output that each of the hidden VMs sends to stderr and stdout, and serializes it. Every time the System VM is scheduled, RUNHIDVM dispatches this serialized output to whatever client is interested in it. You can control the type of output to be displayed in the Whidvm window by using its 'trapout' command. For example, the command 'trapout stderr' toggles the ability to display output sent to stderr. You can also try 'trapout white' command. This will toggle the suppression of any white space contained in the hidden VM output (spaces and tab characters). By default, no output is ignored and no white space is suppressed. You can always interrogate output trapping options by issuing the 'trapout' command with no parameters. There isn't many commands in Whidvm to remember, but you can query a list of them with '?'.
What can you run with Whidvm? Any transient program (transient - in the sense that it doesn't require any user interaction until it exits) you'd run in a 'normal' visible DOS box. I don't recommend to run interactive programs with it because Whidvm has no facility to send keystrokes back to the VM. Not because it's hard or impossible, after all Winoldap has no problem with that, but just because it's a simple demo application. The program you run can be a .EXE or .COM program or a batch file. It can also be a .PIF file since RUNHIDVM has an internal knowledge of PIF file format, it can extract command lines from them on the fly. You cannot run internal command.com commands directly, of course, but you can always include them into batch files. When running batch files, RUNHIDVM follows usual rules, such as it looks up the command processor in the COMSPEC environment variable. RUNHIDVM also takes care of the problem with leaving orphan VMs behind when it runs under Windows 3.x.
download WHIDVM.ZIP
download RINGO2.ZIP (required by RUNHIDVM)
This page has been visited times since Mar-24-1998