Abstract
This chapter answers common MS-DOS-to-Windows NT 4.0 conversion questions, and discusses important differences between DOS and Windows NT 4.0 that DOS power users need to know. The chapter covers how Windows NT 4.0 compares to MS-DOS, the Windows NT 4.0 MS-DOS subsystem, how to run MS-DOS applications in Windows NT 4.0, how to add 16-bit DOS driver support to Windows NT 4.0, and the Windows NT 4.0 and MS-DOS boot processes.
The longevity and popularity of the MS-DOS operating system, now more than 15 years old, has produced many power users or “DOS jockeys,” as I like to call them. DOS jockeys are users who, either by choice or out of pure need, have become fluent in the ways of MS-DOS. They have learned to live with the various eccentricities involved in using and managing a DOS environment, such as editing Config.sys and Autoexec.bat, using FDISK, or navigating directories with the CD (Change Directory) command. These users have mastered MS-DOS through their familiarity with DOS’s various commands and features.
The most common question asked by DOS jockeys who migrate to Windows NT 4.0 is “How do I do the equivalent of <blank> in Windows NT?” You can fill in the blank with any DOS feature, command, or concept. This chapter answers common MS-DOS–to–Windows NT 4.0 conversion questions, and discusses important differences between DOS and Windows NT 4.0 that DOS power users need to know.
We’ll cover the following key topics in this chapter:
How Windows NT 4.0 compares to MS-DOS
The Windows NT 4.0 MS-DOS subsystem
How to run MS-DOS applications in Windows NT 4.0
How to add 16-bit DOS driver support to Windows NT 4.0
The Windows NT 4.0 and MS-DOS boot processes
COMPARING WINDOWS NT 4.0 AND MS-DOS
At first, you may think comparing Windows NT 4.0 and MS-DOS is unfair, because each operating system was developed at a vastly different stage in the evolution of the PC industry. However, such head-to-head comparisons are inevitable in light of DOS’s continued use in modern computing. In fact, many modern PCs run an only slightly improved version of the same DOS operating system developed more than 15 years ago for the original IBM PC! Amazingly, well over 60 million such computers are still in use today.
Windows NT 4.0 and MS-DOS have little in common besides the fact that both were developed by Microsoft and both can run DOS applications. Windows NT 4.0, as you already know, is a 32-bit multitasking operating system with a flat (linear) address model and an intuitive graphical user interface. MS-DOS is a single-tasking, 16-bit operating system with a segmented memory model (system memory is divided into discrete 64K chunks) and a command-line user interface.
From a technical standpoint, MS-DOS is limited in several ways. To begin with, DOS is largely oblivious to newer, more sophisticated processors. Windows NT 4.0 overcomes this limitation by taking advantage of the potential of such systems, without the artificial limits imposed by DOS. For example, Windows NT 4.0 provides applications access to 4 GB of system memory, rather than to the 640K memory limit of MS-DOS. Also, Windows NT 4.0 takes advantage of the memory-protection and multitasking capabilities of today’s advanced processors; MS-DOS does not. In short, the development of Windows NT represents a significant breakthrough for PC users.
In the following sections, we’ll examine how Windows NT 4.0 supports MS-DOS applications and what DOS users need to know to get the most from their DOS applications under Windows NT 4.0.
THE VIRTUAL DOS MACHINE
As part of its environment subsystem design, Windows NT 4.0 provides DOS application support through its MS-DOS subsystem, also known as a virtual DOS machine (VDM). A VDM is like a “virtual PC” that is dynamically created around a DOS application when you start the program. Applications run as if they were in a regular DOS environment. The Windows NT 4.0 VDM provides excellent support for DOS applications and — with relatively few exceptions — is compatible with the majority of DOS programs.
New to Windows NT 4.0: Although DOS support on RISC-based Windows NT machines is provided through software emulation and is consequently slower than DOS support on Intel-based machines, Microsoft vastly improved this emulation in Windows NT 4.0. Instead of the 80286-based emulation in previous versions of Windows NT, Windows NT 4.0 provides 80486 processor emulation.
Despite their similar appearance, however, Windows NT 4.0’s DOS environment and true MS-DOS are different. To begin with, MS-DOS runs the base operating system and any running applications (including terminate-and-stay-resident, or TSR, programs) in one shared memory space. As a result, applications can easily cross their boundaries in memory and overwrite important operating system or application code, causing a system lockup. Also, MS-DOS is only capable of running one application at a time (referred to as single-tasking). Windows NT, on the other hand, is capable of running many DOS applications simultaneously (i.e., it is capable of multitasking). Individual DOS applications are physically protected from each other as well as from the Windows NT operating system through Windows NT’s subsystem architecture.
In MS-DOS, the need for device drivers and TSR programs to run in the first 1 MB of system RAM creates the infamous “RAM cram” that often prevents large, memory-hungry DOS applications from running properly. Unlike MS-DOS, Windows NT 4.0 does not use real-mode drivers for hardware devices; instead, it uses virtual, 32-bit device drivers that do not take away from the memory available to DOS applications. As a result, it is not uncommon for DOS applications to have over 600K free memory under Windows NT 4.0. Finally, Windows NT does not let DOS applications gain direct control over system hardware; it virtualizes hardware by providing device drivers for all hardware devices. Device-driver calls by MS-DOS applications are then mapped to their equivalent Windows NT 4.0 device driver (if one is available). An important note bears repeating: For a device to function properly in Windows NT 4.0, the device must have a Windows NT 4.0 driver (with one special exception noted in “Using 16-bit MS-DOS Drivers,”). It is important to verify that all your system hardware is on the current Windows NT Hardware Compatibility List (HCL).
Tip for MS-DOS Users: The virtualization of system hardware is a major part of Windows NT 4.0’s reliability. It prevents applications from directly accessing system hardware, an action that can potentially violate system integrity. Although the majority of DOS applications run well under Windows NT 4.0, DOS applications that attempt to directly access hardware (such as COM ports, sound boards, and video adapters) may run slowly or not at all. DOS-based games, which are notorious for direct hardware access, may experience the most problems. To successfully run games under Windows NT 4.0, look for newer games that support the Windows 95/Windows NT DirectX set of application programming interfaces (APIs); these APIs provide fast access to hardware without compromising the system’s reliability.
Caution: If you use software packages that require a special hardware security key (often attached to a parallel port), they may not be able to read the hardware key when running under Windows NT 4.0. Windows NT doesn’t let applications directly access system hardware, which is how hardware keys are usually read. These applications normally will not function without a special Windows NT device driver from the application developer or the hardware key manufacturer. You should contact the software vendor about Windows NT 4.0 support for the application before upgrading to Windows NT 4.0.
THE WINDOWS NT COMMAND PROMPT vs. THE DOS COMMAND PROMPT
If you’ve used DOS for any length of time, you are very familiar with the DOS command prompt (e.g., C:\> ). The DOS command prompt is a by-product of the DOS command interpreter program, Command.com. This command prompt, the primary interface of MS-DOS, lets you issue DOS commands and launch DOS applications.
To accommodate users accustomed to issuing commands via the command prompt, Windows NT 4.0 includes its own improved version of the DOS command interpreter, named Cmd.exe. This program is launched when you select the Command Prompt icon (see Figure 3.1), found in the submenu of Start, Programs.
The Windows NT 4.0 command prompt is much more sophisticated than the DOS command prompt. For example, you can use the Windows NT command prompt to launch any type of executable program supported by Windows NT — not just DOS applications. You can start both 16-bit and 32-bit Windows programs, OS/2 1.x character mode applications, POSIX applications, as well as MS-DOS programs. This capability is a vast improvement over
Windows 3.x, which requires the use of icons to launch Windows programs. In Windows NT 4.0, you can launch these applications directly from the command line. You can also create the applications in new, separate windows rather than in the same window as the command prompt via Windows NT’s Start menu. These features are especially useful inside batch files, which can have either a .bat or .cmd extension under Windows NT.
Special Note: You can launch a version of the DOS Command.com file under Windows NT 4.0. This feature provides a Windows NT DOS session that runs in a 16-bit VDM, rather than in the 32-bit (Win32) session created by Cmd.exe. It is unlikely, though, that you will ever want or need to use Command.com because Cmd.exe provides a superset of Command.com’s features and is a 32-bit application. Whenever possible, you should use Cmd.exe instead of Command.com for command prompt sessions.
Tip: Windows NT 4.0 automatically shuts down a window once a batch file or an application has finished executing. If you want Windows NT to leave a Cmd.exe command prompt window open after an application has terminated, use the following command line in the shortcut for the application (or batch file):
cmd.exe /K program_name
where program_name is the name of the batch file or executable file to be run. The /K option tells Windows NT to leave the command prompt window open after the application has terminated. This option is useful, for example, if a program displays on-screen information that the user needs to see, but then terminates immediately afterward. Without the /K option, the information would appear only briefly and disappear as the window closed.
WHAT HAPPENS TO AUTOEXEC.BAT AND CONFIG.SYS?
One of the first questions experienced DOS users often ask about Windows NT is “How are the Autoexec.bat and Config.sys files used in Windows NT?” While these files still have some function under Windows NT 4.0, their role is not nearly as essential as it is under MS-DOS.
Keepers of the Environment
The only function of the Autoexec.bat and Config.sys files under Windows NT 4.0 is to provide a backward-compatible source for locating and setting DOS environment variables.
Windows NT 4.0 automatically supports MS-DOS environment variables for DOS applications. Environment variables contain special information and values required by DOS (and some Windows) applications to run properly. During startup, Windows NT incorporates any environment variables found in the Autoexec.bat and Config.sys files (including variables set via the MS-DOS SET and PATH statements) into Windows NT’s environment. Apart from inheriting environment variables and path information, Windows NT otherwise ignores the Config.sys and Autoexec.bat files.
Special Note: Windows NT 4.0’s practice of copying environment-variable information is important for users who maintain a dual-boot DOS and Windows NT 4.0 setup or run DOS or 16-bit Windows applications under Windows NT 4.0. DOS and Windows 3.x applications assume you are running under MS-DOS and may modify the Autoexec.bat and Config.sys files if environment variables need to be added or changed. Because Windows NT always scans these files at startup to incorporate environment settings, you are sure to have correct support for the MS-DOS application under Windows NT.
Meet Config.nt and Autoexec.nt
Although Autoexec.bat and Config.sys are simply a source of environment-variable settings, two other files provide similar features for 16-bit DOS and Windows applications in Windows NT 4.0. These two files — Config.nt and Autoexec.nt — are used by default to initialize every VDM started in Windows NT.
Special Note: Config.nt and Autoexec.nt are for DOS and Windows 16-bit application (VDM) support only. Settings in these files have no effect on Windows 32-bit applications.
If you have special device drivers, TSRs, initial programs, or environment variables that need to load for a majority of your DOS or Windows 16-bit applications, you may wish to place references to these items in Config.nt and Autoexec.nt. Remember that whatever you place in the files will be executed before each and every DOS or Windows 16-bit application that runs under Windows NT.
Tip for Windows 95 Users: Autoexec.bat and Config.sys have the same function in Windows 95 that they have in regular MS-DOS; that is, all lines in both files are executed before loading Windows 95. Windows NT 4.0 does not use the files in this manner; it uses them only for environment-variable information. If you maintain special lines in these files for your 16-bit DOS and Windows applications under Windows 95, you may need to copy or move these lines to the Config.nt and Autoexec.nt files.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
