Windows applications may be run under OS/2 Version 2.0 in six ways:
No license of Windows V3.0 or Windows V2.x is necessary to run Windows applications, as the Windows environment is an implementation of Windows V3.0 and Windows V2.x within OS/2 V2.0 (WIN-OS/2) itself. Multiple instances of any of the above methods may be started in the same system.
However, note that in the current release, "seamless" WIN-OS/2 VDMs and common "seamless" WIN-OS/2 VDMs may only be started on machines with VGA graphics. Seamless execution of Windows applications is not supported using other graphics modes.
The following applications are started (iconized) when the first VDM (either SAVDM or MAVDM) is started:
Each of these methods is described in the following sections.
Single Application VDM (SAVDM)
A SAVDM is the recommended way of running Windows applications under OS/2 Version 2.0 in a non-VGA system, such as a PS/2 with an XGA or 8514/A display adapter, because seamless execution is only supported with VGA graphics. Using a SAVDM is also recommended if the user wishes to run Windows applications in real mode (seamless execution is supported only in Windows standard mode).
Since the Windows application runs in a self-contained Windows environment in its own VDM, it is fully protected from other applications, and the system is protected from it. This means that if the application crashes for any reason, it only affects its own VDM, and thus only that one application. Other Windows or DOS applications running in other VDMs are not affected, nor are OS/2 applications. This represents a significant improvement in reliability over DOS/Windows, in which a failure in one Windows application may bring down the entire Windows system or corrupt the data areas of other Windows programs, since all Windows applications and Windows itself share the same address space.
Figure "Single Windows Application Running under OS/2 Version 2.0"
Also, by running in SAVDMs, Windows applications are timesliced more effectively than in a MAVDM or native DOS/Windows environment, since each application is under the control of OS/2's scheduler and its pre-emptive multitasking. In a MAVDM environment, all Windows applications are still subject to the cooperative multitasking under Windows itself.
Ctrl-Esc is the key combination used to display the Windows "Window List".
Alt-Esc is the key combination used to switch to the next session as defined in the Workplace Shell.
The SAVDM provides a simple approach to Presentation Manager integration. The application is loaded from the Workplace Shell in a very similar way to a DOS application, and the user may easily switch back to Presentation Manager, as well as share data via clipboard or DDE with other Windows or Presentation Manager applications. The icon displayed on the Workplace Shell desktop is the application's own Windows icon.
Each SAVDM will indicate the Windows execution mode based on the file type specified in the EXE header of the Windows application. Real mode will be indicated for Windows applications written for versions of Windows prior to 3.0. Auto-Select (real or standard mode) is selected by default for Windows 3.0 applications, based on processor type.
Multiple Application VDM (MAVDM)
The MAVDM is almost identical to running Windows 3.0 on a DOS-based machine. The MAVDM uses the Windows 3.0 Program Manager to start multiple Windows applications within the same VDM, running on a separate Windows desktop. It therefore provides maximum "look and feel" compatibility for the DOS/Windows user migrating to OS/2 Version 2.0.
Note that the use of a MAVDM or the common "seamless" WIN-OS/2 VDM is a requirement where Windows applications must communicate with one another via shared memory.
Ctrl-Esc is used within the VDM to display the Windows "Window List".
Alt-Esc is used to switch to the next session defined in the Workplace Shell.
For a MAVDM, the Workplace Shell icon will represent the MAVDM itself, rather than the applications executing within the VDM. Terminating an application within the VDM will not terminate the VDM itself. The user must select Exit Windows in the Windows Program Manager to terminate the VDM, or close the VDM from the Workplace Shell.
In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all Windows applications are still subject to the cooperative multitasking of Windows itself. Since several Windows applications are typically loaded in the same VDM, the MAVDM environment shares some of the pitfalls of DOS/Windows in terms of robustness. If one Windows application crashes within a MAVDM, it may cause all the applications within that VDM to fail. However, the effect is only within that VDM; other VDMs running DOS or Windows applications, and other processes executing under OS/2 Version 2.0, are not affected and continue execution. So even here there are benefits from running Windows applications under OS/2, for greater resilience from system crashes. Furthermore, the MAVDM environment provides additional error checking and handling over that provided by Windows 3.0 itself.
"Seamless" WIN-OS/2 VDM
One of the goals of OS/2 2.0 is to be the integrating platform of choice; that is, to provide a desktop environment from which all types of applications:
may be executed in a uniform manner. Although OS/2 V2.0 is able to support Windows applications effectively in SAVDMs, the additional ability to launch a Windows application from a Workplace Shell object, and execute it on the OS/2 desktop along with Presentation Manager and DOS applications, achieves the goal of creating an environment that is explicitly simple and uniform enough that the end user need not be concerned with the implicit differences between the types of applications that need to be executed in it. OS/2 V2.0 will concern itself with the differences and "seamlessly" accommodate the applications. This level of support extends not only to execution but to installation and configuration of the application as well.
Figure "Single Windows Application(s) Running "Seamless" on the OS/2 Version 2.0 Desktop"
The appearance of Windows applications on the Workplace Shell desktop requires that the Windows video device driver and the Presentation Manager video device driver communicate and coordinate their access of the video hardware. Each device driver effectively "owns" its area of the screen. Allowing the Windows display device driver to directly access the video hardware avoids the more cumbersome process of a complete task switch. However, this hardware access poses integrity problems in the areas of simultaneous access of hardware, rectangle invalidation handling, window management, and the exchange of window state information between Presentation Manager and seamless VDMs supported by separate video device drivers.
To address these problems, a high performance virtual device driver named (VWIN.SYS), capable of interprocess communication, was created. This VDD serializes the simultaneous accesses to the hardware, oversees the exchange of window state information between Presentation Manager and seamless VDMs, and establishes the addressability of Presentation Manager resources (either directly or indirectly) by the Windows display device driver.
When the system is initialized, the Presentation Manager display driver calls the VWIN.SYS driver, and passes a pointer to an array of structures that specify the protocol required to enable the Windows device driver to access Presentation Manager resources. To prevent a seamless Windows application from hanging the entire Workplace Shell desktop, the Windows video device driver and the Presentation Manager video device driver together implement and monitor a VDM "heartbeat" or counter. This counter is stored in the Presentation Manager display driver's data area and is made available to the Windows display driver.
The "heartbeat" counter information is made available to the Windows DD to indicate that hardware access is in progress by the Windows DD. The "heartbeat" counter is incremented by the Windows DD prior to the video hardware access. If a Windows application is locking up the Workplace Shell desktop, it is the responsibility of VWIN.SYS to identify the current owner of the semaphore, terminate the VDM and tell the Presentation Manager DD to clean up.
In the event that the Presentation Manager display device driver requests hardware resources and the time interval allotted for this access to occur is exceeded, then:
This algorithm is relatively simple but not totally fail-safe. It is quite possible to create a serialization mechanism that would safeguard the Workplace Shell desktop to a greater degree. However, when one considers the remoteness of the possibility of its failure (which requires a bogus PID or TID), the costs, in terms of a performance impact, would far outweigh the benefits incurred.
Some important points about "seamless" WIN-OS/2 VDMs:
Notes:
As shown in Figure "Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 2.0" PMVIOP.DLL contains a PMShield routine which is responsible for maintaining the entire Workplace Shell desktop, including the "black holes" which correspond to and are maintained by each "seamless" WIN-OS/2 VDM.
WinShield is the Windows VDM's counterpart of PMShield. The Workplace Shell desktop windowing state must be maintained in its entirety by this component. WinShield registers a service routine with VWIN.SYS, giving it the ability to post a message to PMShield whenever the Workplace Shell desktop state changes.
Upon creation of the first "seamless" WIN-OS/2 VDM, PMShield spawns three dedicated threads under the Workplace Shell to specifically service its "seamless" WIN-OS/2 VDM clients:
On successful creation of a "seamless" WIN-OS/2 VDM, the Presentation Manager Session Start thread will notify VVGA.SYS to allow the started VDM to access the video hardware directly.
Common "Seamless" WIN-OS/2 VDM
There is no visible difference between Windows applications running in a "seamless" WIN-OS/2 VDM and those running in a common "seamless" WIN-OS/2 VDM. The technical differences between them are described in the following paragraphs. Everything else discussed in the above section ."Seamless" WIN-OS/2 VDM is common to both.
To reduce the system resource usage in a low memory environment, users are given the option to start all "Seamless" WIN-OS/2 applications in the same VDM. This also helps to reduce startup time for Windows applications, and reduces the swap file space required. By default, Windows applications migrated from a DOS/Windows system at OS/2 installation time are migrated to a common "seamless" WIN-OS/2 VDM. The user has the option of prestarting one or more Windows applications in the common "seamless" WIN-OS/2 VDM by using the Startup folder in the Workplace Shell.
There is only one common "seamless" WIN-OS/2 VDM in the system. If the system is not currently configured to run "seamless" WIN-OS/2 VDMs, any Windows application which is defined for common "seamless" WIN-OS/2 VDM will be loaded and run in a fullscreen SAVDM.
By default, only the first Windows program launched from the Workplace Shell as a "seamless" WIN-OS/2 VDM will create a new VDM. Any subsequent Windows programs will share this environment, in exactly the same way as in a MAVDM full-screen session. This is known as the common "seamless" WIN-OS/2 environment.
However, the user may wish to protect these Windows programs from each other, and to maximize the timeslicing efficiency of Windows applications. This can be done by checking the Separate session option on the Session page of the Settings notebook for any Windows program object under the Workplace Shell. That procedure would activate a "normal" "seamless" WIN-OS/2 VDM session.
The Workplace Shell Window List will contain an entry for the common "seamless" WIN-OS/2 VDM itself, in addition to an entry for each Windows program running in this VDM This provides also a mechanism for terminating this VDM from the Workplace Shell desktop, along with all the active Windows applications in it. As the user has a visual representation of the "contents" of the common "seamless" WIN-OS/2 VDM, the user knows which applications will be terminated if the Close option is chosen. If the common "seamless" WIN-OS/2 VDM hangs because one of the Windows programs is not behaving properly, the Close option on the entry for the common "seamless" WIN-OS/2 VDM will close down the entire VDM, including all Windows programs running in it. This behavior is similar to that of a MAVDM.
In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all those Windows applications are still subject to the cooperative multitasking under Windows itself. Since several Windows applications are loaded in the same VDM, the common "seamless" WIN-OS/2 VDM shares the same pitfalls as does the MAVDM. If one Windows application crashes within a common "seamless" WIN-OS/2 VDM, it may cause all the applications within that VDM to fail. However, as in a MAVDM, the effect is only within that VDM; other VDMs running DOS or Windows applications, and other processes executing under OS/2 Version 2.0, are not affected and continue execution. So even here there are additional benefits running Windows applications seamlessly under OS/2. Furthermore, as for the MAVDM environment, enhancements are made to provide additional error checking and handling for the common "seamless" WIN-OS/2 VDM.
A number of restrictions apply to the use of a common "seamless" WIN-OS/2 VDM. These are as follows: