This chapter provides you with a background on the Windows NT architecture for supporting applications—more specifically, the subsystem architecture that allows you to run many different types of applications from DOS and 16-bit Windows programs, even OS/2 and POSIX applications. You will learn how these subsystems communicate with each other, and with the Windows NT operating system. You also will learn how applications can be configured under these various subsystems. Supporting applications is an important portion of the exam. For this reason, we will cover the ways you can start applications to increase their performance as well as their stability and how applications affect each other and the system.

Windows NT uses modular components for the subsystem architecture that enable compatibility for applications. These subsystems provide the application programming interfaces (APIs) that are specific to the operating system they are mimicking. This specificity is the reason there are several environment subsystems, such as OS/2, POSIX, and the Virtual DOS Machine. The subsystems are run in User Mode and are 32-bit, preemptively multitasked with other applications on the system.

Looking at Figure 13-1, you can see just how important the primary Win32 subsystem is to the rest of the environment subsystems. These other subsystems call upon the Win32 subsystem with requests for translation. You will learn more about the Win32 subsystem later in the chapter.

Figure 13-1 also shows how each subsystem not only communicates with the Win32 subsystem for translation, but with the Windows NT Executive Services. The subsystems are communicating with each other by passing messages through the Local Procedure Call Facility, which we will discuss later. I mention this message-passing facility to show you that subsystems do communicate by requesting and providing services to each other, invisible to you. The subsystems also call on the system services, because that is the only way they can gain access to the NT Executive.

Environment subsystems enable Windows NT to remain compatible with existing software. Windows NT provides support for various subsystems and Virtual DOS Machines.

All of these subsystems are protected from each other to prevent errant applications from affecting other applications running in a different subsystem. They too are run in User Mode, so as not to affect the performance of the critical system components, such as the Executive Services.

Another subsystem, called the Client Server Runtime Subsystem (CSRSS), provides console, shutdown, and error handling functions to the other environment subsystems. This subsystem is not covered in this chapter, because it does not provide a subsystem for applications to run. There are also integral subsystems, such as the security subsystem, which are very important, but not for the purpose of running applications.

The difference between Kernel Mode and User Mode concerns whether or not direct access to the hardware is given. Kernel Mode, otherwise known as Privileged Mode, has this capability. Only a select few components are run in Kernel Mode. This is to provide stability by limiting the amount of components that are allowed to access the hardware. If every component or application were allowed to directly access the hardware, chances are the system would continually crash as these components or applications made incorrect or improper function calls.

User Mode is the Mode in which the majority of Windows NT code, environment subsystems, and all of the applications are run. This is also known as Nonprivileged Mode, because it is not privileged to accessing the hardware directly. It must have its calls to the hardware intercepted and translated by the NT Executive Services before processing. There is a concern that some applications will need to access the hardware directly, but unfortunately, they cannot be run on Windows NT. Since Windows NT has restricted access in this way, it has become a very stable operating system. Unless you have applications that are unsupported due to this restriction, you will be very pleased with the stability that NT provides.

The Kernel Mode is comprised of several components that work together to maintain the system. As mentioned before, this mode has full access to the system hardware. Only a select few components run in this mode.

The Windows NT Executive Services, combined with the NT Kernel, are at the top of the Kernel Mode component hierarchy. The Executive Services have separate components that perform the various operating system functions. The following components each have a responsibility to carry out a specific function when called upon.

The Object Manager is responsible for the creation and use of objects. This includes naming, managing, and security for objects. Objects are everywhere in Windows NT, and have a type, various attributes, and a set of operations. They can be physical devices such as a COM port, or they can be abstract, such as a thread. Other parts of the operating system and programs access these objects by the name of the object. The Object Manager gets a request, and uses an object handler to provide a pointer to locate the actual object and the information about the object. The Object Manager also cleans up objects that have been orphaned. These orphaned objects might consume system resources if not properly terminated.

The Process Manager is responsible for process and thread objects, including deleting, creating, and managing these objects. A process is a program, or a part of a program, that has an address space, contains objects, and spawns threads that need to be processed. A process object, which is overseen by the Process Manager, watches over the threads that it produces, including their priorities and the amount of time they spend in execution. The Kernel itself is responsible for scheduling these threads to be processed.

The Virtual Memory Manager (VMM) is responsible for the use of virtual memory and the paging file in the system. The VMM keeps track of all mapping between the physical and virtual memory. It is responsible for swapping the pages in and out of memory as needed. This can be a demanding task, because you can have up to 4GB of virtual memory, thanks to the 32-bit flat memory model. Half of the virtual memory is reserved for the operating system storage, and the other half is for applications.

The Local Procedure Call Facility is responsible for passing information between processes. Applications make calls to the environment subsystem for service. This relationship is based on a client/server model. This is not the client/server model you are familiar with, such as an NT Server sharing files to workstations on the network. The client/server relationship in this respect is within one computer. The applications or processes (clients) requiring service make calls to the environment subsystem (server). This is a local procedure call, and this is how the Local Procedure Call Facility got its name. If you are familiar with the Remote Procedure Call (RPC), you can see that the Local Procedure Call (LPC) works the same way, only it is local to the machine.

The Security Reference Monitor is responsible for access to the resources in the system. It has to provide validation for users, access to objects, and generating audit messages. This is also a very demanding task, because Windows NT has a great deal of security, even down to the file level. The Security Reference Monitor works with the logon process and security subsystem to make up the entire security model for the system. The Security Reference Model uses the logon process to verify that a user has access to the system. After the user has been granted permission to access the system, there is still constant access validation to verify that the user has access to the object. Successful and failed attempts to access resources also have to be audited by the Security Reference Monitor.

The I/O Manager is responsible for all input and output for the operating system. Since input and output usually are handled by hardware devices, the I/O Manager has to spend a great deal of time communicating with the device drivers. These drivers, as we will see later in the section, are for communicating with the various devices in the system. The I/O Manager communicates with the drivers so it does not have to be aware of how the device functions. It only calls upon the driver to perform the functions. In addition to communicating with the device drivers, the I/O Manager communicates with the file systems and the Cache Manager, which are subcomponents. The I/O Manager must route information to the file system drivers to be able to access the drivers for the devices. It also communicates with the redirector to access files stored on a network file system, just as it does with the local file system. The Cache Manager is responsible for managing the cache for the entire system, and is controlled by the I/O Manager.

The Graphics Device Interface (GDI), is the graphics engine. It is responsible for communication between applications and the graphics devices. Applications call on the GDI for graphic output, and in turn the GDI calls upon the graphics device driver. This is another example of the Kernel Mode components using a driver to communicate with the hardware in the system. Kernel Mode components can communicate to any driver in the same way. Developers can make use of this powerful GDI to make their work easier, adding only hardware-specific code to their drivers and letting the GDI do most of the work.

The Window Manager (USER) is the component that creates the screen interface for the user. When applications call on USER functions, the call is communicated to the GDI, which in turn communicates with the device drivers to perform the function. An interesting fact about the Window Manager is that it draws 16-bit application windows using the Win32 GDI functions. This explains why my old applications appeared different when I first ran them on the new operating system. The dialog boxes were drawn differently, and the placement of the buttons had changed.

Both the Graphics Device Interface and the Window Manager ran in User Mode in the Win32 subsystem in previous releases of NT, but now have been moved into the Windows NT Executive, which runs in Kernel Mode. This will speed up calls to the graphics devices by reducing the amount of costly translation calls from User Mode to Kernel Mode. For example, Microsoft’s PowerPoint, a graphically intensive multimedia application resulted in a 15-20% increase in performance compared to Windows NT 3.51.

Device drivers are used to communicate with the various hardware components in the system. These drivers are just small programs that are called upon when the system needs to communicate with the device. The Executive Services are designed so that the Kernel Mode components communicate with every device the same way. The device driver is what performs the specific features of the device. Although some device drivers can be used to communicate with many different devices, it is more common to see a device driver for each device, including drivers for each brand and model of the device. Finding compatible drivers to work with Windows NT is a concern. The number of device drivers for NT is limited, and you cannot use other operating system drivers.

The Microkernel, or Kernel, is the core of the Windows NT operating system. Before we get too specific, we should say that the Kernel is responsible for all actions that take place on the system. This means that the Kernel is extremely busy and very important, because most system functions have to pass through it. The Kernel uses modular components to help with the various system operations. These components all work together, and are known as the Executive Services, which we have been discussing. The Kernel is not only a member of the Executive Services, but also is the head of the Executive Services. It is responsible for scheduling and managing threads, and handling exceptions and interrupts. Interrupts are natural, common occurrences in the system, but exceptions occur when a process has performed an operation that is not permitted, such as writing to a portion of memory already in use, or dividing by zero.

The Hardware Abstraction Layer (HAL) is the layer between the operating system and the hardware located in the computer. The HAL is what makes NT able to be ported to other architectures. A new HAL is required for different architectures, and you even require a new HAL for a multiprocessor system. For this reason, there are two Hardware Abstraction Layers provided for each processor architecture: one for a single processor configuration, and one for a multiprocessor configuration. The goal is to write the new HAL to allow for different architectures, and to compile the rest of the operating system code.

In order to get some applications to run in Windows NT, you may have to do some configuring of the application or environment. Most applications run just fine, but you still may want to maximize their performance, or increase their stability. In subsequent exercises, you will see how to do this using the various types of applications and subsystems. You also will see how applications can be adjusted on a per-application basis, and how the environment can be adjusted so that subsequent applications use the same settings. Refer to Figure 13-2 for and overview of the applications and memory spaces.

The Win32 subsystem is the primary subsystem for Windows NT. This is where most of your applications designed for Windows 95 and NT are run. These Win32 applications give you the most performance and stability, because they are designed to run on Windows NT, a Win32 operating system. You don’t spend as much time trying to get these applications to run as you would with DOS or Win16 applications. If you are using 16-bit versions of programs, you will see better results after upgrading these programs to the 32-bit version.

Win32 is what provides the user interface, as well as control for the input devices such as the mouse and keyboard. When an application is running from another subsystem, it must have its calls directed through the Win32 subsystem for translation. You will learn more about this technique, called thunking, later in the section. For now just understand how important this subsystem is. It doesn’t even appear that other subsystems are running, because you see the Win32 subsystem user interface the whole time you are running NT. If it is not the familiar Windows interface, then it is the character-based window, called a console.

This subsystem uses a separate memory space and message queue for each application. This provides stability if one of the applications were to crash. The other Win32 applications would remain unaffected. As a matter of fact, any other applications running are not affected if a Win32 application crashes or hangs.

Although it appears as if the DOS and Win16 Virtual DOS Machines (VDMs) are separate, they actually are a part of the Win32 subsystem. It’s easier to understand how these VDMs work when they are isolated from the Win32 subsystem for discussion.

1. Make sure you are logged on as Administrator of the system.
2. Press Ctrl-Alt-Del to bring up the NT Security dialog box.
3. Click the Task Manager button.
4. Click the Processes tab.
5. Start the NT calculator by typing CALC in the Run dialog box. (Start Menu | Run.)
6. Notice that CALC.EXE now appears on the processes list. No other components are needed to run this application.
7. Close the calculator.
8. Exit the Windows NT Task Manager.

Windows NT Win32 applications can be multithreaded for increased performance. These 32-bit applications are designed to have more than one thread for the process. These multiple threads can be executed on any processor in the system. Threads in general are a good idea for performance. If processes were not broken down into smaller threads, one large file could take a long time to execute, and cause the other processes to wait their turn. Smaller threads can be executed in such a rapid manner that they appear to let many applications run at one time. Of course, on a single processor system these threads cannot be run at the exact same time. However, with a multiprocessor system you receive this benefit of multithreading between the processors on the system. Now you can have threads executing at the same time. These threads can be from the same process, or different processes.

The default for Win32 applications is to use a separate memory space. This separate memory space prevents an application from affecting other applications and the operating system if it becomes unstable. You won’t see an option to run these applications in their own memory space, because they are already run in their own space by default.

Just as with the memory space, Win32 applications use separate message queues. When we say separate, we mean separate from every other running Win32 application, as well as separate from the 16-bit applications. These Win32-based applications provide better recovery if an application crashes or hangs. In other words, the application can still receive events from it’s own message queue. If the message queue were one large queue for all applications, one application could stop another from receiving its messages. You will see later in the chapter how Win16 applications use the message queue by default. You can compare and contrast the use of message queues between the two, and how applications are affected.

Processes have base system priorities, and the threads that are spawned from the processes inherit the priority of the process. However, these priorities can be altered. Priorities are assigned to threads and processes so the highest priority processes or threads, most likely system processes, are processed first. Executing threads based on priority is one method that preemptive multitasking uses to multitask applications. The other method is to use a time slice, known as a time quantum, that executes a thread until the time slice has expired for that thread. The next thread in line will then be processed.

You can start applications at different priority levels from the command line. This is useful if you know beforehand that you would like this application to be more responsive to requests, or less responsive. If you do not alter the priority of an application, it runs at the default priority level of 7. This is on a priority level of 0 - 31, with 31 being the highest priority. When an application is in the foreground, it receives a priority boost to level 9. Here are the different levels you can start an application in:

/LOW, which begins the application at the priority level of 4. This is considered the IDLE priority class.

/HIGH, which begins the application at the priority level of 13. This is considered the HIGH priority class.

/REALTIME, which begins the application at the priority level of 24. This is considered the REALTIME priority class.

Of course, if you do not specify a priority level when starting the application, it receives the default priority class of 7, which is considered the NORMAL priority class. Assigning a new priority class should be done with caution, because a high priority such as REALTIME can put a tremendous strain on your system. REALTIME applications do have the advantage of not being paged to disk, and that can be very useful. You can try these priority levels on your own computer, but try not to mess with them too much in a business environment unless you know what you are doing.

In addition to adjusting priority levels from the command prompt, you can adjust priority levels for the applications using the Windows NT Task Manager. The applications are running processes that can be adjusted. One application may have more than one process, but in most cases you can tell which process correlates with the program you would like to alter. For example, I have Microsoft Word open, and the process that appears for Word is WinWord. I can right-click WinWord and choose Set Priority to adjust the priority level. You have the same priority level options here as you did from the command prompt. WinWord is currently running at the default of Normal. It is a little off the subject, but you can also start applications as minimized or maximized from the command prompt. Here is the syntax for starting the applications either minimized or maximized:

START /MIN application_name

START /MAX application_name

You probably will be asked on the test to choose the correct command line for starting an application, based on the situation. This will include the priority levels, separate memory space, and whether it will be minimized or maximized. Know your syntax! You can type START /? |MORE at the command prompt for an overview.

Windows NT can run MS-DOS applications as well as, or even better than DOS can. This is amazing when you consider that Windows NT does not have any DOS code at all. These DOS applications are run in a Win32 application called the NTVDM, or NT Virtual DOS Machine. Each VDM has its own address space, and can be preemptively multitasked with other applications on the system. This is where you see the performance increase. You also can have multiple VDMs running on the same system. The DOS application running in the VDM is fooled into thinking it has full access to the system resources, just as it did when it was run in its native operating system. Windows NT even uses Virtual Device Drivers (VDDs) to trick applications that require sole use of a device. This might not work every time an application requires direct access to the hardware. Unfortunately, Windows NT does not allow direct access to the hardware for applications, so these applications probably will not run on NT. No amount of configuring changes the fact that the application requires direct access to the hardware.

1. Make sure that you are logged on as Administrator of the system.
2. Press Ctrl-Alt-Del to invoke the NT Security dialog box.
3. Click Task Manager.
4. Click the Processes tab.
5. Use the Start Menu | Programs | Command Prompt to open a command prompt, which is CMD.EXE.
6. Notice in Task Manager that CMD.EXE appears as an only process.
7. Type QBASIC in the Command Prompt window. Now look in Task Manager and see the NTVDM process that has been created for the QBASIC program. This is because QBASIC is a DOS program that requires the NTVDM to function.
8. In the QBASIC window, press Esc to clear the dialog box. You can now exit the Command Prompt window by pressing Alt, then F for file, and then X for Exit.
9. Type exit to close our Command Prompt window.
10. You can see the CMD.EXE and NTVDM no longer appear in Task Manager.
11. You can now close Task Manager.

These are the key components to the Virtual DOS Machine:

As we indicated earlier, Virtual Device Drivers (VDDs) are used to trick an application into believing it is communicating with a device. Windows NT has provided these VDDs for the mouse, keyboard, printer, COM ports, and for network support. These VDDs are are loaded in every VDM, with settings based on the Registry entries. The following Registry key is for VDD information:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\VirtualDeviceDrivers

Just as you did in Windows 95 and Windows 3.x, you can configure the Program Information File (PIF) for a DOS application, only this time it is the Properties dialog box for the application. There is no longer a PIF editor for this purpose. The Properties dialog box configures the environment for the DOS application when it is running in Windows. In other words, you are configuring the VDM. The PIF for the application is automatically created in the same directory as the executable for the application. If there is no PIF associated for the application, then the _DEFAULT.PIF will be used. The default values for the VDM may be sufficient to run the application, but if the application still refuses to run, we can make adjustments to the program properties.

Some DOS programs allow you to right-click them and configure a number of environment settings for the application. You need to make a shortcut to others before you can modify the environment settings. For example, you can use the CMD.EXE in the %SystemRoot%\System32 directory. This program is available for each installation of Windows NT Workstation, so we will use it. If you right-click CMD.EXE, you see only a few tabs, most likely General, Version, and Security. We need to make a shortcut to the CMD.EXE program before we can adjust any of the properties. The quickest way to create a shortcut is to right-click CMD.EXE, and select Create Shortcut. You should now be on the shortcut, so go ahead and right-click the shortcut that we just made. You should now see more tabs that can be used to adjust the environment for the DOS program. Here are a few things you can adjust that are useful:

Of course, there are many more settings available to configure a custom DOS environment for the application. These settings can be adjusted on a per-application basis, or you can configure your shortcut to the Command prompt so that every time you click it, the environment receives your custom settings. This can be done by finding the shortcut to the Command Prompt under your profile. I am logged on as Administrator of this machine, so I would look under Winnt\Profiles\Administrator\Start Menu\Programs. You should now see the shortcut. Right-click this shortcut and make the necessary changes to the environment that you wish. These changes will be available every time you click this shortcut.

There are some DOS applications that let you configure even more than what we just saw in the previous example. For these applications you would just right-click the icon for the program. For example, I have used the BACKUP.EXE in the %SystemRoot%\System32 directory. When you right-click this application you see a few tabs that were different from the CMD.EXE properties. (Once again, I used BACKUP.EXE as an example, because everyone should have this in a Windows NT installation. I tried clicking on the BACKUP.EXE after I configured the environment, but this is not a type of DOS application that is meant to be clicked from Windows. You can adjust the properties of your favorite DOS-based applications rather than for these applications that I have shown you.)

Returning back to the properties for BACKUP.EXE, we see four new tabs: Program, Memory, Screen, and Misc. Program has most of the same settings that the Shortcut tab does for the CMD.EXE shortcut that we saw in Figure 13-3. Here is a summary of the available features of each of the tabs.

There are also two configuration files that can be adjusted for environment variables, called CONFIG.NT and AUTOEXEC.NT. They reside in the %SystemRoot%\System32 directory of your computer (see Figure 13-4), and work just the way you would expect from the equivalent DOS files. When the VDM is loaded, it processes these two files. Here is where you can place commands and environmental settings that you would like to be loaded with every VDM.

You can reach this Windows NT PIF settings dialog box by the Programs tab when you right-click a DOS application. Click the button called Windows NT.

When you have configured your DOS applications, there is something that you should be aware of. First, the NTVDM is not loaded until you start your first DOS application. Every other DOS application that you start after the first DOS application uses the VDM that was created by the first application. If subsequently you were to start an application that had custom environment settings that you specified, your changes would not be in effect. This is because it was not the first VDM loaded, and it’s inheriting the settings of the first VDM. You would have to start the custom application first to take advantage of the settings that you specified.

There is a chance that your DOS applications won’t run for another reason. Some DOS applications check to see if you are running the correct version of DOS. You can find out what version of DOS you are running yourself by typing VER at the command prompt. If you type VER while in Windows NT 4, you receive the answer: Windows NT Version 4.0. But the VDM reports DOS version 5.0 to the application that is checking. This could cause the application not to run, if it requires a higher version of DOS than 5.0. This can be remedied easily with the program included with DOS, SETVER. This lets you trick the application into thinking it is running in the correct version of DOS. It reports the version of DOS that you specify to the application.

There is a huge need for Windows NT to remain compatible with the large amount of 16-bit programs still in existence. The last statistic that I heard concerning operating systems was that Windows 3.x still retains the market share for desktop operating systems. This might seem strange to the more advanced user like ourselves who demand performance, reliability, and stability, and continue to upgrade to the latest and greatest operating systems. However, many businesses still have these 16-bit applications. They rely on these applications for important facets of their company, including accounting, record keeping, and payroll. You’d better have a compelling reason to migrate or upgrade these applications if they are being used for these critical purposes. I cannot believe some of the applications we still use at our company are compatible with Windows NT. If these applications were not compatible with NT, there would be a gigantic concern over migrating to NT. There is still a concern if you find an application that can be replaced with a newer version, or a product from another vendor that performs the same function. You have to migrate the data, or even worse, recreate the data. This is why application support is so important to the design of Windows NT. It is important to understand how these Win16 applications are run in Windows NT. You may find yourself having to configure these applications, or troubleshoot a faulty application. If you know how these Win16 applications are run by default, you are halfway to understanding how they can be configured if the default is not acceptable.

16-bit Windows applications run in a Virtual DOS Machine with another layer for the Win16 functionality. These applications by default are run in a single VDM, with a single thread for processing. This VDM can be preemptively multitasked with the other applications in the system. However, the 16-bit applications within the VDM are cooperatively multitasked with each other. This is very important to remember, not only for the exam, but also for troubleshooting purposes. Preemptively multitasking the single VDM with other applications can increase the performance of the Win16 applications. This also protects other applications that are running on the system from being affected if another VDM becomes unstable. Cooperatively multitasking the Win16 applications by default still leaves them prone to simultaneously crashing or hanging, just as they did in their native 16-bit environment. We will see later in this section how using a separate memory space for these Win16 applications can help performance.

Since Win16 applications require DOS to function, the same rules apply in terms of access to the hardware. If this Win16 application needs to have direct access to the hardware, it doesn’t function. To illustrate the fact that these Win16 applications require DOS (or what we now use as the NTVDM) to function, watch the results of the following exercise.

1. Make sure you are logged on to the system as Administrator.
2. Press Ctrl-Alt-Del to bring up the NT Security dialog box.
3. Click the Task Manager button.
4. Click the Processes tab.
5. Find a 16-bit application on your system and start the application.
6. If you have Task Manager open while you are starting the 16-bit application, you will see it load the NTVDM.EXE, then the WOWEXEC.EXE, then the application itself.
7. Start another instance of the 16-bit application, or if it does not let you, start another 16-bit application while you are running the first one.
8. Notice how the second 16-bit application runs in the same NTVDM as the first. You can continue to open more 16-bit applications and they will continue to appear under the same NTVDM.
9. Exit all of the applications that you have just started, and notice the NTVDM and WOWEXEC still remain.
10. Exit the Windows NT Task Manager.

When 16-bit applications are being run they need to communicate with the primary Win32 subsystem. As noted earlier, the Win32 subsystem is responsible for translating requests from the applications in the various other subsystems. These 16-bit subsystems use a process known as thunking to translate between the 16-bit and 32-bit requests. WOW, which stands for Win16-on-Win32 is this translation layer. There are several components in addition to the VDM involved for the WOW.

Remember that the Win32 detects the Win16 executable and loads the NTVDM. Once the NTVDM is started, the WOW environment is loaded. You witnessed this in the preceding exercise. Subsequent Win16 applications are run using this same NTVDM and WOW environment that was just created.

Running 16-bit programs in separate memory spaces can be effective if you are using older 16-bit applications that are not very stable. The faulty 16-bit application can be isolated and run separately from the other applications in its own memory space. If the application were to crash or hang in this separate memory space, it would not affect the other applications running. This does require more memory, so not every Win16 application should be run in a separate memory space. These unstable 16-bit applications are ideal candidates for separate memory space. Be warned, that some Win16 applications expect to share a memory space with other applications, and if you are running applications in a separate memory space they cannot communicate.

As you can see from Figure 13-5, you can check the box to indicate that you would like the 16-bit application to start in a separate memory space.

There is another way to configure Win16 applications to run in a separate memory space. It is through use of the command line. This method is useful if you would like to run this application in separate memory for one instance only. Here is the syntax for the command:

START /SEPARATE application_name

If you were to not include the SEPARATE parameter, the 16-bit application would start in the default environment, which is in the same memory space as the other 16-bit applications.

Rather than constantly starting an application in a separate memory space, you can configure the Win16 application to start in a separate memory space every time you execute the program. This is demonstrated in the next exercise.

Locate a 16-bit application on your system that can be used for the next exercise. You will know it is a 16-bit application when the option to run the application in a separate memory space becomes available.

1. Find the executable for the application, and drag the application to the desktop. This creates a shortcut.
2. With the icon on the desktop, right-click it and select Properties.
3. Click the Shortcut tab.
4. Under the target path for the application, check the box to run in a Separate Memory space.
5. Click OK to save your changes.

Every time you start the program using this shortcut, it will be started in a separate memory space. You also can make a shortcut for the application not to run in the separate memory space. You then will have the choice of starting the application the way you choose.

There is another way to find out if you are using a 16-bit or 32-bit application. The next exercise shows you how.

1. Press Ctrl-Alt-Del to open the Security dialog box.
2. Click Task List
3. The Windows NT Task Manager now appears. Click the Processes tab.
4. In the Options pull down menu, make sure that Show 16-bit Tasks is checked.
5. If there are any 16-bit applications currently running on the system, they are indented under the NTVDM.EXE, and also have the WOWEXEC.EXE running. If this were the last 16-bit application running on the system, and you were to close the program, the default NTVDM and WOWEXEC still remains open.

We have now seen the most important ways to configure DOS and 16-bit Windows applications. Before we continue, we should go over some possible exam scenarios. I was surprised to see about 10 questions on my exam covering these very topics.

Q: "You have a 16-bit application suite and one application is faulty…"

A: Run the faulty application in a separate memory space so it cannot affect the other applications running. Be aware that running every 16-bit application in a separate memory space is an option, too.

Q: "One 32-bit application crashes…"

A: Don’t worry. It will not affect the other applications running on the system.

Q: "Three 16-bit applications are running in the default space, and one crashes…"

A: Once the faulty application that has frozen the message queue has been terminated, the other applications should be able to continue processing. You must know the defaults that these applications are run in. All 3 shouldn’t crash, just the faulty application. Once the faulty application that has frozen the queue is terminated, the other 2 applications should be able to continue processing.

Q: "You want to start a program minimized and in a separate memory space…"

A: Remember the syntax for starting applications from the command prompt. You know the command is START, and you know the switch for separate is /SEPARATE, and you know the switch for minimized is /MIN. Look for the answer with these choices, and of course, in the correct order. Here is the proper syntax for the command:

START /MIN /MAX /SEPARATE application_name

Q: "You would like to start a program with a higher priority level…"

A: Start the application using the HIGH priority class. This too is done from the command prompt. Know the syntax and the correct order. Once again, here is the proper syntax for the command with priority levels.

START /LOW /NORMAL /REALTIME /HIGH application_name

Q: "How are 32-bit applications run in relation to…"

A: They are preemptively multitasked with other applications in the system.

Q: "How are DOS applications run in relation to…"

A: They also are preemptively multitasked with other applications in the system, including other DOS applications.

Q: "How are 16-bit applications run in relation to…"

A: They are cooperatively multitasked within their own VDM and preemptively multitasked with other applications in the system.

Message queues were very important for older 16-bit applications that were cooperatively multitasked with each other. They shared the same message queue. An application would be written to check the message queue for other applications that request processing. If there were other programs waiting for processing, this application had to yield control of the processor and allow the other applications to execute. If the application refused to check the message queue, it could "hog" the CPU, and other applications that required processing would stop responding. This was a common frustration with 16-bit operating environments, such as Windows 3.x.

Now that I have told how bad a single message queue can be, let me continue by saying that NT still uses this single message queue for compatibility. This only causes concern if the application fails because it interferes with the other 16-bit applications in the same VDM. It does not, however, interfere with the rest of the system and other applications that are run outside of that VDM.

In the Win16 environment, we learned that these applications are run in a VDM. This VDM is a single-threaded process. This means that the program does not spawn many threads like a Win32 program can. This is no great concern; you just are not able to take advantage of NT’s multithreading ability. Threads that are running in User Mode cannot read or write outside their own memory space. This is the protection offered for applications that are running in a separate memory space.

OS/2 application support in Windows NT is not as strong as it is for DOS and Windows applications. This is due in large part to the scarcity of OS/2 applications and the limited popularity of the operating system itself. In fact, RISC-based systems do not even support OS/2 applications, unless they are bound applications, which we will see later. An interesting note is that the primary subsystem for Windows NT, which is currently the Win32 subsystem, was originally designed to be the OS/2 subsystem. It appeared that OS/2 was going to be the dominant desktop operating system, until Windows 3.x gained in popularity.

OS/2 Version 1.x applications are supported in Windows NT. Anything above this version of OS/2 is not supported under NT. The applications that are supported are character-based, rather than GUI-based. For this reason it is very uncommon that you will be running an OS/2 application on Windows NT. Since native OS/2 applications are difficult to find, the older character-based applications are even more difficult to find. You do have the opportunity of forcing the OS/2 applications to use the VDM if they are bound applications. We will learn about bound applications and forcing the DOS VDM later in this section.

There are several components of the OS/2 subsystem used to provide support for OS/2 applications:

Bound applications refer to applications that are designed to run under either OS/2 or MS-DOS. If you run one of these applications, it will run in the OS/2 subsystem if it is available. For RISC-based computers this is the only way to run OS/2 applications. However, you can edit the Registry to disable the application from using the OS/2 subsystem and using the VDM instead. In addition to disabling the OS/2 subsystem, you also can delete it.

Using the VDM to run OS/2 applications rather than the OS/2 subsystem is accomplished through the use of the FORCEDOS command. The command has this syntax:

FORCEDOS application_name

If you use graphical-based OS/2 programs that are also bound, you most likely have to use this command to run them in the NTVDM, because you may not have the Presentation Manager add-on subsystem for these types of applications. In fact, many bound applications will perform better when run under a VDM than the OS/2 subsystem.

You can configure OS/2 applications through the Registry, or through the use of an OS/2 text editor. The Registry entries that are used to configure the OS/2 subsystem mostly involve the path to the executable file used to start the subsystem. The OS/2 applications also use a CONFIG.SYS file, just as older DOS and Windows applications did, to configure startup information. You need an OS/2 text editor to make these adjustments to the CONFIG.SYS file. In Windows NT, the calls to the CONFIG.SYS file are intercepted, and redirected to the OS/2 entries in the Registry. This is to avoid having the CONFIG.SYS altered if you also boot to MS-DOS, or to an operating system that uses the CONFIG.SYS, such as Windows 3.x or Windows 95. Here is the appropriate Registry key for the OS/2 entries:

HKEY_LOCAL_MACHINE\Software\Microsoft\OS/2 Subsystem for

NT\Config.sys

The information found in this key is also under this key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session

Mananger\Subsystems\Os2\Config.sys

POSIX stands for Portable Operating System Interface based on UNIX. The name alone gives you an idea of what POSIX applications are. The POSIX applications are mainly for the UNIX environment, but Windows NT has provided that the POSIX subsystem remain compatible with these applications. There are several standards for POSIX compatibility, and NT is POSIX.1 compliant. The POSIX application must adhere to the rules for compatibility, which include support for hard links, traverse checking, additional time stamps, and case sensitivity. POSIX applications also must be run from the command prompt, due to their non-graphical nature. Refer to Chapter 5 for additional details about the POSIX compatibility.

The components that make up the POSIX subsystem are as follows:

The exam may ask what types of applications are supported in Windows NT. This should be an easy question after what we have covered in this chapter.

The environment subsystems are what enable Windows NT to provide such diverse application support. These subsystems run in User Mode and, in most cases, are not even loaded into memory until they are needed. They are 32-bit, protected, and preemptively multitasked. While they run in User Mode, they must make calls to System Services to access the system hardware. Access to these devices is available only to Kernel Mode components, such as the Kernel, NT Executive, and the Hardware Abstraction Layer. The Kernel is the core of the operating system and is a member of the NT Executive. The NT Executive is comprised of several components that are responsible for their own functions:

Win32 applications are run in the primary subsystem, the Win32 subsystem. This subsystem also is responsible for fulfilling requests by the other subsystems that are running. The Win32 subsystem runs the 32-bit applications in their own memory space, message queue, and address space.

DOS applications are run in the Virtual DOS Machine, which is a 32-bit, preemptively multitasked, separate memory space. They do not have access to the system hardware, but are fooled into believing so by the use of Virtual Device Drivers. Just like Win32 applications, these DOS applications do not crash the system or other applications that are currently running, if they become unstable.

Win16 applications require the use of the NTVDM, but also require another layer of functionality called the WOW environment. This environment must translate the calls between the Win16 APIs and the Win32 APIs. This process is known as thunking. Win16 applications are cooperatively multitasked within the same VDM, but preemptively multitasked with other applications on the system. They share the same message queue and memory space by default. They can run in a separate memory space, which can be configured a number of ways.

OS/2 and POSIX applications are 32-bit, preemptively multitasked, protected environment subsystems, also. They both make use of character-based applications and pass messages to the primary Win32 subsystem. OS/2 bound applications differ in that they can be forced into using the VDM, rather than the OS/2 subsystem.

1. Which facility is used when environment subsystems need to communicate?

1. Process-passing
2. Thread-passing
3. Message-passing
4. Procedure-passing

2. What does CSRSS provide?

1. Security for the subsystems
2. Logon Authentication
3. Translation for the subsystems
4. Error handling for the subsystems

3. What component is responsible for keeping track of the time that threads are being processed?

1. Thread Manager
2. Process Manager
3. The Kernel
4. Object Manager

4. (True/False) The Security Reference Monitor works with the CSRSS and Object Manager subsystem to make up the entire Security model for the system.
5. Which priority class is considered IDLE?

1. Priority level 4
2. Priority level 6
3. Priority level 7
4. Priority level 9

6. Fill in the blanks.

Both the _________________ and the __________________ ran in User Mode in the Win32 subsystem in previous releases of NT, but now have been moved into the Windows NT Executive, which runs in Kernel Mode.

7. Which is not a component of the Virtual DOS Machine?

1. NTDOS.SYS
2. NTVDM.DLL
3. REDIR.SYS
4. NTIO.SYS

8. (True/False). If there is no PIF associated for the application, the DEFAULT.PIF is used.
9. I have a DOS application and three Win16 applications running on the system. When I switch from the DOS application to one of the Win16 applications, they are all unresponsive. What is the best way to remedy this situation?

1. Run each one of the Win16 applications at the priority level of HIGH, so they do not become unresponsive.
2. Run the DOS application at the priority level of LOW, so that it does not consume too many resources.
3. Run each of the Win16 applications in its own memory space, so they do not interfere with each other.
4. Increase the priority level of the NTVDM in which all of the Win16 applications are running, so they will appear more responsive.

10. Which is the proper syntax for loading an application in a separate memory space with a HIGH priority level?

1. START MSPAINT.EXE /SEP /HIGH
2. START /SEP /HIGH MSPAINT.EXE
3. START MSPAINT.EXE /SEPARATE /HIGH
4. START /SEPARATE /HIGH MSPAINT.EXE

11. Which of the following are ways you can start a Win16 application in a separate memory space?

1. From a batch file that uses the /SEPARATE option.
2. From Task Manager by File, then New Task, and then checking the box for Separate Memory.
3. From the command prompt.
4. From the Run dialog box.
5. Creating a shortcut that has the separate memory check box marked.

12. Which is not a component of the OS/2 Subsystem?

1. NETAPI.DLL
2. OS2SS.EXE
3. OS2LIB.DLL
4. OS2.EXE

13. (True/False) The OS/2 Subsystem cannot run OS/2 2.x applications.
14. Which is not a Kernel Mode component?

1. Cache Manager
2. Security Subsystem
3. I/O Manager
4. Local Procedure Call Facility

15. Fill in the blank.