0672311836

3.3. Running applications

Supporting Windows 95 does not only mean supporting the operating system itself; it also means supporting applications that will be used with Windows 95. Even though we can't even begin to talk about every application that will run in a Windows 95 environment, we can talk about how to support applications in a general sense. In doing so, we can break it down to three types of applications:

• MS-DOS applications

• Windows 16-bit (Win16) applications

• Windows 32-bit (Win32) applications

3.3.1. Virtual machines

The Windows 95 architecture is implemented through the use of virtual machines. A virtual machine (VM) is a way that Windows 95 can trick the application that is running on a computer with full access to all of that computer's resources. If you have two applications running and they are in separate VMs, they think they have an entire computer all to themselves.

There are two basic types of VMs. The first type is called a system virtual machine (system VM). In Windows 95 contains one, and only one, System VM. All the base components of Windows 95 run inside the system VM, including the interface, GDI, and kernel. Also, all Win16 applications and Win32 applications run in this system VM.

However, all Win16 applications share the same memory address space. The main reason for this is backward compatibility. Some Win16 applications transfer information to each other by the way of this shared address space. Because they share memory with each other, they all have access to each other's information.

Win32 applications are independent from one another because each Win32 application runs in its own separate memory address space. Take a look at Figure 3.7. This does not mean that Win32 applications cannot share information. Instead, they use the more advanced object linking and embedding (OLE) capability to share information.

Figure 3.7. The system virtual machine.

The other type of VM is an MS-DOS VM. Each MS-DOS application runs in its own separate MS-DOS VM (see Figure 3.8). The reason behind this should be clear already. Think about it: before there was Windows, all we had was MS-DOS. Back in those days, we couldn't run two MS-DOS applications at once. This mainly was because MS-DOS applications were written with the idea that they would have the full control over the computer's resources. If you remember back to my definition of a VM, you'd see that the way we give an MS-DOS application the full control that it wants is to run it in its own VM.

Figure 3.8. The MS-DOS virtual machine.

3.3.2. Processes and threads

Understanding applications means understanding how the actual processing happens. In understanding how the process happens, think for a minute about what a process is. Think of a process as a project that an application wants to accomplish. In order to complete a project, you can break the project down into smaller tasks, the faster you can accomplish those smaller tasks, the faster the project is completed. If a process were a project, we would call those smaller tasks threads.

So simply, a process comprises at least one thread, and a thread is a unit of code to be executed. As long as you understand that basic terminology, understanding the different applications is a breeze.

Let's talk about how Windows 95 uses these processes and threads. Windows 95 has a way that it controls these processes and threads through what is defined as a message passing model. A message could consist of some function such as an interrupt (click of a mouse) or information to be transferred. These messages are used to send information from the application to the rest of the system, whether it is from one program to another, to the processor, or to the screen.

These messages are passed through one of several message queues. These message queues are similar to a print queue. If you print something out, you have to wait until earlier print jobs are done before you see your latest printout. Likewise, messages in the same message queue have to wait to be processed until earlier messages are processed.

The number of message queues that you have is directly proportionate to how many and what types of applications you have running.

MS-DOS applications do not use a message queue because they are not designed for message passing.

Because all Win16 applications share a common address space, they all share the same message queue. All threads of code to be executed from these applications have to go through one message queue. Therefore, if one Win16 application becomes hung up for some reason, it clogs the message queue and prevents any other Win16 applications from responding. Once the hung up application has been terminated, the message queue resumes with the next message in line. In Figure 3.9, you see two Win16 applications running. See how they all share the same message queue?

Win32 applications are a different breed all together. Not only does each application run in its own separate memory address space, but every thread of code gets its own message queue. Also in Figure 3.9 you will see two Win32 applications running. These applications can send multiple threads simultaneously, each thread having its own message queue.

Figure 3.9. TheWindows 95 message queue.

3.3.3. Windows 95 internal

Windows 95 consists of many components, but the three main components are the User, Kernel, and graphical device interface (GDI). Each of theses core components consists up of two DLLs, on which is 16-bit and the other is 32-bit. This means that Windows 95 has 16-bit code as a main part of the operating system.

The reason for this was to ensure backward compatibility and better performance. It keeps the older 16-bit code where needed for backward compatibility, but has newer 32-bit code for increased performance.

The kernel, which handles most virtual memory functions, I/O services, and task scheduling is predominately 32-bit to ensure the main core of Windows 95 is fast and reliable.

The GDI takes care of anything that is placed on the screen. Because graphics are nothing more than complex calculations, most of them became 32-bit in Windows 95, but some portions of the code that are smaller functions, such as window management, remained 16-bit for compatibility with older applications.

The User portion manages keyboard, mouse, and other input or output devices. Most aspects of the User portion is still in 16-bit code.

Because you have both 16-bit and 32-bit portions of code that compose the Windows 95 operating system, how do these devices communicate with each other? The kernel provides a service called thunking to translate between 16-bit and 32-bit code.

3.3.4. 32-bit versus 16-bit applications

So far, we've talked about Win32 and Win16 applications in how they use the message queues, memory address spaces, and such. Let's contrast the two by talking about the difference between preemptive and cooperative multitasking. Multitasking is defined as being able to accomplish more than one task at a time. In Windows, it means that we can run more than one application at a time, but there are two ways of multitasking: preemptive and cooperative.

Preemptive

In a multitasking environment, threads are assigned a priority. They are then executed in the order of the priority that they hold. With preemptive multitasking, each thread is run for a preset amount of time, or until another thread with a higher priority comes along. This prevents one thread from taking control of the processor and keeping it all to itself.

Because Win32 applications run in their own separate memory address space and MS-DOS applications run in their own separate MS-DOS VM, they are preemptively multitasked in Windows 95.

Cooperative

With cooperative multitasking, a thread can control the processor until the processor is done with it. The program that is sending the thread controls how long the thread has control of the processor and when it should relinquish it. Therefore, a Win16 application that is not well written can attempt to take total control of the system.

Win16-based applications are the only applications that are cooperatively multitasked in Windows 95.

Contrasting

Win32 applications are multithreaded. A single Win32 application can send multiple threads, simultaneously to the processor to be processed. When you couple that with the idea that each Win32 thread has its own message queue, you can see how these applications can do more, faster. Therefore, Win32 applications can be preemptively multitasked. They can all send out multiple threads at the same time to be processed.

Unlike Win32 applications, Win16 applications can kick out only one thread at a time. Also keep in mind that all Win16 applications running in Windows 95 share the same message queue; therefore, they have to wait on one another. This is why Win16 applications are cooperatively multitasked. They must cooperate with each other when sending out threads from the message queue.

Figure 3.10 can give you an overview of how the whole process works.

Figure 3.10. Multiprocessing in Windows 95.

3.3.5. Running MS-DOS applications

All Windows-based applications have information stored in the executable file of the program that tells Windows what resources it needs, how much memory it needs, and other attributes about the program.

MS-DOS applications do not have this type of information, however. You can modify the behavior of MS-DOS applications by pulling up the property sheet for that application. In order to obtain the property sheet of an application, right-click on the EXE file in the Windows Explorer and select Properties.

The property sheet will consist of several tabs that I will explain. Once you've modified the information in the property sheet, a program information file (PIF) is created automatically. By default, the file created uses the same name of the executable file and has PIF for the extension. Any time you execute that application, the information stored in the PIF will be set for that application.

Figure 3.11 shows the first tab, the General tab, of the property sheet for a MS-DOS application. As you can see, this tab is common to all files in Windows 95 and contains pretty basic information.

Figure 3.11. The MS-DOS Properties Sheet, General tab.

The Program tab contains information such as the Command Line, the Working Directory, and Shortcut Keys if applicable (see Figure 3.12). Also on this tab, you can specify that a certain batch file run prior to the execution of the application. At the bottom, you see two buttons, one titled Advanced and the other Change Icon. I think that Change Icon is self-explanatory, but I will cover the Advanced button toward the end of this section.

The Font tab is the next tab in line. In Figure 3.13, you see that you can change the size and style of font used in the program. Need I really say anything more?

The Memory property sheet lets you tightly control the memory on an application. I've come across several instances where someone was trying to run an MS-DOS application and was having difficulty. The user simply assumed that the application wouldn't run in Windows 95 and gave up. With a little tweaking here, you can run many applications that you may have thought wouldn't. Keep in mind that these settings are only for that specific application and not for the entire machine. This basically sets up the memory configuration for the MS-DOS VM. Figure 3.14 shows a picture of this tab.

Figure 3.12. The MS-DOS Properties Sheet, Program tab.

Figure 3.13. The MS-DOS Properties Sheet, Font tab.

The Conventional memory setting specifies how much conventional memory is required for this application to run. I have yet to come across an instance where Auto hasn't worked.

Figure 3.14. The MS-DOS Properties Sheet, Memory tab.

The Initial Environment setting specifies how much memory you would like to set aside for COMMAND.COM or settings in batch files such as SET variables. SET variables are things like the PATH statement, TEMP folder, and the like.

You should check the Protected check box if you do not wish the information stored in memory for this application to be paged to the hard disk. Be prepared for a performance drop if you select this option.

The Expanded (EMS) memory setting is where we did some tweaking. This setting specifies how much expanded memory you want to limit this application to. If you set it at Auto, the sky's the limit. Some applications have difficulty when they can't see the limit. If so, set this to 8MB (8,192K).

The Extended (XMS) memory setting is like the expanded memory setting. This is where you set a limit as to how much extended memory you are going to allow this application to have. Auto is the setting where there is no limit. If you have to tweak the expanded memory setting, there's a pretty good chance you'll have to tweak this one. Once again, set it to 8,192K if the application doesn't like the Auto setting.

DPMI stands for DOS protected-mode interface. This is also a maximum setting. Unlike the previous settings, Auto does not leave it as no limit. If you leave it on Auto, Windows will specify a setting based on the machine's current configuration.

In Figure 3.15 you'll see the Screen tab. This tab is also relatively basic. The settings at the bottom, Fast ROM emulation and Dynamic memory allocation, usually throw most people off.

Figure 3.15. The MS-DOS Properties Sheet, Screen tab.

The Fast ROM emulation is checked by default. When checked, it allows the program to use the ROM drivers in protected mode. This can increase video performance by speeding up the rate in which the program can write information to the screen. If your program has difficulty writing to the screen, try removing the check mark in this box.

As for Dynamic memory allocation, with the check mark on (default), it allows the program to control the amount of memory set aside for displaying graphics. Make sure this check mark is on if the program frequently switches between graphics and text. Remove the check mark if you are running Windows on a machine with very little RAM. This will allow Windows to manage the memory and allocate to the program as Windows sees appropriate.

The Misc tab (see Figure 3.16), contains all the misfit settings not appropriate for other tabs. Once again some settings here are self-explanatory.

Idle sensitivity is how long you want Windows 95 to wait before it suspends (pauses) the application for inactivity. If you have an application that appears to be idle but isn't, Windows will suspend it. This causes some MS-DOS applications to crash. If so, set this to its lowest level.

The Quick Edit mouse setting allows for cutting and pasting inside an MS-DOS program when the program is running in a window. Deselect this option if the MS-DOS application uses a mouse.

Figure 3.16. The MS-DOS Properties Sheet, Misc tab.

Exclusive mode locks the mouse inside the MS-DOS application window. If your MS-DOS program uses a mouse and you run the application in a window, you'll find this option handy. If the mouse cursor loses synchronization when you move it in and out of the application window, select this option. It can be a little frustrating at first.

The Windows shortcut keys area at the bottom of this window specifies which Windows 95 shortcut keys are enabled in this program. If your MS-DOS application uses any of these shortcut keys, deselect them here so that the keystroke stays within the program instead of going to Windows 95.

Using MS-DOS mode

Let's go back to the Program tab. Clicking on the Advanced button on the bottom pulls up a dialog box similar to Figure 3.17.

Some MS-DOS programs are written to detect whether they are running in a Windows environment. These programs react differently depending on whether they are running in Windows or in an MS-DOS environment. If you would like to hide the Windows environment from the MS-DOS program, place a check mark in the first setting.

The next setting, if checked, will allow Windows to determine whether you should use MS-DOS mode for this particular application. This setting is checked by default. (These figures are greyed out in the figure because I have selected to run in MS-DOS mode.)

Figure 3.17.

The Advanced Program Settings dialog box.

If your program will absolutely not run in Windows 95, you can choose to run it in MS-DOS mode. Most examples that I can come up with are games. I do have a couple of games (yes I believe in having fun, too) that require MS-DOS mode. Not sure what MS-DOS mode is? Allow me to explain.

Say you specify that you would like for a particular program to run in MS-DOS mode. When you execute that program, Windows 95 shuts down and the computer restarts in MS-DOS mode (Windows 95 is not loaded). The program then executes automatically. When you exit the program, the machine restarts in Windows 95.

Once you have specified that your machine starts in MS-DOS mode, you have two choices of how to configure the machine for that application. Looking once again at Figure 3.17, you see that I have already specified that this program run in MS-DOS mode. The two choices that you have are these: Use current MS-DOS configuration and Specify a new MS-DOS configuration.

If you choose the Use current MS-DOS configuration , the default settings of the computer will be used. If you choose the Specify a new MS-DOS configuration, you can specify any CONFIG.SYS and AUTOEXEC.BAT settings in the provided boxes. With this option you can specify specific settings on a program by program basis. You can even take it a step further and create several PIFs for one application and specify different settings in each PIF.

I have actually put MS-DOS mode to use in a dual-boot configuration with Windows 3.11. The customers needed to use both Windows 3.11 and Windows 95 environments.

Windows 95 was their predominate environment, but they wanted a quick and easy way to drop completely out of Windows 95 and into Windows 3.11.

With the machine installed with Windows 3.11 and Windows 95 in separate directories (so changing one wouldn't in any way affect the other), we created a shortcut on the desktop. The shortcut's command line pointed to the WIN.COM of Windows 3.11. We configured it to start in MS-DOS mode with specific CONFIG.SYS and AUTOEXEC.BAT settings.

When they wanted to drop down to Windows 3.11, they simply double-clicked the shortcut icon. The machine reboots and starts in Windows 3.11. After they're done with Windows 3.11, they simply exit Windows. The machine reboots again and starts back up into Windows 95.

By default, a check mark is placed in the Warn before entering MS-DOS mode setting. This option, upon executing the program, will display the message in Figure 3.18.

Figure 3.18. The MS-DOS Mode warning.

3.3.6. When an application goes bad

When the term crashed application is used, it usually means different things to different people. For those of us who are familiar with Windows 3.x, it usually means the appearance of the infamous general protection fault error message. For others, it may mean the application no longer responds to keystrokes or mouse clicks. Well, in actuality, both are correct.

General Protection Faults

A general protection fault (GP fault) is not a thing of the past with the creation of Windows 95, but you will see fewer of them. A GP fault basically occurs when a program attempts to violate system integrity. This is classified as an application failure. The way Windows 95 handles applications that attempt to violate system integrity depends on what type of application it is.

If an MS-DOS application fails, a GP fault error appears. Clicking OK will terminate the program. The program that fails is the only program affected by the failure because MS-DOS applications run in their own separate VM.

When a Win16 application fails, a GP fault error message appears stating which application has failed. Until this application is terminated, all other Win16 applications stop responding. If you remember from 3.3.3, Win16 applications are cooperatively multitasked. Once the failed application terminates, all other Win16 applications resume.

Win32 applications are a little different. Because they each run in their own separate memory address space (3.3.3), they don't affect other applications when they fail. A GP fault error message is displayed notifying you what program failed.

Hanging an application

No, I am not talking about getting the noose out for those notorious applications. I'm talking about when an application stops responding to the system. Most people think that because the application that they have in the foreground has hung up, Windows 95 is hung up as well: this is a fallacy. Usually this results in the user pressing Ctrl-Alt-Del being about 30 times at an alarmingly fast rate or just as badly reaching for the infamous power button. These actions are not warranted because there is an easier (and safer) way.

Pressing Ctrl-Alt-Del once (and only once) will perform a local restart. Despite what the name might imply, the computer does not restart In fact, it pulls up the Close Program dialog box. This box will inform you which program has hung up by placing the words Not Responding next to it. To terminate the program, simply click on it, and click the End Task button.

Program Resources

When you terminate an Winapplication, what happens to the resources? Well, that depends on whether the application is an MS-DOS–based, 16-bit Windows, or a 32-bit Windows application.

When you terminate an MS-DOS-based application, its virtual machine is also terminated. This returns all resources to the system.

If the application is a 16-bit Windows application, things are a little more complicated. The 16-bit Windows applications may use resources without Windows 95 being aware of them. Additionally, they may also use resources that other 16-bit Windows applications are using because all 16-bit applications share the same memory address space. Therefore, when you terminate a 16-bit Windows application, the resources that it was using are not returned to the system until all 16-bit applications are no longer running. Once the last 16-bit application is closed, all resources are returned to the system.

With 32-bit Windows applications, things are tracked more closely. When a 32-bit Windows application is terminated, its resources are returned to the system.

In Windows 3.x, 16-bit applications many times crashed the computer because Windows 3.x was 16-bit. Windows NT has a capability to run 16-bit applications in their own separate memory address space so that they do not affect other applications or resources.