Running Applications

Windows 95 and Windows NT run applications differently, especially when supporting 16-bit applications.

Windows Internal Messaging

Unlike MS-DOS, Windows uses an internal messaging model to control Windows applications. Messages are generated whenever an event occurs. For example, when a user presses a key on the keyboard and releases it or moves the mouse, a message is generated by the operating system. The message is then placed in a mechanism known as a message queue . An active application will frequently check its message queue to retrieve messages.

Figure 1.7 Message Queues

Messaging in 16-bit Windows

Under Windows 3.1, a single message queue is used by the entire operating system. Win16-based applications cooperatively examine the queue and extract messages addressed to them. This single-queue causes problems. For example, if a Win16-based application malfunctions, it can prevent other applications from checking the message queue, which causes Windows 3.1 to suspend other Win16-based applications until control is relinquished to them and they are able to check for event messages.

Messaging in Windows 95

Windows 95 solves the problems inherent with the single message queue by providing separate message queues for each running Win32-based application. Each thread in a Win32-based application can have its own message queue, and, therefore, is not affected by the behavior of other running tasks . If a Win16- or Win32-based application malfunctions, other Win32-based applications continue to run preemptively and can still receive incoming messages or event notifications.

In Windows 95, all 16-bit Windows-based programs share a common message queue. If a 16-bit Windows-based program fails, all the running 16-bit Windows-based programs have their messages blocked until the failed program is cleared.

Virtual Machines

Under Windows NT, programs execute in virtual machines (VM). A VM is an environment created by the operating system and the processor that simulates a computer's full resources (disk controllers, memory). The virtual machine appears as a single computer to a program, so the program has virtual access to hardware and all other resources.

Figure 1.8 Virtual machines

Windows  NT runs Win16 and MS-DOS applications in their own private address space called a Virtual DOS Machine (VDM). This allows all applications to be protected from other applications. This allows Windows  NT to preemptively multitask all operating system services and applications.

Windows 95 and Windows NT systems can run MS-DOS-based applications in separate VDMs. However because some memory is available to all virtual machines in Windows 95, MS-DOS-based applications potentially can cause the system to halt.

* To test the functions of the 16- and 32-bit Windows-based programs

1. From the WA\Practice\Ch01 folder, double-click Spind16 .

   The SPINDIB16 program starts.

2. Click Open .

   An Open dialog appears.

3. Select the Billg.bmp file and click OK .

   A bitmap of Bill Gates appears inside the SPINDIB16 window.

4. Click either Spin or Flip .

   The bitmap should spin or flip (respectively) and return to the normal layout. The time elapsed appears on the right side of the toolbar.

5. Repeat Steps 1-4 with the SPIND32 program.

   Leave both programs active on your workstation.

* To cause a 16-bit general protection-fault

1. From the WA\Practice\Ch01 folder, start Badapp16.exe .
2. Arrange your desktop to view all the programs.

   One method is to right-click the Windows taskbar, then select Tile Horizontally or Tile Vertically . This automatically arranges all of your open programs on your desktop.

3. Switch to the Bad App program.
4. From the Action menu, click Options , and turn off the sound.
5. From the Action menu, click GP-Fault .

   When the fuse burns down, the bomb explodes. At this point a general protection fault is triggered.

   Windows 95 displays a dialog box allowing you to close the application or ignore the GP fault.

6. Click the first Close button.

   Windows 95 displays an Application Error dialog box with details of the error and a second Close button. Leave this dialog open.

7. Switch to SPIND32. Is the program still active?
8. Switch to SPIND16. Is this program still active?
9. Click the Close button on the Bad App dialog.
10. Is the SPIND16 application active now?
11. Leave the applications running.

    Answers

* To cause a 16-bit Windows-based program to hang

1. Start Badapp16.exe again.
2. Arrange your desktop so that you can see all programs.
3. From the Bad App Action menu, click Hang .

   When the fuse burns down, the bomb explodes. At this point the program hangs .

4. Verify that all programs (both 32- and 16-bit) are not responding.
5. Start the Close Programs dialog by pressing CTRL+ALT+DEL.
6. Select Bad App [Not responding] and click End Task .

   A dialog box appears prompting you to either End Task or Cancel .

7. Click End Task a second time.

   The remaining programs become active.