Windows on the Desktop

By Derek Clarkson

One of the big highlights of OS/2 is the ability to run programs written for Windows on the OS/2 desktop as though they were OS/2 programs, yet still letting them look and work like they were running in Windows. Most of us take this for granted now and never really worry about how it all works.

After all, it's as simple as letting the Windows code have a section of the screen to play with isn't it ? ... or is it ?

What about when a program such as Visual Basic needs to have a number of sub windows on the screen ?

What if the Windows program crashes ?

What about compatibility ?

All of this proved to be quite a challenge to the writers of OS/2 and it is quite a feat of engineering. One of the problems with trying to run Windows programs on the WPS before OS/2 2.0 was that they were run in a DOS box on the desktop. Whilst this worked as such it had several problems. First it meant that the Windows program was often clipped by the DOS box so that you couldn't see all of it, and second, because the DOS session required emulation of the video hardware, it slowed the program down.

To solve this in OS/2 2.0 two things were done. First each Windows program was mapped to an identical PM program on the screen. This effectively means that as far as the WPS is concerned, there is only another PM program on screen and it can use this window to keep track of the position, size and focus of the session. It also means that further windows can be created quite simply. For example try running programs such as Visual Basic on the desktop. VB uses multiple windows in it's design environment and the Win-OS2 session has no problems running this. Previously, this couldn't have been done. It also means that there is no clipping problems because the full extent of the Windows program is visible and available for use.

Secondly the Win-OS2 code was allowed to write directly to the video hardware, just as though it was running full screen. This solved the speed problem and allows Windows programs to make use of SVGA, which in previous version of OS/2, they couldn't.

To do these two things, a new program had to be added to all Win-OS2 sessions. Running invisibly in the background this program is called WINSHELD.EXE and it's job is to communication with it's OS/2 shield counterpart. Between the two of them, these programs pass backwards and forwards information about what is happening on the display. So if the Windows program has it's window resized, OS/2 is notified so that the corresponding PM window is also resized. This then allows OS/2 to automatically trigger the refreshes of other PM and Win-OS2 programs which may now be visible. Further, if something happens from the PM side of things, the Windows program can be notified so it can react appropriately to it.

Further to Winsheld.exe, another device driver also had to be added. Called Vwin.sys, it allows the two side of the conversation to share data and addressability.

Whilst the PM shell monitors the PM window it has created for Win-OS2 session in terms of size, position and focus, it doesn't actually write anything to the window's area of the video buffer. This has resulted in programmers referring to these areas of memory as Black Holes. PM may need to know the size and position, etc of these black holes, but it doesn't need to access whats inside them and has no idea of what is there.

Because of this, Win-OS2 can take over this area of the video buffer for it's own use and can use the normal Win-OS2 graphics routines to access the video hardware directly as though it was in a full screen session. Thus it can draw titles, buttons, text, graphics, etc within this black hole space created by the PM. This has a further advantage in that it means that a Win-OS2 session is as close as possible to 100% compatible with Windows, meaning that you don't have to worry about compatibility.

Simple ay? Well not quite. Because there is only one video card and monitor there only needs to be one video buffer. Both the PM and Win-OS2 cannot access this buffer at the same time so a semaphore was created which indicates who has the buffer at the present time. Thus if PM is writing some information, the Win-OS2 session will wait until it has let go of the semaphore, thus indicating that the Win-OS2 session can now write data to the buffer.

This is great right up until a Windows program of the Win-OS2 session decides to crash or hang. There are two problems with this apart from the fact you will be wondering just how much it costs to drop a PC 30 stories. Firstly, because PM doesn't know what is happen inside the black boxes on the screen, it doesn't now to do anything about it. And secondly, even if it did realise there was a hang, but the Win-OS2 session has control of the semaphore and therefore, the video buffer. How is it to gain access to the video to display a message to you ? ... Big Red Switch time !!!!

Well, not quite. To stop this scenario from happening, the Win-OS2 session periodically updates a piece of shared memory. If the PM makes two attempts to get hold of the video buffer and fails because a Win-OS2 session has the semaphore and therefore the buffer, it then checks the piece of memory. If this has not been updated, then the PM assumes that the Win-OS2 program is hung and terminates the session. Thus gaining back control of the video buffer as well as stopping the PC from having to be rebooted. Better than a Big Red Switch any day.

- Derek Clarkson