TCS - Ports of Call: DOS System Device Drivers, Part 3

Ports of Call: DOS System Device Drivers, Part 3

by Ken Johnson
Tulsa Computer Society
From the July 1998 issue of the I/O Port Newsletter

Two columns ago we began looking at your computer's system device drivers, the gateway between the inside of your computer and things you need outside. Device drivers are special programs loaded into memory when your computer starts. Typically they provide an interface between the operating system and a piece of hardware. DOS has several built-in device drivers, called system device drivers, which are loaded automatically at bootup. These include:

COM1-- First serial COMmunication port, typically connected to a mouse or modem COM2 -- Second serial communications port, typically connected to a mouse or modem, the one NOT on COM1

COM3 -- Third serial communications port

COM4 -- Fourth serial communications port

AUX -- AUXiliary device, by default the same as COM1

LPT1 -- First parallel port, typically connected to the printer (LPT stands for Line PrinTer)

LPT2 -- Second parallel port

LPT3 -- Third parallel port

PRN -- PRiNter, same as LPT1

CON -- Keyboard and Display (CONsole)

CLOCK$ -- Real-time clock

NUL -- A "Bit-bucket" device that goes to nothing; anything sent to NUL will simply disappear

A:-Z: -- The drive letters

This month we'll conclude our discussion with CON and NUL.

Manning the CON

The CON device driver is used by DOS to handle input from the keyboard and output to the screen. This driver frees DOS from having to know about all the different kind of keyboards and hardware video adaptors. CON is pretty simple; it doesn't know about function keys or screen color. In fact, DOS provides an extended console device driver, ANSI.SYS. ANSI.SYS is an installable device driver, which you have to load in CONFIG.SYS via the DEVICE= command. ANSI.SYS replaces CON, and can exploit hardware features such as that color monitor. (If you load ANSI.SYS then do a MEM /D, the "CON" you see reported there is actually ANSI.SYS.)

CON does have one redeeming feature though. It can be used with the COPY command to create and modify files directly from the keyboard. To create a text file from the keyboard, use CON as the source file specification and the name of the text file you are creating as the target filespec. For example, to create a file called UPDATE.FLG enter
COPY CON UPDATE.FLG

The cursor will jump down one line. Type the lines of text you want, pressing [ENTER] after each line. When you are done with the last line, press [F6] (or Ctrl-Z). DOS will enter Ctrl-Z, the end-of-file marker. Press [ENTER] again and the file is written to the disk.

COPY CON works as a very basic line editor; once you've typed a line and pressed [ENTER], you can't go back and change that line. You'll have to start over if you've made a mistake. (Press Ctrl-Break to cancel the COPY CON process.) Just about any text editor (e.g., DOS's EDIT, Notepad) is easier than COPY CON, but it can be handy for creating "quick and dirty" text files such as flag files indicating that some activity has taken place, or simple batch files.

(I use *.FLG files regularly with batch programs on our network. If the .FLG file doesn't exist, the batch file does some type of update for the user. If the .FLG file is there, it means the update was done and shouldn't be repeated. Since it's not important what's IN the flag file, just that it exists, creating them with COPY CON is a snap.)

Using a similar method, you can add lines to the end of an existing text file with the COPY command's concatenation feature. Let's say you need to add a line to your CONFIG.SYS file. You could use
COPY CONFIG.SYS + CON

This tells DOS to append keyboard input (CON) to the CONFIG.SYS file. You can type in new lines, then press [F6] and [ENTER] when done. The new lines will be added to the end of the CONFIG.SYS file.

One note: if you are using Windows 95 and want to create or append to a file name with special characters such as spaces, put the filename in quotes, like COPY CON "AUGUST 1 UPDATE FLAG"

Also, don't try to COPY CON to a file with the same name as a directory or folder. If so, DOS will end up echoing back what you typed for the file and the "1 file(s) copied" message. Say you have a C:\TEMP directory and you try (from C:\)
COPY CON TEMP

DOS interprets this to be
COPY CON C:\TEMP\CON since the device driver CON exists in every directory. What you are really doing is copying input from the keyboard (CON) to the monitor (CON) -- hence, the echoing.

The Value of NUL

The NUL device is "nothing." This is a virtual device that doesn't go anywhere; anything written to NUL simply disappears into a black hole. So what is nothing good for? A lot actually.

Need to figure out in a batch file whether a directory exists? Simply check for NUL in that directory. As a system device driver, NUL "exists" in every directory. If an "IF EXISTS" test for NUL is false, the directory specified doesn't exist. In this way, your batch files can create directories if necessary, without intervention from the user. Consider this example:
C:
IF EXIST C:\SETUP\NUL GOTO CONTINUE
MD \SETUP
:CONTINUE
XCOPY A:*.* C:\SETUP

If the C:\SETUP\NUL doesn't exist, then the directory is created. When the test is true, the Make Directory is skipped over and the files copied immediately.

This IF EXIST NUL test works on any local disk with a standard FAT file system. The test won't work reliably on network drives, on a HPFS or NTFS file system, or if running 32-bit File Access (such as in Windows for Workgroups). With 32-bit access, for example, the IF EXISTS will always be true, even if the directory doesn't exist.

Another use of NUL is to check whether you have a damaged floppy disk. By copying the disk contents to NUL, you will see any error messages without physically putting the data on another disk. For example, to check the disk in the A: drive, use
COPY A:\*.* NUL

If the disk contains subdirectories, you should repeat the command for each subdirectory so you test all the data areas. You can't use XCOPY /S here; XCOPY tries to create a file called NUL and gives an error because, of course, NUL is a reserved device name.

Since NUL goes nowhere, it's also a way to keep output from commands from appearing on the screen in batch files. Simply redirect the output of the command to NUL, and away it goes. Suppose you copy the DOS commands to a RAM drive (configured as drive E:) each time you bootup -- but don't want to see the "Reading source file(s)" and "xx file(s) copied" message each time (and marvel at how DOS still can't tell one file from two or more files). You could set this up in your AUTOEXEC.BAT as
XCOPY C:\DOS\*.EXE E:\ > NUL
XCOPY C:\DOS\*.COM E:\ > NUL

Note however that this NUL redirection won't suppress the display of error messages, since DOS doesn't use standard output (what we're redirecting) for error messages. If you want to get rid of all output, there's a way using our old device friend CON.

Since CON handles all console input and output, including output to the monitor, if you replace CON with NUL then nothing is going to be seen. This can be done with the CTTY command, which changes the console device for standard DOS input/output. (CTTY can use any of the system device drivers as the new console device, but nothing else.) Put
CTTY NUL
immediately before the commands you want to suppress, and CTTY CON
immediately after, to "turn back on" the monitor and keyboard. One word of warning though, if one of the intervening commands requires input from you (like XCOPY asking if the target is a file or directory), there is no way to see the message or respond to it. Effectively you've frozen your PC, and will have to reboot.

As you can see, the DOS ports, those system device drivers, provide important service to you. With parallel ports you can print, with serial ports you can use the mouse and reach the Internet, and the CON driver takes what you type and shows it to you on the screen. But you can also take advantage of them as we've seen, for printing, creating files, and as batch file utilities. Very friendly ports indeed.


Kenneth E. Johnson is author of "The Lawyer's Guide to Creating Web Pages," and the forthcoming "Lawyer's Quick Guide to E-Mail." He is Assistant Editor of the American Bar Association's Network 2d newsletter, Contributing Editor of Practical Windows magazine, columnist for the Computer for Lawyers Newsletter, and a member of Microsoft's Legal Industry "Ask the Experts" panel. He is also WebMaster of the ABA's www.techshow.com.



For more information on the Tulsa Computer Society click here



This page has been accessed times.
Tulsa Computer Society 1/23/99
Don Singleton, President
djs@ionet.net