Chapter 2: Working with Applications

Exam Objectives

Identify how MS-DOS, 16-bit Windows, and 32-bit Windows applications operate in Windows XP, Windows Vista, and Windows 7

Diagnose application install, start, or load failures with Windows XP and Windows 7

When MS-DOS was first created, very few applications were available for it. Many people chose to use the BASIC programming language to write their own applications. But in short order, people developed faster applications by first using Assembler and then higher-level languages, such as C. These applications served users well for several years. When Windows debuted, Microsoft built in as much backward compatibility for these older applications as it could. Microsoft knew that if the Windows operating system (OS) did not allow older applications to work with it, current MS-DOS users might not want to adopt it. To this day, Microsoft attempts to provide the most backward compatibility possible in its OSes.

When the 16-bit Windows environment, such as Windows 3.0, needed applications, they were developed and they worked well. In later generations, these applications were superseded by 32-bit versions for the newer OSes, and now 64-bit versions for the newest OSes. The newer applications work with data in larger chunks and run faster. In this chapter, you take a look at how all these applications run on your computer.

To properly maintain and diagnose applications, an A+ Certified Professional must be able to manage the installation and removal of applications. In addition to these skills, this chapter also reveals the operating architecture in which applications run. Understanding this architecture allows the professional to diagnose problems quickly. You also examine the level of backward compatibility that is built into the modern Windows OSes, and you explore multitasking.

Installing and Removing Applications

Before you can work with applications on your computer, you need to install them. With the rate at which the computer industry changes, you cannot avoid the need to upgrade or remove applications on your computer as they become obsolete.

The terms application and program are synonymous; they are both programming code that performs a function. In this chapter, though, I use the two terms to mean slightly different things. I use the term application to describe the programming code that represents the functions you want installed on your computer — like a word processing application or a game. I use the term program to describe the programming code that allows you to install the application.

Installing an application

Most applications come with an installation program that must be run to install the application. Some applications (say, the terminal program PuTTY, from www.chiark.greenend.org.uk/~sgtatham/putty) are actually standalone applications that do not require extra files and settings to be created on your computer, but these are rare. Most applications require several files to be installed and often require Registry entries to be created to hold the settings for the application. Because of the complexity involved in copying the files and creating the settings, you use the installation program to ensure that the application is installed properly. The application’s developer decides the name of the setup program, which in many cases is setup.exe or install.exe.

Very few installation programs work in exactly the same way. In general, though, you are asked for the location where you want the application installed. Other options, such as whether you want to create a desktop shortcut to the application or whether you want a specific option to be enabled, are application specific.

The Add/Remove Programs Control Panel applet was created to allow you to manage your installed applications from an easy to use standard interface. When Windows XP was released, the name was changed to Add or Remove Programs, while Windows Vista and Windows 7 call this feature Programs and Features. In all cases, it operates basically the same way. Installing a new program on a Windows XP computer is slightly different from earlier versions of the Windows OS and Windows Vista or Windows 7. Your course of action for Windows XP looks like this:

1. Choose Start⇒Control Panel.

2. Double-click Add or Remove Programs.

Depending on how your interface is set up, Add or Remove Programs might appear in a drop-down list attached to the Control Panel, in which case you just single-click Add or Remove Programs in the drop-down list.

The Add/Remove window appears, as shown in Figure 2-1. Notice the toolbar along the left edge of the window.

3. Click the Add New Programs button on the left toolbar.

The window adjusts itself to your installation needs.

4. Click the CD or Floppy button at the top of the window.

This opens the same Install Program from Floppy Disk or CD-ROM Wizard, which prompts you to insert the floppy disk or CD-ROM that has your installation program.

5. Click Next.

Windows XP scans your floppy disk and CD-ROM drives for a program named install.exe or setup.exe. If either program is present, it is executed. Otherwise, you are asked to provide the path to the setup program for the application you want to install.

6. If necessary, provide the path to the setup program and then click Finish.

If your computer is part of an AD domain, you might also see applications listed in the section of the Add/Remove Programs Control Panel applet called Add Programs from Your Network. You can filter the list by using the Category drop-down list, and install these by selecting an application and then choosing the Add button. This launches the installation program. If you are using Windows Vista, you see an option to Install a Program from the Network in the Programs Control Panel applet.

Windows Vista allows you to do most of your program management through the Programs Control Panel applet, which allows you to do all the same functions, with a different layout, as shown in Figure 2-2.

Windows 7 has streamlined the Programs Control Panel applet even further, and you will only need to use this applet if you want to change Windows features or uninstall a program.

Many applications today are distributed on CD-ROM. When you insert a CD-ROM into your CD-ROM drive, Windows searches for an autorun.inf file and launches the program specified by the autorun.inf file. In most cases, the specified program is the application setup program if the application is not already installed. This AutoPlay feature of Windows makes installing applications even easier.

Removing an application

Most applications also provide a program to uninstall the application when you no longer want it on your hard drive. The path to the program and any switches that are required for it to function are usually stored in the Registry during the installation of the application.

Always use care when working in the Registry; improper changes can leave you in a position where you will be required to reinstall the OS.

The procedure to uninstall or remove a program from a Windows computer is very easy. After opening the Add/Remove Programs Control Panel applet, select an installed application from the list. You are then provided more details about that application, like its size and how often you use it. You will also see one or more buttons beside the application: Change, Remove, or Change/Remove. To change the installed components of an application, click the Change button; to remove the application, click the Remove button. Some applications will have a Change/Remove button, which will then allow you to make changes to the list of installed components, or to remove the application; it uses the same program to accomplish both tasks. Windows looks up the name of the uninstallation program to run in the Registry and executes it. In Windows Vista and Windows 7, you will use the Programs Control Panel applet and the Uninstall a program option, which provides the same type of information if additional columns are enabled, as shown in Figure 2-3.

Like the installation procedure, there is no set uninstall procedure, and it is left up to the software developer to design the uninstall routine. Some developers do an excellent job, and others do not. In the case of applications that do not uninstall properly, you might find the icons, files, or Registry entries still present after the uninstall program has completed. If that is the case, manually remove the leftover components.

Make sure that you are familiar with the standard method of adding and removing applications from your system through the Add/Remove or Programs Control Panel.

In many cases, applications are removed by using special options with the setup program that originally installed them. One nice feature of using the setup program is that many developers allow you to not only remove the application, but also to change the components that are installed.

Getting the Most out of Multitasking

Multitasking is a computer’s ability to balance the processing time given to multiple applications that are running at the same time. Multitasking comes in handy when running multiple applications at the same time.

The two basic types of multitasking are cooperative and preemptive. In this section, I discuss differences between the two types of multitasking; by the end, you should have a clear picture of which one is better.

Cooperative multitasking

Cooperative multitasking means sharing time on the processor by cooperation. By its name, you would think cooperative multitasking is the better form of multitasking. This is probably because cooperation has always been thought of as a good thing. If you needed to get a job done (like building a house) and you had five people to help you, you could get the house raised quickly through teamwork and cooperation. This is a good illustration of when cooperation works. However, if a couple of those people do not work with the rest of the team (they go to get more nails and never come back), their lack of cooperation slows down the process.

Likewise, with cooperative multitasking in the computer environment, a few programs that do not cooperate well with others can slow down the process. If you launch Microsoft Excel, for example, and start a large recalculation of the entire spreadsheet, Excel occupies 100 percent of the processor’s time. At periodic intervals, Excel checks whether any other programs require processing time, at which time Excel turns control of the processor over to the other applications. Each application follows the same process that Excel does; they occupy 100 percent of the processor’s time if needed, and give up control only when they reach their periodic interval for checking with the rest of the OS. If a program doesn’t check with the other applications often enough, it is thought of as a noncooperative program. The big problem with noncooperative programs is that they can hog 100 percent of the processor time for as long as they want.

Cooperative multitasking was implemented to allow multitasking in a 16-bit Windows environment. Most of that environment was single threaded, meaning that only a single element (or thread) in the OS gives the processor instructions. As such, all applications have to work while sharing a single thread of execution. It might seem that cooperative multitasking is inefficient, but cooperative multitasking is better than no multitasking.

Preemptive multitasking

Preemptive multitasking takes a different approach to multitasking in the Windows environment. With preemptive multitasking, the OS decides which applications get execution time. Preemptive multitasking is designed to work in a 32-bit multithreaded environment, in which applications have multiple execution threads, and the OS can manage multiple threads issuing instructions to the processor or processors. Each thread of operation can run on any available processor in the computer.

Each application is given a certain percentage of execution time to use during each second. The OS then manages each process that accesses the processor. With the OS acting as the conductor, sharing the processor is more equal, with fewer conflicts. This does not mean that certain tasks do not attempt to run away with all the processor’s computing time; it is just less likely to happen. Preemptive multitasking entered the Windows OS with the development of Windows NT, and has been improving ever since.

Running 32-Bit and 64-Bit Windows Applications

The 32-bit Windows applications are the ideal type of applications to run under a Windows 32-bit environment, and 64-bit applications are the ideal type of applications to run under a Windows 64-bit environment. All versions of Windows support 32-bit environments. Starting with Windows XP, all Windows OSes have a 64-bit option when running on 64-bit processors. Because all these OSes are 32-bit or 64-bit in nature, it only makes sense that the applications that are run in these environments are also 32-bit or 64-bit. With that said, you should understand the benefits of running 32-bit and 64-bit applications and how those applications are executed in Windows environments.

Benefiting from 32-bit applications

There are several benefits to running Windows 32-bit applications instead of 16-bit applications, such as

Multithreading

32-bit data transfers

Process isolation

One of the greatest benefits of 32-bit Windows applications is the ability to be multithreaded. Multithreaded applications run several threads of code concurrently. Each thread usually is assigned to a specific task. In the case of Microsoft Word, different threads can process typed characters, check spelling, or check grammar in your document all at the same time. If your computer has only one processor, only one task is actually performed at any given instance even though scheduling of all these different tasks is optimized. If you are lucky enough to have a multiprocessor computer, each thread can be assigned to execute on a different processor. This not only optimizes the execution of the program but also evenly uses the processors.

The 32-bit Windows applications work with data in 32-bit blocks, just as 16-bit applications work with data in 16-bit blocks. In any given clock cycle, a 32-bit application should be able to process more information than a similarly written 16-bit Windows application. In a perfect world, the speed factor of a 32-bit application would be twice that of a 16-bit application. Because we do not live in a perfect world, though, this multiplier is not actually realized. Other factors that affect the performance of the application include how the logic in the code was optimized to allow these 32-bit blocks to provide better performance.

The 32-bit Windows applications also run with some level of isolation from other applications that are running on the system. This provides better stability for the applications that are executing.

Ensure that you can recall the benefits of using 32-bit Windows applications on your system, rather than 16-bit Windows applications.

When running 32-bit applications on a 64-bit version of Windows, the application runs in a 32-bit emulated environment called Windows on Windows 64, or WoW64. This allows the applications to run without any modifications.

Benefiting from 64-bit applications

Microsoft now offers a 64-bit version of all current Windows OSes to run on computers with 64-bit processors. Like with 16-bit versus 32-bit applications, applications need to be rewritten and compiled to take advantage of this faster 64-bit architecture.

The 64-bit applications offer all the same benefits of 32-bit applications, such as multithreading. They have the additional benefit of 64-bit data transfers and processing units, which theoretically would provide a huge speed improvement over 32-bit processing.

Executing in the Windows environments

The architectural diagram of Windows XP is shown in Figure 2-4, and all newer versions of Windows use a similar architecture. Note that 32-bit Windows applications (or 64-bit Windows applications) are executed as separate processes in the user mode portion of the OS. This architecture is identical to that of Windows XP.

In Windows, 32-bit and 64-bit Windows applications are executed in an area that is completely separate from where the OS executes processes. This provides the best stability for both the OS and the applications that are running in it, but does hinder some of the backward compatibility of the product. This does not mean that Windows is not backward compatible, but rather that it is less backward compatible than the previous generations. There have been attempts to increase the backward compatibility of the Windows product line, so applications that may not have worked with earlier versions of Windows may work under Windows XP, and applications that might not have worked under Windows XP may work under Windows Vista or Windows 7.

Each 32-bit and 64-bit Windows application is given

Its own address space to work with: If an application hangs or crashes, the separate memory address space makes it easy to destroy or flush the entire memory that deals with that application.

A separate message queue: By having a separate message queue, if an application hangs or crashes, that halted application doesn’t block the messages that are destined for other applications.

The ability to own several threads that are preemptively multitasked by the OS: Multiple threads per application allow the application to perform multiple operations at the same time.

Running 16-Bit Windows Applications

The 16-bit Windows applications were originally designed to run under Windows 3.x. Some of these applications look for specific components in the OS to function properly. To support 16-bit Windows applications, Windows emulates the 16-bit Windows environment called Windows on Windows. (You can read about WoW earlier in this chapter.) The way in which this emulation is performed represents one of the big differences between versions of Windows.

The 16-bit Windows applications are single-threaded applications that actually share a single unit of execution with the 16-bit Windows environment. This is what I referred to earlier in the chapter as cooperative multitasking. The entire 16-bit Windows environment executes via a single processor thread. This thread is then shared among all 16-bit Windows applications running in the 16-bit Windows environment.

The 16-bit Windows programming code is nonreentrant, which means that each section of code can be executed only once (or by one application) at any given time. When one application starts executing a section of code, it sets a flag — the Win16Mutex — on that code. While the flag sets on the code, no other application can execute or enter that code. This is done to prevent multiple applications from executing the same section of code, thereby causing system-wide problems. One of the problems caused by the Win16Mutex flag is that any other program that wants to execute that section of code must wait until the current program finishes and the flag is removed. If the current application freezes, hangs, or crashes, it never removes its flag; thus, the code is not released until the system is rebooted.

All 16-bit Windows applications suffer from these problems. Whenever possible, 16-bit applications should be replaced with equivalent 32-bit or 64-bit Windows applications to create an environment that is more stable and offers greater performance.

Executing in the Windows environments

Running 16-bit Windows applications under current versions of Windows is very similar to running them under a 16-bit version of Windows — but, very similar does not mean exactly the same. The areas of similarity include the following:

16-bit Windows applications run in a common memory space.

16-bit Windows applications share a common message queue.

16-bit Windows applications cooperatively multitask.

Even with these similarities, note a number of differences between current versions of Windows and the 16-bit versions of Windows. These differences start with where the application code is actually run. Within Windows, all 16-bit Windows applications are executed from within a 32-bit or 64-bit Windows NTVDM (Virtual DOS Machine). This NTVDM is a complete, emulated DOS environment onto which a complete emulated 16-bit Windows environment is loaded. It is within this environment that 16-bit Windows applications are executed. Although this seems like a small point, it means that the entire 16-bit Windows environment that is implemented is contained within a newer Windows 32-bit or 64-bit environment. That makes the entire environment as safe and stable as any other Windows application running on the system.

Within the emulated 16-bit Windows environment, all normal rules that apply to 16-bit Windows still apply, but they can affect only the other applications within the running NTVDM. Applications are still cooperatively multitasked. There is still a Win16Mutex flag, and code is still nonreentrant, but the reentrant code and other processes that can be halted are limited to this one environment. When you consider the separation of 16-bit applications and the fact that current Windows does not contain any 16-bit code at the OS level, this gives current versions of Windows a major stability advantage over Windows 9x and 16-bit versions of Windows.

Another advantage to using current Windows environments is that 16-bit Windows applications can be run in separate memory spaces. When a 16-bit Windows application runs in a separate memory space, a new NTVDM is loaded along with a new WoW environment, as shown in Figure 2-5. The benefits of running applications in separate memory space are preemptive multitasking between applications and process isolation. Although the application still cooperatively multitasks within this Windows environment, there are no other applications for the clock to share cycles with. Because the entire 16-bit Windows environment is run within a 32-bit Windows process, the 32-bit Windows process preemptively multitasks other 32-bit Windows processes running on the system. With process isolation, each application can be run within its own 32-bit Windows process. It is important to note that 16-bit Windows applications cannot be run on 64-bit Windows Vista or Windows 7.

The benefit of separate processes is that when one 16-bit Windows application hangs or crashes, it does not affect any other application running within other processes on the system. Any other 16-bit Windows applications running in the same process as the hung application are halted. Windows uses the default memory space to run all 16-bit Windows applications, with the exception of those run in separate memory spaces. A process running in a separate memory space is the only process that may run in that memory space.

The following is a list of are several ways to start a 16-bit Windows application in a separate memory space:

At a command prompt: Use start /separate <application name>

Creation of a shortcut to modify the properties on the Shortcut tab to run in a separate memory space, as shown in Figure 2-6

Modifying the Open command for an associated file

Check out Book V, Chapter 4 for step-by-step instructions on altering the Open action for a file type.

Any of the preceding methods allow you to launch a 16-bit Windows application in a separate memory space, where it can run in isolation from other 16-bit Windows applications.

Terminating an application running under Windows can be accomplished through Task Manager. Access Task Manager by pressing Ctrl+Alt+Delete and clicking the Task Manager button; or, right-click the taskbar and choose Task Manager. Task Manager has at least five tabs:

Applications: All running foreground applications

Processes: All running applications — foreground and background

Performance: Performance statistics about your computer

Networking: Performance statistics on your network interfaces

Users: All users who have applications running on the computer

You can terminate an application from either the Applications or the Processes tab by selecting the application and clicking the End Task button. To terminate the entire 16-bit Windows environment, select the NTVDM that contains the application and then click the End Task button.

You have seen the benefits of running applications in separate memory spaces, but you should also consider the drawbacks. Here are two drawbacks to running applications in separate memory spaces:

Applications that communicate with each other through a shared memory address will not be able to communicate because there will not be a shared address. Microsoft lists this as a minor problem because very few applications that you will run actually perform this type of communication. (This has never been an issue with any of the applications I have worked with.)

You use additional system resources for every NTVDM and WoW loaded into memory. The overhead associated with loading these resources is about one-half megabyte for each NTVDM/WoW combination. This might not seem like a lot, but if you are running a large number of applications, it does add up.

You should now feel comfortable about how each OS supports 16-bit Windows applications, and the options which you are able to control, modifying how the 16-bit applications function. As a CompTIA A+ Certified Professional, knowledge of these environments will allow you to address issues with applications and provide compelling reasons for late adopters to upgrade to the current Microsoft Windows OS.

Lab 2-1 gives you some practice examining the resources used by WoW. This lab requires that you obtain copies of specific 16-bit Windows applications from a copy of Windows 9x. These applications will be copied into the c:labfiles folder on the lab computer. For this lab, use Windows XP.

Lab 2-2 gives you practice starting applications in their own memory space. This lab assumes that the required lab files have been installed to your disk, using the default installation path of c:labfiles. If you have not completed Lab 2-1, follow the steps at the beginning of that lab exercise to get the proper files in your labfiles directory. You can use Windows XP for these lab exercises.

The labs can be downloaded from the website www.dummies.com/go/aplusaio.

Encountering incompatibilities

When running 16-bit Windows applications within Windows, you might find incompatibilities with your OS. Most developers want to make their applications run as fast as possible. This could mean that they follow nonstandard programming practices under early versions of Windows, which can actually cause problems when you attempt to run these applications under newer versions of Windows.

For example, if you developed a fax application, you might use all standard Windows COM driver system calls to communicate with the modem. Upon investigating how the COM calls are actually made, you might decide that you can achieve more speed through the application by making direct hardware calls. Direct hardware calls represent nonstandard communication with that COM device. This will not affect your application when running within the 16-bit Windows environment; but, when running within a simulated 16-bit Windows environment, such as Windows XP, these nonstandard calls might not be properly processed.

Part of the problem arises from the fact that in an attempt to provide better system stability, current versions of Windows, such as Windows 7, restrict direct access to most hardware components.

If an application requires direct hardware access to these components, it simply will not function under these newer versions of Windows, such as Windows 7. Microsoft has taken all possible steps to improve the ability to run older Windows-based applications, but will not take actions that will substantially reduce the stability of the OS.

Running MS-DOS–Based Applications

MS-DOS–based applications represent the oldest type of applications you are likely to run on your computer. MS-DOS applications are supported by Windows XP. MS-DOS–based applications have always been designed to run alone on a computer. They expect to be the only application ever running on that PC, and as such expect to see certain things, like no Windows presence. Microsoft uses virtual machines to provide a unique environment for these applications. These virtual machines simulate all the hardware that would normally be found in a computer, including

Keyboard

Mouse

Monitor

COM ports

RAM

Disk drives

With all these components being virtualized, an MS-DOS–based application believes that it is running alone in a computer. The virtual computer’s settings can be modified through a program information file (PIF), which I discuss in the next section.

Program information file (PIF) settings

Every MS-DOS–based application that executes on your computer starts by configuring a working environment from settings found in a PIF. This is the case even if you are not aware that a PFI file is being used because a _default.pif file on your hard drive is used if no other PIF exists.

If you want to create a default PIF for a specific application, right-click the application and choose Properties. Even though there is not currently a PIF for the application, you will see all the PIF-related tabs, such as Screen, Memory, Font, and Misc. If you make any changes to the application settings on the tabs and click OK to close the dialog box, a file named <application>.pif is created in the same directory as the application executable. This PIF then becomes the default PIF for that application because it is in the same directory as the application and is named <application.pif>. Unlike most files, the .pif extension stays hidden, even if displaying file extensions is enabled.

You can discern a PIF file by viewing the properties of the file (right-click it and choose Properties). The file type will be Shortcut to MS-DOS Program; and the Font, Memory, Screen, and Misc tabs are specific to PIF files, as shown in Figure 2-7. At any time after closing the dialog box and the default PIF has been created, you can make changes to it by right-clicking either the application or the PIF to bring up Properties; either action allows you to edit the settings. Even though you can access the settings through the properties of the application, you are really editing the PIF.

You might also be confused by the fact that a PIF for an application looks exactly like a shortcut for a LNK file. Figure 2-8 shows a series of PIFs created for four MS-DOS–based applications. Notice that the first four icons in the window are MS-DOS application icons, and the last three icons are the default PIFs for the fdisk.exe, format.com, and scandisk.exe applications. In addition to the default PIF, edit.com has three additional PIFs that have been created for it (the keyboard-looking icons in the middle of the window). Each edit.com PIF can have its own unique settings. To access the settings for a PIF, right-click it and choose Properties. The Properties window of a PIF contains seven tabs:

General

Program

Font

Memory

Screen

Misc

Summary

Each tab is discussed in more detail in the sections that follow.

General tab

The first tab in the PIF Properties window is the General tab, and it is the same as the General tab for any other file on your hard drive. The General tab lists the file type you are viewing the properties for, which is a Shortcut to MS-DOS Application. This tab also lists the location of the file; its size and size on disk; when it was created, modified, and accessed; and its attributes. You should also note the size of the PIF file. PIF files are very small (usually only 1K). You can differentiate a PIF from other shortcuts on your hard drive by its file type because other files with a shortcut arrow are identified only as Shortcut — not as Shortcut to MS-DOS Application.

Program tab

From the Program tab, you can configure the following settings:

Cmd Line: Specifies the path to the executable

Working: Specifies the working directory for the program; often used as the default save directory

Batch File: Specifies the name of a batch file or program that you would like to execute prior to launching the executable but after establishing the MS-DOS environment

Shortcut key: Specifies a keystroke that can be executed at any time to either launch or switch to this program

With much trying, this author very rarely has seen the shortcut key in a PIF work the way it is supposed to. Rather than working, it does nothing.

Run: Specifies whether the program is supposed to run in a normal, maximized, or minimized window

Close on Exit: Specifies whether the application should close its window when it completes execution

Having the program close on completion sometimes hides error messages that could be useful for troubleshooting.

Note the two buttons at the bottom of the Program tab:

Change Icon: Change the icon used by the PIF

Advanced: Modify some additional settings

Changing the icon is purely cosmetic, but you can specify an icon from any Windows-based executable or from a few of the system DLLs. Every Windows-based executable contains an icon list (with the first icon in the list having an index number of 0) that includes the executable’s icon (icon number 0) and icons for its documents or files. Icons can also be found in several system DLLs, such as moricons.dll, pifmgr.dll, and shell32.dll. shell32.dll contains many default system icons that Windows uses.

Clicking the Advanced button brings up the Windows PIF Settings dialog box, from which you can override the default autoexec.bat and config.sys files. The default files — autoexec.nt and config.nt — are found in the %SystemRoot%system32 directory. These two files are used to create the default MS-DOS environment for Windows NT–based OSes. You can create new files with any names and specify the files here. There is also a check box to enable compatible timer hardware emulation, which reduces the rate at which the computer sends timing signals to the application. In short, it makes the application think that it is running on a slower computer.

If you want to modify your autoexec.nt and config.nt files, you will need to use a text editor like notepad.exe.

In Lab 2-3, you create a PIF to launch the MS-DOS edit command. You can perform this lab using Windows XP, Windows Vista, or Windows 7. The labs can be downloaded from the website www.dummies.com/go/aplusaio .

Font tab

Use settings on the Font tab to specify the type(s) of screen font(s) that can be used by the window that contains the running MS-DOS application. These fonts can be

TrueType: TrueType fonts are created on the fly by using a formula, and thereby can be scaled to any size.

Bitmap: Bitmap fonts are drawn with pixels or squares to a specific size. Bitmap fonts are faster to draw, but do not scale.

By default, Windows uses both and chooses the best font based on the window size.

Memory tab

The Memory tab enables you to specify limits for application memory. You can configure four types of memory:

Conventional memory

Expanded (EMS) memory

Extended (XMS) memory

MS-DOS protected-mode (DPMI) memory

The default setting for each of these types of memory is either Auto or None. For more information about the different types of memory and how to configure them, consult www.dummies.com/go/aplusaio.

For MS-DOS applications, conventional memory is where the application actually operates. When MS-DOS first hit the market, computers made use of only the first 640K of memory that was installed, with the rest of the 1024K being used to access hardware components and for drivers to load. Windows applications, which came out later, were designed not to use this area, allowing MS-DOS to continue to use the conventional memory space. Because an entire computer is emulated for MS-DOS applications, this first 640K is also emulated. Although the application thinks that it is functioning in the first 640K of memory, Windows could be using any space that the Virtual Memory Manager has available.

On a normal computer, some of the conventional memory is used to load drivers and TSR (Terminate Stay Resident) applications. A TSR would be similar to service in Windows because it runs in the background. When it is time for an application to run, it might not have all the first 640K of memory available. The Total Memory drop-down menu allows you to specify the amount of Conventional Memory available to the application. When the Total Memory drop-down menu is set to Auto, the application is provided with as much conventional memory as it requests.

It seems odd that more conscientious programs actually have problems with this setting. The conscientious programs query the OS before launching to inquire about the amount of free memory available, but rather than returning a value, Windows asks the question, “How much memory do you want?” This merely confuses the application, which then generates an error message stating that an insufficient amount of memory exists to run the program. If that happens to you, adjust the amount of conventional memory available to the application. This drop-down menu is measured in kilobytes.

You can allocate up to 640K of conventional memory to the application, but you should allocate only what the application truly requires. If your application requires the entire 640K and you are still having problems, you can allocate up to an additional 4K of memory to hold environment variables. This memory is added by making use of the Initial Environment drop-down menu, which is measured in bytes.

There is also an option to protect the conventional memory, which prevents the memory space from being swapped out to the Windows swap or paging file. (Some applications crash when they are swapped out to the swap or paging file.)

Protecting memory should be avoided unless absolutely necessary because it locks the application into physical RAM, reducing the amount of physical memory available for other Windows-based applications.

When dealing with the virtual memory file that is found on your hard drive, older Windows OSes refer to this file as the swap file, and current versions of Windows OSes refer to it as the paging file.

When 640K of memory became too restrictive for developers, hardware vendors developed expansion memory that was able to be added to a computer by using ISA expansion slots, and using a small portion of the memory between 640K and 1024K as a swap area. The application would request certain portions of memory, which would then be swapped from the expanded memory card into conventional memory. This memory was called expanded (EMS) memory. To use expanded memory under older Windows OSes, you have to load the Expanded Memory Manager (emm386.exe) in your config.sys file, which allocates the specific memory address blocks that will be used for the swapping process. After the Expanded Memory Manager is loaded, you can specify as much as 16MB of expanded memory to be available to the application by using the Expanded Memory drop-down menu, which is measured in kilobytes.

As computers started to be produced with more than 1MB of memory, people wanted to make use of this extra memory above the 1MB mark, but MS-DOS natively was able to access only 640K of memory. Extended (XMS) memory is the memory above 1MB. Most MS-DOS applications do not use extended memory because it could only be accessed by Protected Mode applications or OSes like Windows.

Extended memory is sometimes also called Protected Mode memory because it is usually accessed by Protected Mode applications.

If you load a driver like himem.sys, you can access this extended memory. You can allocate up to 16MB of extended memory for the application via the Extended Memory drop-down menu (measured in kilobytes). The MS-DOS environment can use the high memory area provided by extended memory by specifying an option when loading himem.sys in the config.sys file. The high memory area is the first 64K of extended memory — and, through a design glitch, can be accessed directly by MS-DOS to load drivers.

Very few applications use DOS protected-mode interface (DPMI) memory these days, and most of those are games like DOOM and Descent. This memory management technique allows MS-DOS-based applications to use extended memory through special MS-DOS and BIOS calls. The big advantage that is provided by DPMI memory use is that it allows an MS-DOS application direct memory access over 1MB, which provides better performance than using extended memory (which uses swapping to move information between extended memory and conventional memory areas). If your application does make use of DPMI, you can specify up to 16MB of DPMI memory. You allocate DPMI memory specifying the amount in the DPMI drop-down menu (measured in kilobytes).

Screen tab

The Screen tab enables you to specify whether the application is to run full-screen or in a window. You can also set the number of lines of text that will appear onscreen. The default is 25 lines, but you can specify as many as 50 lines. The benefit of adjusting the number of lines on the screen is that you can display more data at any given time, but many applications don’t accept this setting. If you are running the application within a window, you can specify whether the toolbar is visible and whether Windows should automatically restore your previous settings upon the next startup of the application. These settings and other display settings can be modified on the Screen tab.

Also note the two check boxes that play a big role with video performance:

Fast ROM Emulation: Copies the contents of the video ROMs on your system into RAM to optimize performance. Fast ROM emulation is incompatible with some applications.

Dynamic Memory Allocation: Allocates only a text mode video buffer for the application. Some applications work in graphics mode from time to time; when they do, if this option is activated, Windows dynamically changes the size of the buffer to support graphics mode. Once again, this may cause some applications to crash.

When troubleshooting problems with an MS-DOS–based application, it is worth checking out these settings. You do not necessarily have to disable the settings, but if you are having video-related problems, there is a good chance that the settings should be disabled.

Misc tab

The Misc (Miscellaneous) tab is a grab bag of settings that affect how the MS-DOS application behaves. The settings affect how the program operates in the foreground or background, how it terminates, the number of clock cycles it receives, and the shortcut keys that it uses.

Foreground settings

The first of these settings, Foreground, lets you choose whether the Windows screen saver is allowed to function when the application is active. If your application is running in full-screen mode, it has to be minimized for the Windows screen saver to be active. If your application does not like running from within a window, or while minimized, using this setting could cause problems. Not allowing the Windows screen saver to be active leaves your screen running 100 percent of the time when the application is active in the foreground. This might not be such a big deal, though, because many monitors now have an energy-saving standby feature.

Background settings

The Background settings specify whether the application is suspended when it is the background task, which means it receives clock cycles only when it is the foreground application. If the application requires clock cycles at all times, having it suspended in the background can cause it to crash. Most applications don’t like being suspended when in the background; however, if you have an application that uses a large number of clock cycles, you might want to try this option.

Termination settings

The Termination setting of Warn If Still Active applies to MS-DOS windows that are closed by using the Close box in the top-right corner of the window. This warning setting has been designed to help prevent data loss when the application is improperly closed by displaying a confirmation dialog box that allows you to cancel the closing of the application. When you try to close normal Windows applications, they usually ask you whether you want to save your changes. Closing an MS-DOS–based application by clicking the Close box, though, bypasses the normal Close functions and promptly terminates the MS-DOS session — and, therefore, the application.

You should always exit your MS-DOS application from within the program, using whatever commands or options are required. Unlike Windows programs that have a standard Exit in the File menu, MS-DOS applications usually have their own special commands for exiting or closing the application, such as key combinations using CTRL or ALT, and Q, X, or W.

Mouse settings

The Mouse settings of Quick Edit and Exclusive Mode affect how the mouse functions for MS-DOS–based application. Quick Edit allows you to use Windows-like mouse movements to select, delete, and insert text. Quick Edit applies only to Windows 9x computers, not to Windows XP, Windows Vista, or Windows 7 computers. Exclusive Mode may seem a little odd; when enabled, it locks your mouse into the confines of the MS-DOS–based application. This is an option because some MS-DOS–based applications have nonstandard mouse routines.

Typically, when your application is running in a window, you can move your mouse out of the window at any position around the window and bring it back in at any other position. However, in some applications that use nonstandard mouse routines, the application thinks that the mouse is still in the exit location, while Windows thinks the mouse is at the re-entry location — which leaves your application mouse pointer and your Windows mouse pointer in different locations. With most programs that use standard mouse routines, when your mouse is brought back into the application, the location of your pointer is resynchronized. If your mouse is not synchronized in your application, set your mouse in Exclusive Mode. You can still move your mouse outside the window by using any standard Windows shortcut keys, such as Alt+Tab. When you click the application to make it active again, Windows synchronizes the mouse pointer for you.

Fast Pasting option

The Fast Pasting option uses Windows-based routines, rather than standard MS-DOS routines, for inserting text into your application. This works with most MS-DOS–based applications but causes problems for some. You know that you have a problem when pasting operations cause errors or disable the application, so disable Fast Pasting in these cases.

Idle Sensitivity setting

The Idle Sensitivity setting specifies how your application responds to having its clock cycles reduced. When multiple applications are running on your system, Windows splits clock cycles among all applications that are actively requesting CPU time. When it comes to MS-DOS–based applications, Windows provides clock cycles only to applications that appear to require them. The problem is that some applications that require CPU time do not appear to need it. If an application seems to stall or crash for no apparent reason, you might want to lower its sensitivity to being idle. Selecting this option means that the application receives additional clock cycles even when Windows doesn’t perceive that it needs them.

Windows shortcut keys

The last section on the Misc tab provides a list of standard Windows shortcut keys. This is different from the Shortcut Key on the Program tab, which is used to launch the PIF. If your application uses any of the shortcut keys, you must clear the appropriate check boxes here to prevent the standard Windows-based responses to the shortcut keys. For example, if your application uses the Alt+Tab shortcut and you have not cleared the Alt+Tab check box on this tab, every time you press Alt+Tab you will be switched to another application. Unless you clear the check box here, the Windows shortcut keys always take precedence.

Summary tab

The Summary tab contains summary information about the file. This is a standard tab for all files on current Windows OSes. These properties will be used by the Index Service and can help you locate files on your hard drive. The fields on this tab have no effect on how the PIF can be used.

Understanding incompatibilities

When you examined 16-bit Windows-based applications earlier in this chapter, you looked at potential incompatibilities that could arise from direct hardware access. The same incompatibilities apply to MS-DOS–based applications. If your application attempts to make direct hardware calls instead of standard MS-DOS–based system calls, it will not function under modern Windows OSes. Modern Windows OSes attempt to be backward compatible, but not at the risk of OS stability. Basically, if you have an application that makes direct hardware calls, it will not work under the newer Windows OSes.

Windows Compatibility Modes

Many applications written for DOS or earlier versions of Windows will work with Windows XP and newer Windows OSes with a few minor tweaks. Starting with Windows XP, Microsoft has provided a new set of options to aid with backward compatibility for applications that are not included with the OS. These features are found on the Compatibility tab in the Properties dialog box of the executable, which is shown for an application and a PIF in Figure 2-9.

These options are designed to be used with locally installed applications. You can use them with applications from CD-ROMs or from a network drive, but the settings will not be saved.

Because many applications have been written to take advantage of specific features found in various versions of the OS, the Compatibility Mode section allows you to emulate the following OSes:

Windows 95

Windows 98/Windows Me

Windows NT 4.0 (Service Pack 5)

Windows 2000

This does not emulate the entire OS, but rather disables some newer APIs (application programming interfaces) and emulates some older ones, thereby improving compatibility.

Windows Vista adds the following OSes to the Compatibility Mode section:

Windows XP (Service Pack 2)

Windows Server 2003 (Service Pack 1)

Windows 7 then adds the following OSes to the Compatibility Mode section:

Windows XP (Service Pack 3)

Windows Server 2008 (Service Pack 1)

Windows Vista

Windows Vista (Service Pack 1)

Windows Vista (Service Pack 2)

Another common problem revolves around screen settings. Many times, I have had to change my screen resolution or color depth to run a specific application (and then reset it later). The Display Settings section allows you to automatically change the display settings for the application to one of the following settings:

Run in 256 colors

Run in 640x 480 screen resolution

Disable visual themes

Disable desktop composition

Disable display scaling on high DPI settings

If you have an application that has problems displaying menus or toolbar buttons, you can attempt to use the Disable Visual Themes setting. This removes the modern rendering of buttons, with the Windows XP, Windows Vista, or Windows 7 smoothness, drop shadows, Aero desktop, and so on.

Finally, under Input Settings, you have the option to Turn Off Advanced Text Services for This Program, which disables the features of Windows XP, Windows Vista, or Windows 7 that do speech-to-text and handwriting recognition. The additional APIs running to support those services can cause unexpected input into your application.

Most of the settings that can be adjusted or disabled on the Compatibility tab can also be changed elsewhere, such as the Performance Options, on the Advanced tab of the System Control Panel, which will change the setting globally for the computer.

If you have an old application that will not run properly on Windows XP or Windows Vista, do not forget about the Application Compatibility Settings.

Windows 7’s XP Mode

With the ever-increasing number of security features that are incorporated into new Windows OSes — such as User Access Control (UAC), tightened permissions on file systems and the Registry, and restrictions on service access — more compatibility issues arise for applications that require more liberal access to the computer. Windows 7 brings these security restrictions one step further, and to try to deal with possible compatibility issues for users who are upgrading from Windows XP, Microsoft has provided XP Mode.

The secret of XP Mode is that you are actually running Windows XP on your computer, and that copy of Windows XP is what runs the applications that you cannot get to work with Windows 7. Microsoft provides a Virtual PC image file that contains a Windows XP installation, which can be downloaded at www.microsoft.com/windows/virtual-pc. To install Windows XP Mode, download the current XP Mode file and Virtual PC from Microsoft’s website and install Virtual PC followed by XP Mode. Using the default installation, Windows XP Mode will start at the end of the installation process, starting the Windows XP Mode Setup configuration.

The Windows XP Mode setup will get you to agree with a license agreement, choose an installation folder, set a password for the XPMUser account, enable Automatic Updates, and inform you that drive sharing will be enabled between the Virtual PC machine and your host computer. At the end of the process, the Start Setup button will apply your settings. Setup will take several minutes to prepare Windows XP Mode for its first use.

After installation, you will be able to launch XP Mode by choosing Start⇒All Programs⇒Windows Virtual PC⇒Windows XP Mode. When you run Windows XP Mode, you will have a Virtual PC window containing a Windows XP virtual machine, into which you can install any compatible application. Figure 2-10 shows the installation of WinSCP inside the Windows XP virtual machine running on the Windows 7 computer. Windows XP Mode tracks these application installations and publishes links to them on your Windows 7 Start menu, under Start⇒All Programs⇒Windows Virtual PC⇒Windows XP Mode Applications. If you have other applications that you would like to have published, which did not add the appropriate shortcuts, place the shortcuts in the C:Documents and SettingsAll UsersStart Menu directory on the XP Mode virtual machine.

When launching applications from the Windows XP Mode Applications folder on your Start menu, the applications are launched on the virtual machine, but run in a seamless window. Seamless window means that although the application is running on the virtual machine, all the surrounding windows from the virtual machine are hidden from the user, so it appears that the application is running on the Windows 7 host computer.

Figure 2-11 shows the seamless window running WinSCP, as well as the menu item from which it was launched.

While it is not truly running the applications in Windows 7, Windows XP Mode does provide the user with an experience that is similar to running the applications on his or her Windows 7 computer. If not for Windows XP Mode, some applications could not be used on Windows 7 computers, so this provides you with a valid work-around to those issues. Issues of application compatibility could be enough to hold up a corporate OS upgrade to Windows 7.

Application Install, Start, and Load Errors

Many Windows application errors are related to permissions to the file system when using NTFS and the Registry. Starting with Windows XP, the default permissions restrict changes to files, addition of files to specific directories, and changes to portions of the Registry. In addition to these restrictions, many applications that attempt to directly access hardware will fail. If the application is a modern 32-bit or 64-bit Windows application that is supposed to work with Windows XP or Windows Vista, most installation errors can be traced to not meeting either the minimum installation requirements or permissions.

Microsoft has made these permissions changes to prevent most users from being able to install their own applications and make unauthorized changes to the OS. One way to see whether the problem is with a user installing or launching an application is to temporarily add the user to the local Administrators group and see whether the problem is resolved. If that resolves the issue, you know that the problem is related to permissions to one of these locations.

If you can’t get permissions information from the application vendor or can’t grant the user elevated group membership, the Microsoft’s Sysinternals (http://technet.microsoft.com/en-us/sysinternals/default.aspx) has utilities (such as Process Monitor) that can help you identify the permissions changes required.

Getting an A+

This chapter examines application management from installation to execution. The following points are covered:

16-bit, 32-bit, and DOS-based applications function under Windows 9x and Windows XP, and 64-bit applications if the OS is 64-bit Windows.

There are core architectural differences between 32-bit and 64-bit Windows. Support for applications differs based on the architectural differences of the OSes.

The new application compatibility features in Windows allow it to support a wider range of older Windows applications.

Prep Test

1 Which of the following types of multitasking are supported by Windows XP? Choose all that apply.

A Share-based multitasking

B Equality multitasking

C Cooperative multitasking

D Preemptive multitasking

2 Which of the following types of multitasking provides better sharing of CPU time between processes?

A Share-based multitasking

B Equality multitasking

C Cooperative multitasking

D Preemptive multitasking

3 What Windows 7 feature allows running incompatible applications on the Windows 7 computer?

A Backward Compatibility Mode

B Windows 7 16-bit Mode

C Windows XP Mode

D Windows 7 Mode

4 Which of the following are benefits of 32-bit Windows applications? Choose all that apply.

A They share a common message queue.

B They run in separate memory spaces.

C They are preemptively multitasked.

D They support running multiple applications in one virtual machine.

5 How large is the memory space that each 32-bit Windows application has to work with?

A 16MB

B 1GB

C 2GB

D 4GB

6 Which of the following operating systems support 16-bit Windows applications? Choose all that apply.

A Windows XP

B Windows 98

C Windows 3.1

D MS-DOS

7 How can you preemptively multitask 16-bit Windows applications when using Windows XP?

A Right-click the application icon and choose Launch in Separate Memory Space.

B Choose Start⇒Run, use the Browse button to locate the application, and then select the Start in Separate Memory Space check box.

C Use start /separate <application> in a command prompt.

D This cannot be done.

8 What effect does a 32-bit Windows application have on the rest of a Windows XP system when it hangs or crashes?

A It halts 32-bit Windows applications that are running on the system.

B It halts 16-bit Windows applications that are running on the system.

C It halts MS-DOS-based applications running on the system.

D It has no effect on other applications.

9 What effect does a 16-bit Windows application have on the rest of a Windows XP system when it hangs or crashes?

A It halts 32-bit Windows applications that are running on the system.

B It halts 16-bit Windows applications that are running on the system.

C It halts MS-DOS-based applications running on the system.

D It has no effect on other applications.

Answers

1 C, D. Windows XP supports cooperative and preemptive multitasking. See “Getting the Most out of Multitasking.”

2 D. Preemptive multitasking provides more even distribution of CPU time between applications. Review “Preemptive multitasking.”

3 C. Windows XP Mode provides application compatibility through a Windows XP Virtual PC. Check out “Windows XP Mode.”

4 B, C. A 32-bit application uses separate message queues so that when one application hangs, it does not affect the others. Only 16-bit Windows applications may be run in a common VM. Running applications in separate memory spaces and preemptive multitasking are benefits of running 32-bit applications. Peruse “Benefiting from 32-bit applications.”

5 D. Each application or VM runs in a 4GB memory space. Take a look at “Running 32-Bit and 64-Bit Windows Applications.”

6 A, B, C. Only Windows-based OSes can run Windows-based applications. Windows 3.1 could run only 16-bit applications, and Windows XP and Windows 98 support 16-bit applications in an effort to be backward compatible. Peek at “Running 16-Bit Windows Applications.”

7 C. Using the start command allows you to run applications in separate memory spaces. Look over “Executing in the Windows environments.”

8 D. When a 32-bit Windows application crashes, it has no effect on other applications running on the system. Study “Executing in the Windows environments.”

9 B. When a 16-bit Windows application crashes, it halts other 16-bit Windows applications in the same memory space. MS-DOS–based applications and 32-bit Windows applications should continue to operate. Refer to “Executing in the Windows environments.”