If you have a modern, reasonably fast processor (that is, at least 500MHz), you can take full advantage of all the visual niceties provided by Windows XP's Visual Effects menu. However, if you're running with less than 128MB of RAM, have a processor under 500MHz, or have a slow video card (such as a PCI-based video card or typical motherboard-integrated video circuits), you might want to adjust Windows XP's defaults so that less graphics processing is required (see Figure 25.4).

Figure 25.4. Windows XP Professional's Visual Effects menu offers several animation and effects settings.

If you select Adjust for Best Performance, all the animations and effects shown in Figure 25.4 are turned off. If you select Adjust for Best Appearance, all the animations and effects are turned on. If you use Let Windows Choose What's Best for My Computer, none, some, or all of the animations and effects will be enabled, depending on the speed of your hardware. For example, on my old 800MHz system with a fast AGP video card, all features were turned on except Smooth Edges of Screen Fonts. Select Custom to choose the options you want turned off or on. You can speed up screen displays by turning off options in the Visual Effects menu.

To improve the performance of your computer by adjusting processor, memory, and virtual memory usage, click the Advanced tab of the Performance Options sheet (see Figure 25.5). The Advanced tab provides three ways to affect the performance of your system:

Figure 25.5. The Advanced dialog box enables you to adjust three factors to improve system performance.

These options are covered in the following sections.

Windows XP Professional—like Windows 2000, Windows NT, Windows Me, Windows 9x, and Windows 3.x—incorporates a virtual memory scheme. As you might know already, virtual memory is a method for tricking the operating system into thinking it has more apparent RAM for use by applications than is physically present in the computer. Windows XP uses a hard disk file called pagefile.sys to simulate RAM. Windows XP's Virtual Memory Manager (VMM) constantly tracks the amount of free RAM, and when the available RAM is exhausted, the VMM begins swapping out 4KB chunks of data and instruction code to pagefile.sys. As portions of the data or code are needed, they are swapped back into RAM chips, where they can be used by the CPU. This activity is called paging. The upshot is that more applications and services can run simultaneously than would normally be the case. Paging is a big benefit when the memory required by programs that are actually doing real work at any given time is greater than the amount of physical memory. On the other hand, CPU access to the pagefile on your hard drive is monumentally slower than to your physical system memory, so when paging activity is high, performance plummets.

The default VMM settings applied when you install Windows XP Professional are based on your hard disk space and partition designations. Windows 9x and Me allowed only a single pagefile, although its size could vary. On Windows XP, however, a pagefile is created in the root of the partition containing the operating system, each additional partition can also have a pagefile.sys, and the size of the each file is dynamic. So, if you have several disks or partitions, Windows XP Professional can decrease the size of a pagefile on one partition and shift paging onto another one as available hard disk space decreases.

Because Windows XP Professional is such a huge operating system and today's office suites, games, movies, and graphics editors are bigger than ever before, it's imperative that paging be intelligent and plentiful. This is especially important if your system barely exceeds the minimum RAM recommendation, as you learned in Chapter 2, “Getting Your Hardware and Software Ready for Windows XP.”

If you want to ensure that your hard disk doesn't thrash itself to death and that the system runs efficiently, not making you wait every time you switch between windows or move something around on the screen, you should install at least 256MB of RAM, let Windows manage the pagefile size, and keep lots of free space on your drive.

The default pagefile size is equal to the amount of RAM in your computer plus 12MB. As disk space dwindles, the file can shrink. The minimum can be no less than about 2MB. Usually, you should leave the pagefile at its recommended size, although you might increase its minimum size if you routinely use programs that require a lot of memory—this lets Windows allocate the pagefile space immediately, when there is less chance of having a fragmented pagefile. You can check with the software maker for information about how demanding applications might benefit from increasing the allocation.

You can optimize virtual memory use by dividing the space between multiple drives and especially by removing it from slower or heavily accessed drives. To best optimize your virtual memory space, you should divide it across as many physical hard drives as possible. When you're selecting drives, keep the following guidelines in mind:

The following are some other points to consider when you're adjusting the pagefile:

To change the initial and maximum size of the workstation's pagefile, the file locations, and the number of pagefiles, follow these steps:

You can use the Performance Monitor discussed earlier in this chapter to get a sense of how much virtual memory is being used. To get started, open the Performance Monitor and click the + (plus) button on the toolbar. Choose Paging File from the Performance Object drop-down list. Then add Usage and Usage peak. View the statistics in whatever way you like. Figure 25.7 shows an example. In this figure, you can see that even with 15 programs running, I'm still only at 3.354 percent usage, with a peak of 6.212%.

Figure 25.7. You can check virtual memory usage via the Performance Monitor by adding paging file monitoring for display in the chart.

As you know, Windows XP Professional is a multithreaded, preemptive multitasking operating system. Left to its own devices, it does an extremely good job of balancing user requests with the need for internal system operations and control. The result from the user's point of view is performance that appears to be highly responsive, even though some internal sleight of hand and task juggling might be going on under the hood. You'll really appreciate Windows XP's excellent multitasking capabilities when your system is sharing files and a printer, running a Web server, and at the same time juggling multiple browser windows, an email client, two or three word-processing documents, a spreadsheet, and a photo editor. Sound like your office?

As well as it works by default, one setting can slightly improve overall smoothness of Windows XP Professional's multitasking, depending on what you use your computer for. To set it, do the following:

Normally, Programs is selected, ensuring that the foreground application (the window you're currently working with) gets more CPU time slices than programs running in the background. Time slices are also shorter and variably sized, which results in more responsive action from an application as you work in it. Unless you have CPU-intensive applications running in the background, though, you won't notice a difference in foreground performance.

If you're running something important in the background that bogs down too much when you're doing other foreground work on the computer, choose the Background Services option. Examples might be data acquisition programs, communications programs, Internet Connection sharing, a Web server, or a backup utility. The time slices are doled out in longer portions with this setting.

By default, Windows XP devotes more memory to running programs than to the system cache (the memory used for disk caching and handing background operations). If your computer is used entirely as a workstation and doesn't share folders, drives, or its Internet connection with other computers on a network, this setting should be left alone. However, if your computer is used as a server, and particularly if you have 256MB of RAM or more, change the default for Memory Usage (see Figure 25.5) from Programs to System Cache to improve performance for shared resources.

When you're finished customizing Performance settings, click OK to close the Performance Options dialog box and return to the Advanced tab of the System Properties window.

Since the early days of computing, most computer designs have allowed program instruction codes and data to be mi XEd together in memory. This has many advantages, but it's also made possible a whole category of security disasters, wherein hackers exploit program bugs to write new instructions into the program's data areas, and then fool the program into EXEcuting these new instructions. These program bugs take a lot of time to identify and eliminate, and there are untold numbers of them still lurking about, so programs and operating systems remain vulnerable.

To answer the security threat, some recent microprocessors now have as part of their memory-management hardware a feature that lets the operating system mark the data storage sections of memory as non-EXEcutable, so that the operating system can be notified if a program attempts to execute instructions in them. Starting with Service Pack 2, Windows XP can take advantage of this hardware feature, and calls it the Data Execution Prevention (DEP) option. At the time this section was written, only Intel's and AMD's 64-bit processors provided Execution Protection support, so DEP was available on the 64-bit version of Windows XP, and on the 32-bit versions of XP only while running on the Opteron and Athlon-64 processors in 32-bit mode. However, it may also be provided by newer 32-bit processors, so you should check to see if Data Execution Prevention is available on your computer.

To manage DEP, log on as a Computer Administrator, open the Control Panel, open the Security Center, and at the bottom of the screen double-click the System icon, to view the dialog shown in Figure 25.8. (You can also get to the Data Execution Prevention tab from the System Options/Performance dialog we've been discussing in the previous sections.)

Figure 25.8. If Data Execution Prevention is available on your computer, you can control it from the System Performance Options dialog.

If Windows indicates that your processor does not have the necessary hardware support, the dialog's options will all be grayed out, and you can simply close it and forget about it.

If the options are not grayed out, you should check Turn on DEP for All Programs to enable the feature. Thenceforth, if an application program attempts to execute instructions from protected memory regions, Windows will display a dialog box informing you of the program failure, and will terminate the application.

In almost all cases, EXEcuting instructions in writeable data memory occurs only as a consequence of a serious bug, or during a hacking attempt. There are some rare instances of application programs that legitimately write and execute instructions on the fly—”just-in-time” compilers like Java are an example. Also, some graphics processing applications use self-modifying code to squeeze out every last bit of performance. These programs should be updated by their manufacturer to work correctly under DEP. Until they're updated, however, DEP will not let them run. If you know you can trust a given application, you can disable DEP just for the one application by making an entry in the DEP configuration dialog. Click Add, and then locate the application's EXEcutable filename.

If a device driver fails with DEP enabled, you will get the dreaded “Blue Screen of Death” with the message ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY, and you will have to restart Windows. If this happens, I suggest that you restart Windows in Safe Mode, and attempt to identify, then disable or update the device driver that failed.

Many applications create temporary files to hold information while you're working. These files are usually deleted when the application exits. Sometimes, however, they're not deleted, and they can accumulate, taking up a lot of disk space. To make management simpler, you may wish to control where they are stored. By custom, most applications that do create temporary files create them in the folder named by either the TMP or TEMP environment variable.

By default, both TMP and TEMP are defined in the System Settings list as %userprofile%Local SettingsTemp. %userprofile% is an environment variable that contains the full path to your user profile folder. The net result is that, for my account, temporary files are created in C:Documents and SettingsknittelLocal SettingsTemp.

Now, for maximum security, placing each user's temporary files in a different folder is a good idea. Also, with Fast User Switching active, several users could have applications running at the same time, so placing temporary files in a different folder for each user avoids the possibility of conflicts in the filenames. On my own computer, however, I am not worried about inter-user security, and to make cleanup easier, I personally prefer to place temporary files for all users in a folder named emp on the hard drive with the most space. On my computer this is D: emp.

To specify the location of temporary files for your account alone, set the values of variables TEMP and TMP in the User Settings section. To specify the same location for all accounts, set the values in the System Settings section and delete any settings in the User Settings section.

Another important environment variable is called PATH. This variable lists the folders that Windows is to search whenever you attempt to run a program by typing its name without a path specification. For example, if I type regedit into a Command Prompt window, or into the Start, Run dialog, the Registry Editor window appears. But how does Windows know that “regedit” meant C:windowssystem32 egedit.EXE? The answer is the PATH variable. On my computer, PATH contains this:

D:Perlin;C:WINDOWSsystem32;C:WINDOWS; C:WINDOWSsystem32WBEM;"C:program filesscripts";
  "C:Program FilesSymantecpcAnywhere";c:progra~1winzip;"c:Documents and
  Settingsknittelscripts";c:in;c:at

The value of the PATH variable is a list of folder names separated by semicolons. If a folder name has a space in it, it is enclosed in double quotes, as “C:program filesscripts” and “C:Program FilesSymantecpcAnywhere” are on my computer.

Now, when I type regedit as a command name, Windows searches the folders named in the PATH variable in order, looking for the first one that contains an EXEcutable program whose name is regedit. It finds the standard Windows utility in the second folder, c:WINDOWSsystem32.

Many applications add their own installation folders to the path during installation. Thus, you will seldom if ever need to modify the PATH to provide access to programs that are designed to run from the command line. If you write batch files or scripts, however, it's very useful to put all of these into one folder and to enter this folder name into the PATH, so that you can run your batch files and scripts simply by typing their name.

Because it's so common for users to want to put a personal folder into the PATH, and because mis-editing the PATH variable can prevent Windows from being able to find applications it needs to run, Windows gives the “User Variables” PATH definition special treatment.

In other words, you can enter your own personal folder(s) into the User Variables definition of PATH without worrying about messing up the standard definitions.

For example, a few paragraphs back I showed my computer's PATH setting. It's set up this way: the System Variables PATH definition is

D:Perlin;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSsystem32WBEM;
"C:program filesscripts";"C:Program FilesSymantecpcAnywhere";
c:progra~1winzip;"%USERPROFILE%scripts"

These folders are used for every user on my computer. The User Variables PATH definition contains only my personal folders:

c:in;c:at

When I log on, Windows automatically adds my personal folders after the system-wide folders.

You can also modify the PATH variable by directly setting the environment variable at the command prompt. It's best to do this by adding a new folder at the beginning or end of the existing path list, rather than by replacing the list entirely. Type the string %path% where you want the original PATH contents to appear. For example, you can add the folder c:myfolder to the head of the path list by typing

set path=c:myfolder;%path%

or to the end of the path by typing

set path=%path%;c:myfolder

You also can use this technique to modify the path from within a batch file.

Windows XP provides support for old MS-DOS and Windows 3.x applications through a program subsystem called the Virtual DOS Machine, or VDM. VDM is a program that mimics the hardware and software of a computer running MS-DOS. This program then loads and executes MS-DOS and Windows 3.x programs in a controlled environment. The “virtual” part signifies that an old program running in the VDM thinks it can directly control hardware like the video card and keyboard, when in fact, the VDM intercepts all hardware control attempts and uses Windows XP to carry out the desired operations safely. An illegal or dangerous hardware operation can simply be rejected. No user application program can directly manipulate hardware on Windows XP—that's why it's so sturdy. When you run a Windows 3.x application or an MS-DOS program, Windows XP runs it through the VDM where it can do whatever it wants without the risk of actually crashing the computer.

The Virtual DOS Machine can be configured by several settings and setup files, which I'll discuss in the following sections.

Windows XP creates a separate instance of the virtual DOS machine (VDM) program for each MS-DOS program that you run, but normally all 16-bit Windows 3.x applications are run by one VDM. This is necessary because the old Windows depended on being able to directly transfer data back and forth between programs (or between multiple instances of the same program) by means of shared access to blocks of memory, in ways that modern Windows programs aren't allowed (again, for reliability's sake). The result is that, just like in a real Windows 3.x machine, a Windows 3.x application that crashes can take down the whole VDM, crashing any other Windows 3.x programs (but not, thankfully, Windows XP itself).

Well, unlike death and ta XEs, this isn't necessarily a fact of life. If you don't need your Windows 3.x applications to communicate with each other, you can cause an application to request its own VDM. The memory space that it runs in is then totally isolated, protected from other applications that might run amok. The upside is that one errant Windows 3.x application can't take down another. The downside is that any Windows 3.x applications running in their own memory spaces can't communicate with other Windows 3.x applications as they would in a true Windows 3.x computer. Dynamic Data Exchange (DDE) and services provided by shared Dynamic Link Libraries (DLLs) will not work, thus data- passing between applications is quashed. However, this isn't a big problem for most Windows XP users, because you'll probably seldom use more than one or two Windows 3.x applications at once anyway.

You make the setting to the properties for the Windows 3.x program. As an example, I'll use a Windows 3.x version of the popular Pretty Good Solitaire shareware program. To change the setting, follow these steps:

From this dialog box, you have only to put a check in the Run in Separate Memory Space check box.

The other option, Run with Different Credentials, allows you to select which user name should be used to run the program. This is useful if a program was installed by a particular user, not by the system administrator, but you want all users of the computer to be able to run the program. Select the user who installed the program when prompted by the system.

You can choose to further configure the MS-DOS and Windows 3.x environment by modifying XP's equivalent of the old CONFIG.SYS and AUTOEXEC.BAT files. In Windows XP, as in Windows NT and Windows 2000, these files are called CONFIG.NT and AUTOEXEC.NT. They are the files used to configure each DOS VDM when it starts up.

When you run a DOS or 16-bit Windows application, Windows XP Professional creates a DOS VDM by loading the DOS environment subsystem and sort of “booting up” DOS. In the process, it reads in settings from CONFIG.NT and AUTOEXEC.NT in just the same way the original DOS read CONFIG.SYS and AUTOEXEC.BAT when it booted. The difference is the filenames and the file locations. In this case, the files are in the SYSTEM32 directory (usually WINDOWSSYSTEM32 or WINNTSYSTEM32) instead of the root directory. Each time you run a DOS application in a new window (that is, each time a new VDM is created), Windows XP Professional reads the CONFIG.NT and AUTOEXEC.NT files. The great thing about this capability is that you can change the settings and rerun a program, and the new settings get read and go into effect immediately. It's like rebooting DOS after fine-tuning CONFIG.SYS and AUTOEXEC.BAT—except faster.

Just remember:

The standard settings in CONFIG.NT set up when Windows XP is installed are shown in the following listing. The REM comments have been removed for brevity. (If you upgraded your computer from an earlier version of Windows, your CONFIG.NT may be different, as the installer may have retained some of your previous operating system's settings.)

dos=high, umb
device=%SystemRoot%system32himem.sys
files=20

You can edit the CONFIG.NT and AUTOEXEC.NT files with a simple text editor like Notepad. Microsoft, for some reason, chose not to provide a comprehensive list of the settings permitted in CONFIG.NT in the online Help and Support, so I've listed them in Table 25.2.

If you enter CONFIG.NT into the Search box in Windows XP Professional's Help and Support Center, some of these terms are listed under the Full-Text Search Matches section of Search Results. Click on the individual terms for more information.

The standard settings in AUTOEXEC.NT set up when Windows XP is installed are shown in the following listing. The REM comments have been removed for brevity. (And again, if you upgraded your computer from an earlier version of Windows, your AUTOEXEC.NT may be different).

REM Install CD ROM extensions
lh %SystemRoot%system32mscdexnt.EXE

REM Install network redirector (load before dosx.EXE)
lh %SystemRoot%system32
edir

REM Install DPMI support
lh %SystemRoot%system32dosx
REM The following line enables Sound Blaster 2.0 support on NTVDM.
SET BLASTER=A220 I5 D1 P330 T3

Here's what these do:

Two of the most common enhancements used on MS-DOS computers were DOSKEY and ANSI.SYS. DOSKEY provided enhanced command-line editing: for example, the use of the up and down arrow keys to recall previous commands. ANSI.SYS gave DOS applications a way to easily control the position and color of text output onto the screen. Both enhancements are provided with Windows XP, although they don't work exactly as you might expect.

ANSI.SYS can be made available for MS-DOS programs simply by adding the line device=ansi.sys to CONFIG.NT (or an alternate CONFIG file). Unfortunately, there is no ANSI cursor support provided for 32-bit Windows character mode (console) applications.

Conversely, DOSKEY—which has been enhanced significantly from the old DOS days—functions only in the 32-bit Windows console environment, and even if you attempt to load it in AUTOEXEC.NT, it does not function within the MS-DOS “COMMAND.COM” shell; that is, after you've run any MS-DOS program in the Command Prompt window.

You can work around this limitation by instructing Windows to use CMD.EXE as the MS-DOS shell. Just add the line NTCMDPROMPT to your CONFIG.NT file. However, this may not work if you need to load Terminate-and-Stay-Resident (TSR) programs before your DOS application.

The command prompt window displays a text-mode window that looks a lot like a DOS computer's screen. This window is actually a true 32-bit Windows application, although it can also execute old MS-DOS applications. Settings you make in to the command prompt window affect both the Window itself and any DOS programs run it. In fact, by far the simplest means for altering the DOS environment is via the Properties dialog box of a DOS window. If you need to fine-tune the DOS environment, this is most likely the way you will do it.

When you open a command prompt window or run a DOS-based program, the window defaults to a standard size, background color, and font. Configuration options on the window's Control menu allow you to alter settings for the specific session. Options in the dialog bo XEs also let you save the settings to establish new defaults. You can set the properties like this:

If you're changing the properties for a specific window, the default is to change the properties for this window only. If you want to use these settings every time you launch this program, select Modify Shortcut That Started This Window, and then click OK.

When you make this choice, Windows edits the PIF for the DOS application in question (or the _DEFAULT.PIF in the case of a CMD window), storing the settings.

If you're experiencing difficulties while running specific DOS programs, you should read this section to learn about making deeper changes to the properties settings for them. When you manipulate the properties (via the PIF) for a program, Windows XP Professional fine-tunes the VDM environment for the particular application, allowing it to run more smoothly, or in some cases simply allowing it to run at all.

MS-DOS applications were designed to run in solitude. They assume that they are the only applications running and usually are memory hogs. Often they want at least 640KB of RAM and perhaps even extended (XMS) or expanded (EMS) memory. Running several non-Windows programs simultaneously—especially DOS programs—is just asking for territorial conflict.

To successfully accommodate the DOS-based applications still in use, Windows XP Professional must be ingenious in managing computer resources such as RAM, printers, modems, mouse devices, and display I/O. Significant sleight of hand is required to pull off this task smoothly, but Microsoft has done this fairly well, partly due to the use of PIFs.

PIFs (program information files) are small files stored on disk, usually in the default Windows folder (WINDOWS or WINNT) or in the same folder as the application. They contain settings Windows XP Professional uses when it runs a related application. When you modify the properties of a DOS EXEcutable or shortcut, Windows XP, in turn, edits the associated PIF. With the correct settings, the program runs properly, sparing you the aggravation caused by program crashes, sluggish performance, memory shortages, and other annoying anomalies. PIFs have the same initial name as the application but use .PIF as the extension (123.PIF, for example). When you run an MS-DOS application (using any technique), Windows XP searches the application's directory and the system search path for a PIF with the same name as the application. If one is found, this file's settings are applied to the DOS environment by the DOS environment subsystem before running the application. If no PIF is found, Windows XP uses the default settings stored in a file named _DEFAULT.PIF, stored in the WINDOWS or WINNT folder. These settings work for most DOS applications, but not all; games and educational programs are likely to need the most modifications.

DOS property settings can affect many aspects of an application's operation, such as (but not limited to) the following:

Some DOS programs come with PIFs, knowing you might run them under Windows. PIF settings from a Windows 3.x computer work under the Windows XP environment, so you can copy them to the appropriate directory, or take note of the settings on the Windows 3.x machine and reenter them on the Windows XP machine.

Earlier versions of Windows (namely Windows 3.x) sported more settings for DOS programs, but because Windows XP Professional is more intelligent than its now-obsolete sibling, many of them are history.

To edit these properties for a DOS program, do the following:

Poke through each tab, and use the ? (question mark) button for help on the settings. Educational and game programs will most often require you to adjust the Memory and Compatibility settings.

When you run a command line program or batch file from the Command Prompt window, the window stays open after the program completes, and you can read any messages the program has printed.

However, if you the program or batch file from a shortcut, or by entering its name into the Start, Run dialog, by default the command window will close automatically as soon as the program exits. To keep the window open, follow these steps:

If you don't want every application's VDM to use the same AUTOEXEC.NT and CONFIG.NT settings, you can specify alternative AUTOEXEC and CONFIG files to be used instead, on an application-by-application basis. Here's how:

From the application's Properties page, select the Program tab and click the Advanced button. You then see the dialog box shown in Figure 25.15; here, you can name alternative files to be used. Just enter the names of the files. You should create your own modified files for this use. Start by copying CONFIG.NT and AUTOEXEC.NT from the WINDOWSSYSTEM32 folder to a new folder (the folder of the DOS application in question is a good spot). Then, edit them with a plain text editor such as Notepad.

Figure 25.15. You can specify a custom CONFIG.NT and AUTOEXEC.NT file for a given application.

Windows XP retains and enhances almost all the functionality of MS-DOS. The following sections explain new Windows XP commands not found in MS-DOS, changes to MS-DOS commands, and unavailable MS-DOS commands.

Table 25.5 lists most of Windows XP's command-line commands. Some may be used only by a Computer Administrator.

Table 25.6 lists some changes and improvements to command line programs that date back to MS-DOS.

I'll talk a bit more about some enhanced commands at the end of this chapter, under “Tips from the Windows Pros.”

The MS-DOS commands in Table 25.7 are not available at the Windows XP command prompt.

I can't get my Windows 95 program to work, even if I use the Program Compatibility Wizard.

The Program Compatibility Wizard isn't a cure-all for program compatibility problems, although it can help many otherwise-incompatible programs to run.

Before you decide you simply can't use the program at all with Windows XP, try the following:

These same steps will help you with any program compatibility problem you encounter.

When I run my MS-DOS application, I get the error “Too Many Files Open” or a similar message.

By default, MS-DOS applications run by the VDM are allowed to open only 20 files. Some older programs, especially database programs, want to open more. In DOS or Windows 9x, you'd have added the line

FILES=100

to your config.sys file. In Windows XP, you must add this line to your CONFIG.NT file. Use Search to find this file on your computer, or look in WINDOWSSYSTEM32. Of course, if you specified an alternate setup file for this application, you'll want to change that file rather than CONFIG.NT.

When I run an old MS-DOS application, I see lots of junk characters on the screen, and many occurences of “←[”.

Some older programs that displayed text on the computer screen depended on the assistance of a display driver program called ansi.sys. Ansi.sys isn't installed by default in CONFIG.NT, so you're seeing the control message that your program was intending for ansi.sys to interpret; these should have resulted in color changes or cursor movements.

You need to add the line

device=ansi.sys

to your CONFIG.NT file. Use Search to find this file on your computer, or look in WINDOWSSYSTEM32. Of course, if you specified an alternate setup file for this application, you'll want to change that file rather than CONFIG.NT.

When command extensions are enabled, the following commands have new features or are available for use:

If you like to write batch files, you'll find that changes to the FOR command alone will make your head spin with possibilities. Type help for >x & notepad x to read all about it.

In the following sections, you'll see how to use some of the other enhanced commands to get more done at the command-prompt level.

The cd (Change Directory) and md (Make Directory) commands allow you to change to a different folder and make a new folder from the command prompt as an alternative to using Windows Explorer.

When command extensions are enabled, you can change to a long directory (folder) without putting quote marks around the name:

cd My DocumentsMy MusicMy MP3s

Without command extensions, you'd need to enter the following command:

cd "My DocumentsMy MusicMy MP3s"

Forget the quotes, and you'd see an error message.

Normally, md (Make Directory) can create just one folder (directory) at a time. When command extensions are enabled, you can create a nested series of folders with a single command. For example, this single command creates a series of folders below your current folder. You could use a command like this within the My Documents folder to create folders for your home budget:

md "My Budget4th QuarterTravel"

(Yes, you need the quote marks!)

When you open a command-prompt session in Windows XP, the default prompt $p$g uses $p (current drive and path) and $g (greater-than sign) to display your current location:

C:Documents and SettingsAll Users>

However, if you've mapped a network drive to a drive letter, either with Windows Explorer or the command-prompt NET USE command, all you normally see is a drive letter when you change to the network drive:

S:>

When command extensions are enabled, you can use the following prompt command to display the server name (if any):

prompt $m$p$g

Now, the prompt will display the true network path and the drive letter you're using to access it.

Figure 25.16 shows you how this special prompt command makes life easier for you when you work with network drives.

Figure 25.16. Using prompt $m$p$g to display the actual path to a mapped network drive.

Very experienced DOS users might remember when the ANSI.SYS device driver and complex batch file commands were needed to change the screen color in a command-prompt session. When command extensions are enabled, you can use the COLOR command to do the same thing. And, if you want to use more than one command-line session at the same time, you can color-code each one.

To see a complete list of the color codes you can use, type color /? and press Enter.

Here are two examples:

To change the color of the screen to light blue and the text to light aqua (very easy on the eyes), enter color 9B.

To reset the screen color to its original colors, enter color by itself.

The color command affects on only the current command prompt window. If you later open a new window, the colors are reset to the defaults set on the Color tab of the command prompt window's properties page.