First steps towards system programming under MS-DOS 7/Selected utilities

Chapter 6. Selected utilities for MS-DOS 7

Functions of command interpreter in MS-DOS 7 are complemented and extended by separate executable files (utilities). Several utilities for DOS are supplied within Windows-95/98 OS release. If the origin of utility is not specified explicitly in this chapter, hence, it is one of these Microsoft's utilities, which normally can be found in  directory. Besides these, many other utilities can be successfully used in MS-DOS 7, including those from previous versions of DOS and those written by various private and non-private software vendors.

MS-DOS utilities contain internal help text. It can be displayed, when the utility is launched from command line with a single " " parameter. Rarely other utilities can be encountered, which display help text when are launched with " " parameter or without parameters at all.

Some MS-DOS utilities request DOS version number and wouldn't perform their mission, if the number, returned by DOS, isn't equal to the expected one. It is not necessarily caused by incompatibility: most such version-specific utilities successfully operate under MS-DOS 7, when the Setver.exe driver (5.01-02) substitutes expected version number from its table for the actual DOS version number. Mismatch of DOS version numbers may cause a problem of other kind : when a synonymous utility, belonging to a different DOS version, is encountered in the current directory, the proper utility from MS-DOS 7 can't be addressed via the PATH environmental variable (2.02-02), because DOS begins its search in the current directory and finds the improper utility first. In MS-DOS 7 version-specific utilities are: Attrib.exe, Chkdsk.exe, Command.com, Debug.exe, Diskcopy.com, Doskey.com, Fc.exe, Find.exe, Format.com, Label.exe, Mem.exe, Mode.com, Sort.exe, Subst.exe, Xcopy.exe. There is one obvious solution for this problem: name of each version-specific utility in command line should be preceded by full path. It will be wise to prepare special batch files or file manager's menu entries for execution of version-specific utilities with properly specified paths (examples –- in 9.03). Most examples of utilities usage, presented in this chapter, contain no path specifications. It's implied that the Setver.exe driver, the PATH environmental variable value and file's placements are prepared in advance so that each particular utility can be called just by name.

6.01 ATTRIB.EXE – attribute changing utility
In directories each file is represented by a record (A.09-1). Attribute byte 0Bh in this record specifies file's status and rights of access (A.09-2). Attribute byte 0Bh in record(s), related to particular file(s), can be changed by ATTRIB.EXE utility, launched, for example, in the following way :

where :


 * Notes
 * 1) If attributes are not specified in command line, the ATTRIB.EXE utility shows which of the requested files have been found and displays a summary of their features, including attributes.

6.02 CHKDSK.EXE – disks checking tool
CHKDSK.EXE is a utility for analyzing and repairing FAT (File Allocation Tables) on diskettes and on hard disk drives, formatted with file systems FAT12, FAT16 or FAT32. By comparing data in first and second FAT tables (and in directories as well), CHKDSK.EXE reveals crosslinks and lost clusters. The latter are transformed into files with *.CHK suffix, written in the root directory of the same disk. Having finished the check, CHKDSK.EXE shows a summary of results. Being executed without parameters, CHKDSK.EXE checks the current disk with default settings. Besides this, you may specify the following options :

where :


 * Notes
 * 1) The SCANDISK.EXE utility (6.21) performs the all the checks which CHKDSK.EXE does, and some extra checks besides that. Therefore CHKDSK.EXE is worthy only as an information utility, displaying summary of disk's usage.
 * 2) CHKDSK.EXE shouldn't be applied to network drives, CD-ROMs, and to virtual disks, arranged by utilities Assign.com, Subst.exe and Join.exe.
 * 3) The CHKDSK.EXE utility doesn't check whether the files are readable or damaged.
 * 4) The CHKDSK.EXE utility with  parameter shouldn't be applied to disks suspected of being infected by virus: an antivirus program should be applied first.
 * 5) The CHKDSK.EXE utility shouldn't be applied to disks having from 4085 to 4087 clusters, because it may report nonexistent errors in such disks, and an attempt to fix these errors may destroy stored data.

6.03 CHOICE.COM – choice input utility
The CHOICE.COM utility is intended for arranging interactive menu in the course of batch file(s) execution by command interpreter. CHOICE.COM accepts a character, sent from keyboard or via redirection, and then sets ERRORLEVEL value (3.15-03, 9.07-03) according to the number of the accepted character in a succession of prescribed alternatives. Here is an example of CHOICE.COM usage, charged with its main mission :

where the options are :

Just before prompt message two more optional parameters may be specified :

Errorlevel values, returned by CHOICE.COM, remain intact during execution of interpreter's internal commands and may be taken into account in order to affect further course of batch file interpretation. Errorlevel values can be examined in the following lines of batch file by a succession of "if errorlevel" conditions (3.15-03) or else within a FOR cycle (3.13), assigning errorlevel value to an environmental variable, for example :

In a similar way the FOR cycle can be used to perform conditional jumps with "GOTO L%%Z" command, but for this purpose the expected errorlevel values in parenthesis should be enlisted in reverse order.

Quite different application for CHOICE.COM utility is word parsing. The word to be parsed may be, for example, a path, if you have to check writability of specified disk, existence of each directory in the path, etc. Let's assume that file CHECK.BAT contains an analyzing program, which needs the word to be presented letter-by-letter. For this purpose the CHOICE.COM utility should be used as follows : Here the word to be parsed (example: Anyword) is enclosed in semicolons, which guarantee proper separation of first and last letters. Besides this, semicolons guarantee non-stop execution because of presence of redirected answer (ECHO ;) among allowable alternatives. Prompt message is represented by group of words "Call CHECK.BAT". Being sent to STDOUT, this output message will be redirected into temporary file TEMP.BAT. After execution of the first line the created TEMP.BAT file will contain the following string :

The second of the shown lines calls execution of the TEMP.BAT file. During this execution all letters of the word to be parsed will be presented to CHECK.BAT as its parameters (from %2 and on) and can be analyzed separately one-by-one.


 * Notes
 * 1) If user breaks batch execution by pressing CTRL-BREAK or CTRL-C key combinations, then CHOICE.COM utility returns errorlevel 0.
 * 2) When user presses any other key instead of those expected, CHOICE.COM sends a beep signal (the 07h control symbol) to the console.
 * 3) When CHOICE.COM encounters any error, it returns errorlevel 255.

6.04 COMMAND.COM – command interpreter
Command interpreter COMMAND.COM is a resident program, which presents command prompt, enables execution of commands from command line and automatic execution of commands from batch files as well. File COMMAND.COM contains code of all internal commands, specified in chapter 3.

COMMAND.COM gets control over PC at final booting stage, when IO.SYS interpreter executes the SHELL command (4.26) in CONFIG.SYS file. This first execution loads resident module of COMMAND.COM and arranges its primary (parent) environment with global variables. After that each next execution COMMAND.COM creates a derived (child) environment, inheriting copies of all the variables from the former (parent's) environment.

Contrary to ordinary utilities, COMMAND.COM leaves no reference in its PSP (= Program Segment Prefix, A.07-1) to the parent's PSP, so the parent's environment is preserved hidden with no legal access. Repeated execution of COMMAND.COM enables to change local environmental variables and execute application files otherwise (run step-by-step, for example). Having accomplished its mission, the last loaded resident module of COMMAND.COM can be unloaded out of memory with EXIT command (3.12). Then its derived (child) environment becomes lost with all its variables, active state of the former (parent) resident module is restored, and the former (parent) environment again becomes accessible.

Here is an example of loading the command interpreter, in particular, for step-by-step execution of a single batch file:

where :

Besides the shown parameters, COMMAND.COM interpreter accepts the following options :


 * Notes
 * 1) The  parameter affects keyboard functions used to terminate execution of batch files (1.03).
 * 2) When COMMAND.COM is loaded permanently with  parameter, its first default task is interpretation of AUTOEXEC.BAT file, which is implied to exist in the root directory of the current disk.
 * 3) When execution of AUTOEXEC.BAT is launched implicitly via the SHELL command (4.26), then the %0 parameter inside AUTOEXEC.BAT can't be used to initiate recursion.
 * 4) Having been loaded with  parameter, COMMAND.COM is able to accept commands from other processes or from command file(s) via input redirection (see 2.04-02, 2.04-05, and also note 1 to part's 6.05 introduction article).
 * 5) Being executed, batch files (with  suffix) share a common environment with their interpreter COMMAND.COM. Ordinary executable files (with   or   suffix) get a copy of that environment.

6.05 DEBUG.EXE – debugger and mini-assembler
DEBUG.EXE is a specialized command interpreter (debugger), written by Tim Patterson as an instrument for creation of that operating system, which later has been bought by Microsoft and became known as first version of MS-DOS. DEBUG.EXE helps to find out and to fix errors in both program's executable code and PC's hardware settings. Capabilities of DEBUG.EXE are not limited to a set of its internal commands, because these commands enable to assemble just any machine code and to execute it at once. Of course, DEBUG.EXE is not a tool for writing complex programs; it can't compete with high-level languages. But circumstances dictate other criteria, when you can't rely on known compilers, when you have to examine something or to clear up. If you do it with DEBUG.EXE in CPU's real mode, then all AT-compatible computers obediently submit themselves at your disposal. You'll get direct access to disks, to ports, to memory and to code inside executable files.

Command line for launching DEBUG.EXE may include name of a file to be loaded just at start and prepared for debugging, for example :

where :

If the file to be loaded is not specified in command line, it may be defined and loaded later with debugger's internal commands "N" (6.05-12) and "L" (6.05-10). The retarded loading gives an opportunity to start code's layout from an arbitrary address. This is important, in particular, for assembling and debugging drivers (details in article 6.05-18).

Just as COMMAND.COM interpreter, DEBUG.EXE activates command line editing keys (1.05) and accepts commands from command line. If there is any redirected input (2.04-02), DEBUG accepts it as a sequence of commands instead of commands from keyboard. This feature enables to write command sequences into textual command file(s) and then send it to DEBUG.EXE for automatic execution :

All specifications of the code to be loaded or written may be included into such command files (examples in articles 9.02, 9.06, 9.08, 9.10).

 When interpreter accepts redirected commands from a command file, it loses communication with keyboard via the STDIN channel, and hence data input can't be performed by interrupts INT 21\AH=01h, 06h, 07h, 08h, 0Ah (8.02-02, 8.02-04, 8.02-06). Because of the same reason the interpreter may hang, if there is no command to restore communication with keyboard in the last line of command file. Most often this mission is performed by the "Q" command, terminating each debugger's session. Another way to restore communication with keyboard without termination of debugger's session is shown in article 9.07-02. An enhanced modification of DEBUG.EXE is developed by Paul Vojta. The main difference with the original Microsoft debugger is that enhanced modification is able to "understand" machine commands of modern processors. Archive Debug113.zip, containing version 1.13 (2008) of the enhanced debugger, can be downloaded from site http://www.japheth.de/dwnload4.html. If not specified otherwise, all following articles in part 6.05 are equally applicable to Paul Vojta's enhanced debugger. 
 * Notes

6.05-01 DEBUG.EXE : commands and addresses
Having been started, DEBUG.EXE presents its "–" (hyphen) prompt. It means that DEBUG.EXE is ready to accept a command.

Debugger's commands consist of a one-letter or two-letter instruction name, which may be followed by parameters, separated by space(s) or by comma(s). Separators may be omitted, if their absence in any particular position doesn't cause ambiguity. DEBUG.EXE treats numbers as hexadecimal, upper and lower case letters as identical; the only exception from this rule is data comparison with SEARCH command (6.05-16).

Most often the first parameter following command's name specifies a start point memory address. It may be presented in full form – as a segment address and offset (for example, 1FA5:0100), or with an explicit reference to a segment register (for example, CS:0100), or in a short form – as an offset only (for example, 0100). In the latter case segment will be defined by CS (Code Segment) register for "A" (Assemble), "G" (Go), "L" (Load), "P" (Proceed), "T" (Trace), "U" (Unassemble) and "W" (Write) commands; for other commands it will be defined by DS (Data Segment) register. Offset specifications less than 4 digits long are regarded as having preceding zero(s). For example, offset 100 is interpreted as 0100h.

Initial segment address in all segment registers is the same, allocated by DOS on request of DEBUG.EXE in order to lay the code, which is to be debugged. This code will be written not just from the start of the allocated segment, but from a certain shifted point, defined by offset in IP (=Instruction Pointer) register. Initial setting for offset is 0100h (i.e. 256 decimal). Reserved 256 bytes at the start of allocated segment are known as PSP = Program Segment Prefix (details in appendix A.07-1).

If action of debugger's command is directed to a group of bytes, then this group is defined either by its start point address and length or by start point address (segment:offset) and end point offset. Parameter, specifying size (length) of a group, is marked by preceding letter "L" – for example, L20 specifies a group of 20h bytes. Sum of start offset and length must not exceed FFFFh. If a hexadecimal number in place of length specification is not preceded by letter "L", it is interpreted as end point offset inside the same segment. Separate segment specification for the end point is not allowed. Obviously, end point offset must be greater than start point offset.

Having typed a command, the user initiates its execution by pressing the ENTER (or "CR") key.

The simplest debugger commands consist of nothing more than a single character and don't need much comments :

However, the displayed list of commands presents no intelligible guidelines for their usage. All necessary guidelines are given in this book in the following articles of part 6.05.


 * Notes
 * 1) If you have mistaken typing a command, DEBUG.EXE displays a message "Error" in the following line, and points with a ^ (caret) to the first character it is unable to "understand". Most often just this character is the cause of the error, but sometimes the cause may be a mistake in preceding part of command line.
 * 2) Absolute memory address is calculated as a sum of offset with segment address, multiplied by 10h (i.e. 16 decimal). If segment address is, for example, 1FA5h, and offset is 0100h, then absolute memory address will be (1FA5h x 10h) + 0100h = 1FB50h.

6.05-02 DEBUG.EXE : the "A" (= Assemble) command
The "A" command switches DEBUG.EXE to translation of assembler language instructions (see chapter 7) into executable machine code. This code is not executed at once, but rather is written into memory, thus forming a succession of machine commands. When translation is finished, the formed succession can be executed or saved in a file. Here is an example of the "A" command specification in debugger's command line :

Letter-name of the ASSEMBLE command is followed by address of a memory cell, where the first byte of the formed machine code should be written. In the shown example this start address is represented by an offset only, but it may be specified in any of allowable forms, enlisted in article 6.05-01. If segment is not specified explicitly, then it is defined by segment register CS:. Start address may be omitted at all, and then the start cell is pointed at by contents of registers CS:IP.

Having accepted the "A" command, DEBUG.EXE shows full address of a memory cell, where the first byte of translated machine code will be written, and displays a blinking cursor, thus inviting you to type an assembler instruction, which should be translated. At that moment DEBUG.EXE doesn't accept commands, described in part 6.05, but accepts only assembler instructions, described in chapter 7. The user confirms an end of each assembler instruction by ENTER keystroke. DEBUG.EXE translates the entered instruction, writes its machine code into memory cell(s), and shows a new line with a new full address, inviting to type the next assembler instruction.

In order to terminate translation of assembler instructions you have to ignore debugger's invitation and just press ENTER, while the line is left empty. Then DEBUG.EXE returns to normal interactive operation, shows its hyphen prompt and again becomes ready to accept commands, described in part 6.05. If DEBUG.EXE received assembler instructions from a file via input redirection, then an empty line should be left in this file (7.01-04), and this empty line will force DEBUG.EXE to terminate translation of assembler instructions.

6.05-03 DEBUG.EXE : the "C" (= Compare) command
The "C" command shows non-coincident bytes from two successions of memory cells. Identical bytes are skipped. Command line with a call for the "C" command may look, for example, as follows :

After the letter-name "C" the first and the third parameters are start addresses of those memory cell successions, where are the bytes to be compared. Start addresses may be specified in any of their allowable forms (6.05-01). In the shown example both start addresses are represented by offsets only, and then default segment for both sequences is defined by segment register DS:. The second parameter after letter-name "C" defines either offset of the last memory cell in the first succession or the length of byte successions to be compared (if the number is marked by preceding letter "L"). In the shown example L8 means length 8 bytes. All three parameters after the "C" command are required.

6.05-04 DEBUG.EXE : the "D" (= Dump) command
The "D" command displays hexadecimal contents of a group of memory cells, and at the same time in the right part of display screen shows the same contents, represented by characters and symbols of ASCII code. Here is an example of debugger's command line with a call for the "D" command :

Just after the letter-name "D" there is a full address of the first memory cell in a group to be displayed. Address may be specified in any of allowable forms (6.05-01). If segment is not specified, then it will be defined by segment register DS:. The second parameter after the letter-name "D" defines either offset of last memory cell in a group or a length of that group (if the number is marked by preceding letter "L"). In the shown example L10 means length 10h (i.e. 16 decimal) bytes. If the second parameter is not specified, 80h bytes (i.e. 128 decimal) will be shown. If both parameters are omitted, then 80h bytes will be shown, starting from current offset, which is increased by length of the shown bytes group at each execution of the "D" command. This is why each next execution of the "D" command without parameters will show not the same, but the next group of bytes. Examples of dumps, displayed by the "D" command, are shown in fig. 8–12 (in chapter "Appendixes").

6.05-05 DEBUG.EXE : the "E" (= Enter) command
The "E" command writes new contents into one or more memory cells. Debugger's command line with a call for the "E" command may look like this :

In the shown example the letter-name "E" is followed by address (offset) of the memory cell, where writing of new data should start. When segment is not specified, then it is defined by DS: segment register. Address may be specified in any of its allowable forms (6.05-01), but it can't be omitted. Having accepted this command, DEBUG.EXE shows full address of the requested memory cell and shows the data byte, present in this memory cell at that moment. The shown line ends with a dot, which should be regarded as a prompt to type a new data byte for this memory cell. Data in ASCII codes are not accepted by "E" command via keyboard, data should be presented in a form of two hexadecimal digits per byte. Then a SPACEBAR keystroke should follow. If a new data byte has been typed in, it will be written into memory cell, but if a new byte hasn't been typed, the former contents of this memory cell is preserved. In any case DEBUG.EXE will show contents of the next memory cell, inviting to change it in the same way. If instead of the SPACEBAR keystroke the "–" (minus, or hyphen) key will be pressed, then the user will be given an opportunity of another attempt to change contents of the previous memory cell. In order to terminate data input, you have to press ENTER instead of SPACEBAR.

The "E" command is executed otherwise, without waiting for data input via keyboard, if new input data are specified in the same command line after the memory cell address, for example :

New input data in command line may be represented either by two hexadecimal digits per byte, or as string(s) of ASCII characters, enclosed at both sides in quotes or in double quotes. Both forms of representation may interlace in one line in arbitrary order. Before being written into memory, ASCII characters are translated into hexadecimal form byte-by-byte, except the enclosing quotes, which are not translated and are not stored. If a byte is represented by a single hexadecimal digit, it will be interpreted as the lower half-byte, for example, the "A" digit will be interpreted as 0Ah. In any case data will be written into sequential memory cells, starting from the specified address, in the order of their placement in command line.

6.05-06 DEBUG.EXE : the "F" (= Fill) command
The "F" command fills a succession of memory cells with a repeated record of a single byte or of any given sequence of bytes. In debugger's command line a call for the "F" command may look, for example, like this:

The first parameter after the letter-name "F" is start address of memory cell succession which is to be filled. Though start address may be specified in any of its allowable forms (6.05-01), in the shown example it is represented by an offset only, and then segment is defined by DS: segment register. The second parameter specifies either a length of memory cells succession (if the number is marked by preceding letter "L") or offset of the last cell in that succession. In the shown example length 2Eh bytes (46 decimal) is declared. The third and the following parameters represent that sequence of bytes, which should be used to fill memory cell succession. At least one byte of this sequence must be specified. Data in command line may be represented either by two hexadecimal digits per byte or by a group(s) of ASCII characters, enclosed at both sides in quotes or in double quotes.

Both forms of representation may interlace in one line in arbitrary order. Before being written into memory, ASCII characters are translated into hexadecimal form byte-by-byte, except the enclosing quotes, which are not translated and are not stored. If the data, presented in command line, are not enough to fill the whole succession of memory cells, the process is repeated: the next cells are filled with a copy of the same sequence of bytes. On the contrary, if succession of memory cells is too short, filling process terminates at the last cell without error message.

6.05-07 DEBUG.EXE : the "G" (= Go) command
The "G" command initiates execution of machine code commands, prepared in memory beforehand. Here is an example of debugger's command line with "G" command:

Optional parameters following letter-name "G" are addresses. The first address, preceded by equality sign, points at the first byte of that machine command, which is to start the execution procedure. Though start address may be specified in any of its allowable forms (6.05-01), in the shown example it is represented by offset only; hence, default segment will be defined by CS: segment register. If an address, marked by preceding equality sign, in not present in command line, then the start memory cell will be pointed at by contents of CS:IP registers.

Those addresses, which are not preceded by equality sign, are breakpoints. Up to 10 breakpoints may be specified in command line for different branches of the program under test. In those memory cells, which are pointed at by breakpoints, DEBUG.EXE replaces original machine code by code CCh of INT 03 interrupt (8.01-04).

Interrupt INT 03 handler returns control back to DEBUG.EXE, and then debugger restores original machine code in breakpoint memory cells, and also stores the state of registers and flags, thus preparing further continuation of debugging procedure. For successful termination of the described operations two conditions must be met. First, breakpoint address(es) must correspond to first byte(s) of machine command(s), since otherwise the CCh code will be interpreted not as INT 03 call, but as a part of previous machine command. Second condition is that execution shouldn't be stopped in any other way, besides the prepared breakpoints, because otherwise DEBUG.EXE will not store states of registers and flags, will not restore the replaced contents of memory cells, and the program under test will become corrupted. You'll have nothing to do but reload it with "L" command (6.05-10).

If you have no intention to apply breakpoints, there are two methods to stop execution, initiated by the "G" command. The first is a call for INT 21\AH=4Ch handler (8.02-55), which stops execution, terminates debugger's session and returns control back to DOS. The second method is a call for INT 20 handler (8.02-01), which stops execution, but doesn't terminate debugger's session. The RET command (7.03-73) at original stack's position also induces a INT 20 call with the same consequences. DEBUG.EXE gets control back and begins to accept next command(s) either from keyboard or from redirection – according to the way it was launched. After a stop of execution via a INT 20 call the code under test most probably wouldn't be corrupted, but final states of registers and flags will be lost.

6.05-08 DEBUG.EXE : the "H" (= Hexadecimal) command
The "H" commands calculates and displays a sum and a difference of two hexadecimal numbers, each of up to four digits long. In debugger's command line it may look like this :

In the shown example two parameters after letter-name "H" are original numbers presented for calculation. Any of them or both may comprise less than four digits, and then zero(s) in senior positions will be implied. Presence of both parameters is required.

6.05-09 DEBUG.EXE : the "I" (= Input) command.
The "I" command reads a byte from the specified port and shows it on the screen. The shown byte can't be written elsewhere or stored. A single parameter in command line after the letter-name "I" is port address, for example :

Unlike ordinary memory addresses, port addresses have no relation to segments and segment registers. Port address is just a hexadecimal number of up to four digits long. Zeros in senior positions may be omitted. Addresses of several common ports are enlisted in appendix A.14-1.

6.05-10 DEBUG.EXE : the "L" (= Load) command
The "L" command reads a succession of codes from disk and loads it into memory, starting from specified address and on. Succession of codes to be read may be defined either by a name of a file or by a number of disk's sector. Here is an example of "L" command usage for loading a succession of codes from a file :

Single parameter in the shown example is a memory cell address, where writing of code succession should start. Address may be specified in any of its allowable forms (6.05-01), but when segment is omitted, it is defined by CS: segment register. It is assumed that the name of a file to be read is written already into PSP (A.07-1) by "N" command (6.05-12) or was initially transferred there from parameter of that command line, which has launched the debugger. Moreover, it is assumed that the contents of DS: segment register has not been changed since this name was written into PSP, and hence the "L" command can still refer to segment address in DS: for reading this name from PSP.

Address after the letter-name "L" may be omitted, and then succession of codes will be loaded from address CS:0100 an on, except loading from files with suffixes *.EXE and *.HEX. These files contain a header with supplementary loading specifications.

Supplementary offset from the header of *.HEX files is added to that taken by default (0100h) or to that specified after the "L" command. For *.EXE files the offset specified after the "L" command is ignored, header of the *.EXE files is not loaded. In order to see "as they are" those files loaded without a header or not loaded at all, their suffix should be replaced (preferably with *.BIN). In any case length of the file is stored in CX register. If length exceeds 64 kb, then senior digits of length are written into BX register.

For loading a succession of codes from sectors of logical disk, command line must contain four required parameters, for example:

The first parameter, just as in previous example, is the memory cell address, where writing of code succession should start. The second parameter is interpreted as logical disk number: 0 – disk A:, 1 – disk B:, 2 – disk C:, and so on. The third parameter represents the actual hexadecimal number of the first sector to be read ; the fourth, the number of sectors to be read, in hexadecimal notation. Up to 80h sectors can be read in one operation. In particular, the shown example specifies reading of a single sector number 0 (the bootsector) from logical disk C: and writing its contents into memory starting from address CS:0100. Contrary to loading from files, loading from disk's sectors doesn't induce writing of loaded succession's length into registers. Physical disk's sectors beyond logical disk(s) are not accessible to "L" command.

6.05-11 DEBUG.EXE : the "M" (= Move) command
The "M" command copies a block of data from one place in memory into another. In debugger's command line a letter-name "M" must be followed by three required parameters, for example :

In this example the first parameter specifies start address of the source data block, and the third parameter – a similar start address of the target memory space. Both these addresses may be specified in any of their allowable forms (6.05-01). If address is represented by offset only, then segment is defined by DS: segment register. The second parameter in command line represents either the length of the source data block (if the number is marked by preceding letter "L") or offset of its final byte. Here the second parameter L20 denotes length 20h bytes (32 decimal) of the source data block.

If the source data block and target memory space are not superimposed, then data in the source block remain unchanged. But when target memory space overlaps source data block, data in the overlapped part of this block will be overwritten without error message. In any case the order of copying is chosen so that the bytes to be overwritten are copied first.

6.05-12 DEBUG.EXE : the "N" (= Name) command
The "N" command declares a name of a file, which is to be loaded later by "L" command (6.05-10) or written later by "W" command (6.05-19). Letter-name "N" must be followed by a name of a file, for example :

If suffix of the specified name exists, it can't be omitted. Name of a file may be preceded by a path and may be followed by a group of parameters (as "/S /D" in the shown example).

All data, declared by the "N" command, are written into PSP area (A.07-1) at address DS:0081 and on. Besides that, length of the written string is stored at DS:0080, file's name without suffix – at DS:005D, suffix – at DS:0065. As far as the mentioned addresses refer to DS: segment register, its contents must not be changed up to the moment when the written data will be requested by "L" or by "W" command. When the "N" command is executed without parameters, it overwrites data in DS:005C–DS:0080 memory cells and writes code 0Dh in memory cell DS:0081.


 * Notes
 * 1) Initial settings in CS: and DS: registers are the same. Therefore loading of the program under test below default address CS:0100 may cause overwriting of PSP data (A.07-1), including the stored filename(s). Moreover, loaded code itself may be damaged later because of writing data into PSP by "N" command.

6.05-13 DEBUG.EXE : the "O" (= Output) command
The "O" command sends a data byte into specified port. Letter-name "L" in debugger's command line must be followed by two parameters, for example :

The first parameter represents port address, the second parameter is the byte to be sent. Unlike ordinary memory addresses, port addresses have no relation to segments and segment registers. Port address is just a hexadecimal number of up to four digits long. Zeros in senior positions may be omitted. Addresses of several common ports are enlisted in appendix A.14-1.


 * Notes
 * 1) Incautious usage of the "O" command may affect important PC's settings and cause serious malfunctioning.

6.05-14 DEBUG.EXE : the "P" (= Proceed) command
The "P" command initiates execution of a prescribed number of machine instructions, prepared or loaded into memory beforehand. If execution is initiated by the "P" command, then loops (7.03-55 – 7.03-57), subroutine calls (7.03-08), repetitions (7.02-03, 7.02-04) and interrupts (7.03-28) are not traced step-by-step, but rather are executed as though it were one machine instruction. This feature is the main difference between "P" and "T" (6.05-17) commands. Debugger's command line with "P" command may look like this :

The first parameter after letter-name "P" is address of machine instruction, intended to start execution. This address may be specified in any of its allowable forms (6.05-01), but it must be preceded by equality sign. If address is represented by offset only, as in the shown example, then default segment is defined by CS: segment register. The second parameter specifies the number of machine instructions to be executed. Both parameters may be omitted, and then only one instruction will be executed, the one pointed at by CS:IP.

After execution of machine instructions the "P" command displays current states of registers and flags, and also presents result of unassembling the next, not executed yet machine instruction.


 * Notes
 * 1) The "P" command shouldn't be applied to machine instructions, which are read directly from fixed storage chips or from read-only memory (ROM). For such purposes the "T" command (6.05-17) should be used instead.

6.05-15 DEBUG.EXE : the "R" (= Register) command
If you type into command line a single letter R and press ENTER, then DEBUG.EXE will show you current states of CPU's main registers and flags. Typical initial states of registers and flags, set by DEBUG.EXE at the moment when it is launched, are shown below in fig.1.

Let's notice that in all shown segment registers (DS, ES, SS, CS), the same hexadecimal number is written : it is segment address of memory space, allocated by DOS for debugging experiments. Other registers and flags acquire predetermined initial states. Bi-letteral designations of flag's initial states have the following meaning :

The last line of displayed message (fig.1) shows machine instruction code in memory cell, pointed at by CS:IP, together with unassembled representation of that code. Just this machine instruction will be executed, if DEBUG.EXE will be given "T" (6.05-17) or "P" (6.05-14) command with default parameters.

You may get an opportunity to change flag's states, if letter-name "R" in debugger's command line will be followed by parameter "F" :

DEBUG.EXE responds to this command by showing current flag's states together with a hyphen, which is an invitation to input bi-letteral designations of desired flag's states. Flag's states, opposite to those shown in fig.1, can be set by typing the following input :

The order of flag's states input is indifferent. If new state for some flags is not specified, those flags preserve their former state.

In order to get an opportunity to change a state of a register, letter-name "R" in debugger's command line must be followed by a name of that register, for example :

The shown command opens the AX register for writing new value. The "R" command also enables to open registers BX, CX, DX, BP, SP, DI, SI, CS, DS, ES, SS, IP (and PC – it is another name for the same IP register). Having got the shown command, DEBUG.EXE displays former contents of that register and a colon, thus inviting you to input new value of up to four hexadecimal digits long. If you wouldn't type new data and just press ENTER, the former value in this register will be preserved. The "R" command doesn't provide separate access to senior byte and to least significant byte of 16-bit registers, for example, to AH and to AL inside the AX register. If you want to change the state of only one byte, you have to specify unchanged former value for the other byte of the same register.


 * Notes
 * 1) The 8 flags, mentioned in this article, are not all the flags in modern CPU's. For a more complete list of flags see appendix A.14-4.

6.05-16 DEBUG.EXE : the "S" (= Search) command
The "S" command performs a search for a specified sequence of bytes throughout a limited search region. Both sequence of bytes and search region must be defined by parameters, following the "S" command in debugger's command line, for example :

The first parameter after the letter-name "S" is start address of search region. Though start address may be specified in any of its allowable forms (6.05-01), in the shown example it is represented by an offset only, and then default segment is defined by DS: segment register. The second parameter specifies either a length of search region (if the number is marked by preceding letter "L") or offset of the last cell of that region. In the shown example length 200h bytes (512 decimal) is declared. The third and all the following parameters represent that sequence of bytes, which is to be searched for. At least one byte of this sequence must be specified.

Bytes of the sequence may be represented either by two hexadecimal digits per byte or by a group(s) of ASCII characters, enclosed at both sides in quotes or in double quotes. Both forms of representation may interlace in one line in arbitrary order. Before being taken into account, ASCII characters are translated into hexadecimal form byte-by-byte, except the enclosing quotes, which are not included in the prepared sequence sample. In the course of search similar letters in upper case and in lower case will be considered different.

When the search is finished, DEBUG.EXE shows all addresses in the search region, where the sought sequence has been found. It's important to notice that DEBUG.EXE doesn't analyze the mission of the found bytes sequence(s). Data strings and machine instructions may include just the same sequences of bytes. Solving of such uncertainties is a user's prerogative.

6.05-17 DEBUG.EXE : the "T" (= Trace) command
The "T" command initiates execution of a prescribed number of machine instructions, prepared or loaded into memory beforehand. The "T" command can trace execution of machine instructions inside loops, subroutine calls, interrupt handlers, etc. This feature is the main difference between "T" and "P" (6.05-14) commands. Here is an example of debugger's command line with "T" command :

The first parameter after letter-name "T" is address of machine instruction, intended to start execution. This address may be specified in any of its allowable forms (6.05-01), but it must be preceded by equality sign. If address is represented only by offset, as in the shown example, then default segment is defined by CS: segment register. The second parameter specifies number of machine instructions to be executed. Both parameters may be omitted, and then only one instruction will be executed, the one pointed at by CS:IP. After execution of machine instructions the "T" command displays current states of registers and flags, and also presents result of unassembling the next, not executed yet machine instruction.


 * Notes
 * 1) As far as the "T" command traces execution of machine instructions inside loops, subroutine calls and interrupt handlers, it may involve very long sequences of instructions, taking too much time to trace. In such cases the "P" command (6.05-14) should be preferred.

6.05-18 DEBUG.EXE : the "U" (= Unassemble) command
The "U" command displays assembler instructions obtained by translation of executable machine code from a group of memory cells. A debugger's command line with "U" command may look like this :

The first parameter of the "U" command is an address of the first memory cell in selected group. Address may be specified in any of its allowable forms (6.05-01). If the segment is not specified, then it is defined by CS: segment register. The second parameter after the letter-name "U" defines either offset of the last memory cell in selected group or a length of that group (if the number is marked by preceding letter "L"). In the shown example L10 means length 10h (i.e. 16 decimal) bytes. If parameters are omitted, then code of 20h bytes will be translated, starting from current offset inside CS: segment. Current offset is increased by length of the translated bytes group at each execution of the "U" command, so that each next execution of the "U" command without parameters shows translation of code from not the same, but from the next group of memory cells.

It's important to notice that the "U" command can't discriminate between executable code and other data, can't find the first byte of long machine instructions. When specified start address doesn't correspond to the first byte of instruction, or when unassembling is applied to data, then translation produces garbage. Two examples of unassembling are shown below in fig.2: the first corresponds to proper specification of start address (0181h), the other shows consequences of improper specification.

In case of improper start address specification (0180h) translation of bytes at offsets 0180h and 0184h produces invalid results, but after that the "phase" of unassembling comes to a proper steady state. If translated machine instructions are correct and are known to DEBUG.EXE, then stochastic process of reaching the proper steady state usually takes up to 10h bytes and doesn't affect further translation.

Of course, commands should be unassembled just as they are apprehended by processor. However, the same machine code may be interpreted in different ways. One reason of differences is that machine codes of short jump instructions don't comprise jump target address, but rather contain a target offset relative to current contents of IP register. Debugger calculates target addresses by adding these offsets to IP register contents. The latter depends on start offset, where the first byte has been loaded of that code which is to be unassembled. Therefore unassembling short jump instructions can't be performed correctly, unless the code, which is to be unassembled, is loaded just as it must be loaded for execution, i.e. starting at CS:0000 address for drivers and at CS:0100 for *.COM and *.EXE programs.

Another reason for differences between processor's and debugger's interpretations of machine codes is the effect of processor's type and state. Interpretation depends on the operand size byte in the code segment descriptor.&#91;Note 5 to A.12-2&#93; Besides that, there are several machine codes which are interpreted in a special manner by 64-bit processors. However, proper processor's type and state for a particular presented machine code isn't "known" to DEBUG.EXE. It is able to unassemble only those machine codes designed for 16-bit execution. There is no sense in forcing DEBUG.EXE to unassemble other machine codes.

Invalid results of unassembling may be caused by those machine instructions, which are not "known" to debugger. Because of this reason Microsoft's version of DEBUG.EXE can't be recommended for unassembling modern programs. Another version of DEBUG.EXE, proposed in note 2 to part's 6.05 introduction article, should be preferred. Of course, recent versions of "respectable" unassemblers (IDA, SoftICE, etc.) are much more "clever", but can't give comparable freedom of access and even can't work under DOS. For those constrained to use Microsoft's version of DEBUG.EXE some "unknown" machine codes are given in the table below. Its first column presents first bytes of machine codes, which are shown by DEBUG.EXE as parameters of DB command (7.01-01) in a separate line. First byte together with second byte, given in the second column, are often enough to understand the type of operation. If necessary, names and references from the fourth column enable to find more information about particular instruction(s).

6.05-19 DEBUG.EXE : the "W" (= Write) command
The "W" command copies a code's succession from PC's memory onto a logical disk, either in a form of a file or just into disk's sectors. Here is an example of "W" command usage for writing a succession of codes into a new file :

A single parameter in the shown example is a memory cell address, where reading of code succession should start. Address may be specified in any of its allowable forms (6.05-01), but when segment is omitted, default segment is defined by CS: segment register. If address is not specified, reading of code succession starts at CS:0100. Length of code succession, counted from start address, must be prepared beforehand : least significant two bytes of length — in CX register, most significant byte in BX register.

It is assumed that name of new file to be created is written already into PSP (A.07-1) by "N" command (6.05-12). The name may have any suffix except *.HEX and *.EXE, because DEBUG.EXE is unable to compile a header for such files. One more assumption is that contents of DS: segment register has not been changed since name of new file was written into PSP, and hence the "W" command can still refer to segment address in DS: for reading this name from PSP. If the prepared name is not preceded by a path, new file will be created in the current directory. If a file with the same name exists yet, it will be overwritten without error message.

For writing into sectors of a logical disk the letter-name "W" must be followed by four required parameters, for example :

Here the first parameter presents start address of code succession, just as in previous example of writing into a file. The second parameter is interpreted as logical disk number: 0 – disk A:, 1 – disk B:, 2 – disk C:, and so on. The third parameter represents actual hexadecimal number of the first sector to be written, the fourth parameter – total hexadecimal number of sectors to be written. Up to 80h sectors may be written in one operation. Total number of sectors defines the length of written code succession, contents of CX and BX registers are ignored. In particular, the shown example specifies writing of a single sector number 0 (the boot-sector) onto logical disk A:. Physical disk's sectors beyond logical disk(s) are not accessible to the "W" command.


 * Notes
 * 1) When it is necessary to write a code succession from PSP region (A.07-1) into a file, you can't declare file's name by "N" command before a spare memory space for writing file's name is prepared. This may be done either by moving code succession out of PSP memory region or by changing DS: segment register contents so that file's name wouldn't overwrite code succession in PSP (example in article 9.08).

6.05-20 DEBUG.EXE : the "XA" (= Allocate) command
The "XA" command appeals to EMM386.EXE memory manager (5.04-02, 8.03-59) with a request to allocate a specified memory space beyond conventional memory and to assign a hexadecimal reference number – a handle – to the allocated memory space. Requested operation can't be performed unless the EMM386.EXE memory manager is loaded yet and unless memory above 1088 kb is available. In debugger's command line the name "XA" must be followed by requested number of logical memory pages of 16 kb each, for example :

The shown requested memory space is 1Ah (26 decimal) logical pages, which will be enumerated from 00h to 19h. DEBUG.EXE responds to the request with a message, for example, "Handle created 0006". Hence, the allocated memory space can be referenced with hexadecimal number 0006h. But this is not enough for access to the allocated memory space, one more operation must be performed: a limited number of selected logical pages from the allocated memory space must be mapped onto physically addressable memory space by "XM" commands (6.05-22).

6.05-21 DEBUG.EXE : the "XD" (= Deallocate) command"
The "XD" command appeals to EMM386.EXE memory manager (5.04-02, 8.03-61) with a request to deallocate a particular memory space, which has been allocated yet by "XA" command (6.05-20). It is assumed that EMM386.EXE memory manager is loaded and that memory beyond 1088 kb is available. In debugger's command line the name "XD" must be followed by a hexadecimal reference number (a handle), identifying the memory space, which is to be deallocated, for example :

DEBUG.EXE responds to the shown example: "Handle 0006 deallocated". Since that moment the 0006h handle becomes invalid, access to logical pages in deallocated memory space is lost, and this space is regarded as free.

6.05-22 DEBUG.EXE : the "XM" (= Map) command
The "XM" command appeals to EMM386.EXE memory manager (5.04-02, 8.03-60) with a request to map a 16 kb logical page in allocated memory space onto a "physical" page of the same size. Here the term "mapping" means adjustment of address translation mechanism in CPU so that ordinary 16-bit addresses within "physical" page address space are translated by CPU into 32-bit addresses of real memory cells in that part of address space, which corresponds to specified logical page. It is assumed that the PC has a 32-bit CPU, that the amount of memory exceeds 1 Mb, that EMM386.EXE memory manager is loaded yet, and that reference number (a handle) is assigned to the allocated memory space by "XA" command (6.05-20).

In debugger's command line, the name "XM" must be followed by three required parameters, for example:

The first parameter — 0Bh in this example — is a number of requested logical page in allocated memory space. The second parameter, 03h, is a number of "physical" page. The third parameter is a reference number (a handle), which is assigned to that allocated memory space, where the requested logical page belongs.

Numbers of "physical" pages may be selected from 00h to 1Bh, but it should be taken into account that "physical" pages from 04h and on occupy address space in conventional memory. This is why the most actively used are "physical" pages 00h–03h, which by default correspond to segment addresses E000h, E400h, E800h and EC00h accordingly. But their placement in address space may be affected by PC's BIOS requirements and by EMM386.EXE (5.04-02) memory manager's settings. Therefore in each particular case placement of "physical" pages should be checked by the "XS" command (6.05-23) or by a call to INT 67\AX=5800h handler (8.03-70).

6.05-23 DEBUG.EXE : the "XS" (= Show) command
The "XS" command appeals to EMM386.EXE memory manager (5.04-02, 8.03-70) with a request to display data, related to memory usage and to placement of "physical" pages. It is assumed that the PC's amount of memory exceeds 1 Mb and that EMM386.EXE memory manager is loaded yet. Since "XS" command needs no parameters, command line with "XS" command looks like this :

DEBUG.EXE responds to "XS" command with display of a table showing valid reference numbers (handles) and how many logical pages is associated with each handle. Then segment addresses are shown for each "physical" page. The last lines display statistics: total number of logical pages, number of free logical pages, maximum available number of handles and a number of handles, which are assigned yet. However, displayed table will be too long and wouldn't fit the screen, if it will comprise data about all 28 "physical" pages, stipulated by EMS 4.0 specification. In order to see the whole length of the table, you may either redirect output into a file (2.04-03), or set video mode 108h (A.10-1), or else limit actual number of "physical" pages by means of EMM386.EXE driver's settings (5.04-02).

6.06 DISKCOPY.COM – diskette copying utility
DISKCOPY.COM copies the whole contents of one floppy disk onto another, including volume label and serial number. Both floppies (diskettes) must be of the same type. Here is an example of command line for copying a diskette in a PC equipped with two floppy drives :

where :

Besides the shown options, DISKCOPY.COM can accept also

If the computer is equipped with only one floppy drive, then the same letter-name must be specified both for source and for target. In this case DISKCOPY forms a temporary buffer-file on a HDD in a directory, specified by environmental variable %TEMP%, then suggests to replace the source diskette with target diskette, and copies data from buffer-file onto target diskette. After that buffer-file is automatically deleted. But when the %TEMP% variable is not defined (or when /M option is specified), the source diskette is partially copied into available memory space, and therefore you'll have to exchange source and target diskettes several times in the same floppy drive.

DISKCOPY.COM is not designed to create a non-temporary file-image of a diskette. Besides that, DISKCOPY.COM can't cope reasonably with damaged sectors. Because of these drawbacks nowadays other copying programs are preferred. For example, the IMG.EXE utility can be recommended. Archive file IMG.ARJ, comprising the IMG.EXE utility, can be downloaded from server ftp://ftp.elf.stuba.sk/pub/pc/utildisk/.


 * Notes
 * 1) DISKCOPY.COM and similar diskette copying utilities can't be applied to hard disk drives, to network drives, to CD/DVD-ROMs and also to virtual disks, arranged by utilities ASSIGN.COM, JOIN.EXE and SUBST.EXE.

6.07 DOSKEY.COM – command line manager
DOSKEY.COM is a resident supplement to command line functions of COMMAND.COM interpreter. DOSKEY.COM enables to edit command line text, to recall former commands, to create and execute macrocommands, comprising simple sequences of operations. Procedures, specified via macrocommands, become available after loading of their definitions by DOSKEY.COM into special memory buffer. Besides this buffer, resident module of DOSKEY.COM occupies about 4 kb.

DOSKEY.COM in MS-DOS 7 has been changed relative to its former versions: it has been given an ability to load a list of macrocommand's definitions from a textual file and to increase sizes of both keyboard buffer and command line editing buffer.

DOSKEY.COM can be loaded from command line or from a line of a batch file (AUTOEXEC.BAT or other), either directly or with LH command (3.17), for example :

where:

Other options, allowable for loading operations, are :

If DOSKEY.COM is already loaded, it can be called again with the  option, to show stored previous commands (the history) :

or else with /M option in order to show stored macrocommands :

Besides this, DOSKEY.COM may be called again in order to load one more definition of a macrocommand into memory buffer from command line, for example :

Here the word "count" is interpreted as a name of new macrocommand. This name, being typed into command line close to command prompt, will initiate execution of command(s), specified within macrocommand's definition to the right of equality sign. The shown definition consists of one command, which counts lines in any textual file, represented here by dummy parameter $1. In the course of macrocommand's execution dummy parameter is replaced by actual filename, specified after macrocommand's name in the same command line.

Commands within macrocommand's definition may contain equality signs and substitutions of variable's values (such as %Temp%). When symbol "$" is encountered within macrocommand's definition, it is interpreted together with the following letter (or digit) in a special way as :

Textual file for loading macrocommand's definitions must contain one definition per line, which may look, for example, as follows :

You may delete any loaded macrocommand from buffer by specifying its name followed by nothing more than equality sign, for example :

When DOSKEY.COM is loaded, it activates the following "hot" keys :


 * Notes
 * 1) Macrocommand wouldn't be executed, if its name in command line is preceded by at least one space.
 * 2) When macrocommand is synonymous to a command, it disables the latter (macrocommand will be executed instead).
 * 3) DOSKEY.COM is NOT compatible with TSR file managers (Norton Commander, Volkov Commander, etc). File managers usually are preferred.

6.08 DELTREE.EXE – directories eraser
DELTREE.EXE is an extremely dangerous utility, because it enables to delete directories with all their subdirectories and files, regardless to file's attributes. Only root directories of logical disks can't be deleted with DELTREE.EXE. An example of its usage may look like this :

where :

6.09 EDIT.COM – editor utility
EDIT.COM is a popular double-window editor program mainly for textual files, but also with limited capabilities for editing binary files. EDIT.COM enables to keep open up to ten files simultaneously. Fig.3 shows two different files opened in separate windows of EDIT.COM editor.

The file(s) to be edited may be as large as PC's memory allows. EDIT.COM arranges a clipboard, enabling to send selected parts of text between opened files. Besides that, EDIT.COM is able to cooperate with mouse device drivers, thus making editing much easier and faster.

The EDIT.COM editor may be launched from command line without parameters, and then it will show an empty window. The user will have to open file(s) to be edited via menu "FILE". Otherwise the file(s) to be edited may be specified just in command line, for example :

The name of the first file to be edited is preceded by a path; without a path the EDIT.COM editor can only open files which are located in the current directory. Thus, the second file (Part6.txt), specified without path, must be present in the current directory. By default both files will be opened for textual editing, but only the first opened file will be shown in displayed editor's window. The user is given an opportunity either to open second window by CTRL-F6 keystroke or to switch the initial window with F8 keystroke to editing of the second opened file.

Some presets and help texts for EDIT.COM are stored in files EDIT.INI and EDIT.HLP (implied to be present in the same directory), but EDIT.COM can cope without help and with default settings only. When EDIT.INI is absent, the user is still allowed to save optional presets via the OPTIONS menu, and this will induce EDIT.COM to regenerate EDIT.INI file anew.

EDIT.COM preserves functions of some "hot" keys, which were active in DOS. Among these are the BACKSPACE key and combinations of ALT keystroke with digit(s) in numeric keypad, enabling to enter characters by their ASCII code. But most other "hot" key functions are redefined. The ALT keystroke makes active literal "hot" keys for selecting items in upper bar menu, and also makes active digit keys in literal part of keyboard for selecting opened files by their number, if more than one file is opened. Arrow keys shift cursor anywhere inside editor's window. If the SHIFT key is kept pressed while cursor is shifted over a part of text, then this part of text becomes selected (highlighted) for being deleted or copied into clipboard. The same effect is achieved when cursor is dragged over a part of text by mouse, while its left button is kept pressed.

Besides the mentioned key functions, EDIT.COM activates the following "hot" keys and key combinations :

Several "hot" key combinations are shown in upper bar menus. These menus and separate items in these menus can be opened not only with keystrokes, but also with mouse's left button as well.

As far as binary files have no line structure, line wrapping specification in command line will make their editing more convenient, for example :

where

EDIT.COM is able to accept from command line also the following options :

6.10 EXPAND.EXE – unpacker for compressed files
EXPAND.EXE is unpacker for files compressed with Microsoft's COMPRESS.COM utility. Each such compressed file contains only one original file and inherits its name, except that the last character in suffix is replaced with underscore, for example *.TX_ instead of *.TXT. Releases of previous MS-DOS versions and several other software packets comprise such compressed files together with EXPAND.EXE unpacker utility. In particular, EXPAND.EXE is present in SFX archive DOS62SP.EXE, which can be downloaded from Microsoft's FTP-server ftp://ftp.microsoft.com/softlib/mslfiles/.

The name of EXPAND.EXE unpacker utility must be followed in command line by the name of the compressed file to be unpacked, and then by a name, which should be appointed to the restored original file, for example :

Both paths in the shown example are optional. The path preceding a name for the restored file is interpreted as a prescription to write the result of unpacking into that directory. If paths are omitted, then compressed file will be searched for inside current directory only, and the result will be placed just there, but in this particular case it is permissible, because compressed file and original file have different names.

Wildcards (2.01-03) in filenames are not allowed by EXPAND.EXE, but there may be several names of compressed files in one command line. In this case the last specified name must be a directory name (without final backslash), where unpacked files should be written. Name of the current directory with this mission can't be omitted, but may be represented with a dot (2.02-03).

Source files, compressed with old versions of COMPRESS.COM, comprise no information about original names of compressed files. Such files will be unpacked properly, but their original names will not be restored, if explicit new name specification is not given in command line. Therefore sharing of a common directory as both source and target should be avoided because of possible name conflicts.


 * Notes
 * 1) Compressed files in Windows-2000/XP releases also are marked with underscore at the end of suffix, but these files are compressed by other algorithm. Their unpacking in MS-DOS 7 can be performed by EXTRACT.EXE (6.11).

6.11 EXTRACT.EXE – unpacker for *.CAB files
The EXTRACT.EXE utility unpacks files, compressed by MAKECAB.EXE packer. Microsoft uses this algorithm for compression of separate files in Windows-2000/XP releases, and also for compiling large multi-volume archives with *.CAB suffix in releases of Windows-95/98/ME. EXTRACT.EXE enables to extract separate files from large *.CAB archives and to display their contents. Here is an example of command line for extracting a list of contents from a multi-volume *.CAB archive :

where :

As far as *.CAB archives contain a large number of files, it's difficult to perceive their long tables of contents from a scrolling screen. This is why in the shown example output is redirected into file List.txt, which may be analyzed more conveniently with a viewer (6.19) or with an editor program (6.09).

Here is one more example of EXTRACT.EXE usage for extracting of a single file from a multi-volume archive, when it is not known beforehand, which particular volume contains the required file :

where :

In the shown example the first specified filename (Win95_02.cab) is interpreted as a name of that archive volume, where a search for the required file should start. All following filenames are interpreted as names of those files, which should be extracted and decompressed. Execution of the shown command line initiates a search procedure through volumes from 02 to 26 for the specified file. In fact it will be found in the 13th volume and will be unpacked into C:\WINDOWS\SYSTEM directory, overwriting there a corrupted sample of the same file. Such procedures are much faster than the total unpacking of a software release.

EXTRACT.EXE doesn't allow wildcards (2.01-03) in filenames, but accepts one more optional parameter /E, which forces to unpack all contents of the specified CAB-file. In this case a particular name(s) for the files to be unpacked shouldn't be specified. The /E parameter is expedient for unpacking non-cabinet compressed files (those marked with underscore at the end of suffix) from Windows-2000/XP releases. But total unpacking of large *.CAB files in DOS takes too much time. A combination of /A and /E parameters deserves special caution, because it may initiate a process, which will take hours of time and a lot of disk space.


 * Notes
 * 1) Some software vendors supply *.CAB archives, which are produced by other compression algorithm. Besides that, several mutually incompatible versions of EXTRACT.EXE are known. The most suitable unpacker for any given software release is that one, which is supplied within this release.

6.12 FC.EXE – files comparison utility
The FC.EXE utility enables to compare two files, either binary or textual. Binary comparison is expedient for finding changed bytes in nearly identical binary files: FC.EXE displays byte number for each pair of mismatched bytes and these bytes themselves, taken from each of the compared files. Here is an example of command line for performing binary comparison:

where :

Binary comparison doesn't imply searching for match in mutually shifted successions of bytes.

Textual comparison is based on line structure of textual files. FC.EXE compares textual files line-by-line and displays mismatched lines side-by-side. When order of correspondence between line successions becomes disrupted, FC.EXE can restore it by searching for a next group of matching lines. Both comparison and search conditions are specified by options in command line, for example :

where :

Binary comparison is the default for files having suffixes BIN, COM, EXE, LIB, OBJ, SYS. Other files are compared as textual by default.
 * Notes
 * 1) In special applications one of the files to compare (or both) may be replaced by other sources (2.01-01), for example, by virtual device NUL or by CON device – the console. The latter enables to perform comparison with keyboard input (1.04).

6.13 FDISK.EXE – partitioning tool for HDDs
Disks, known by their letter-names, are logical disks. Contrary to those, physical hard disk storage devices have no letter-names. Writable storage space in physical storage devices may be divided into several partitions, and each partition may represent a separate logical disk. The FDISK.EXE utility is a proprietary MS-DOS 7's tool for arranging partition structures in physical HDDs (Hard Disk Drives).

Being launched without parameters, FDISK.EXE asks the user whether large disk support should be provided or not. Rejection of the offer means that arranged partitions within range 512–2048 Mb will be of FAT-16 type, otherwise FAT-32 type will be preferred. FAT system for partitions outside the mentioned range is assigned by default : FAT-32 for partitions larger than 2048 Mb, FAT-16 for partitions between 512 and 16 Mb, FAT-12 – for 16 Mb and smaller volumes.

Those apt to trust theirselves may specify command line parameters, enabling to get rid of undue questions and restrictions :

The  parameter cancels query about large disks support and gives all rights on file system choice to the user. The  parameter enables to arrange an active partition in any physical hard disk drive (otherwise an active partition may be arranged in the first physical HDD only). Being launched in the shown way, FDISK.EXE presents a menu to select an operation: to display current partition structure, to delete or to create a partition or to make it active. The user is allowed to compose partition structure, but the latter is not written to disk at once. FDISK.EXE gives a chance to correct it. If a partition ought to be bootable, don't forget about making it active. Then you may exit FDISK.EXE.

If the partition structure has been changed, FDISK.EXE writes it to disk and exits into reboot, because created partitions must be registered by BIOS. PC's BIOS system appoints letter-names to registered partitions. Since that moment all registered partitions become "visible" in DOS as logical disks, but new logical disks are not yet formatted and therefore are inaccessible. New logical disks become accessible after formatting by FORMAT.COM utility (6.15).

Besides interactive arrangement of partition structures, FDISK.EXE may be used as ordinary console utility with the following options :

Regardless to purpose of FDISK.EXE usage, its command line may be complemented with  option, which forces to avoid extended support functions for access to disk(s). The  option should be remembered, when ordinary usage attempts fail: the HDD either is not recognized, or is found inaccessible, or the PC gets hanged with "Stack overflow" message. Such outcomes may take place because of incorrect configuration, hardware faults, virus MBR infection. Not necessarily, but in some such cases the  option may help.

If an identical partition structure should be formed on several new HDDs, then automatic (non-interactive) arrangement of partitions should be preferred. Automatic writing of a partition structure onto a HDD can be initialized by the following example of command line :

where :

Having finished its job successfully, FDISK.EXE initializes reboot.

 ^ Overwriting the MBR enables to get rid of MBR bugs, including those inflicted by viruses. However, some BIOS extensions and boot managers use non-standard types of MBR, which can't be restored by FDISK.EXE. In such circumstances other ways of MBR restoration should be preferred (example in 9.02-03). Microsoft's FDISK.EXE doesn't support non-sequential placement of partitions and therefore gives no opportunity to bypass worn-out regions of physical disk's surface. FDISK.EXE can't arrange correctly those partitions, which cross the 8.4 Gb boundary in physical disk's space. FDISK.EXE often can't cope properly with partitions, arranged by other operating systems: either can't delete such partitions, or may arrange new partitions, overlapping the former ones. Most significant drawbacks of original Microsoft's FDISK.EXE have been corrected in its new unofficial version (dated 2006), which can be downloaded from site http://radified.com/Files/FDISK.EXE. Besides that, completely new synonymous utility has been compiled by Brian E. Reifsnyder. Version 1.30 (dated 2003) of this utility, packed into archive fdisk130.zip, can be downloaded from server ftp://ftp.uni-koeln.de/pc/msdos/diskutils/ Any change of existing partitions structure, performed by FDISK.EXE, causes total data loss within affected partition(s). Partition(s) rearrangement without data loss may be performed by more powerful tools, for example, by PowerQuest's Partition Magic utility (bought now by Symantec Co.). FDISK.EXE can't arrange partitions in HDDs, accessed via a network or controlled by drivers. Because of the latter reason FDISK.EXE often can't cope with external storage devices having SCSI or USB interface. In such cases other utilities may suit, for example, BTFDISK.EXE (from Buslogic) or TFDISK.EXE (from TEKRAM). Archive DC390FBW.ZIP, comprising TFDISK.EXE, can be found in internet site http://www.neuron.alt.ru/drivers/Driver/Controllers/, in its subdirectory TEKRAM. A SFX archive DOSASPI.EXE, comprising BTFDISK.EXE, is present in subdirectory BUSLOGIC of the same site.</li> </ol>
 * Notes

6.14 FIND.EXE – word(s) searching filter
The FIND.EXE utility acts as a filter for textual data: it receives lines of text from a file or via redirection, selects lines with or without a certain combination of characters, and sends selected lines into standard output channel (STDOUT) for being displayed on the screen by default. Here is an example of word(s) filter usage for searching lines with a specified string of characters :

where :

The shown example of command line will display on the screen all lines of the analyzed file, containing words INT 13, and a short message reminding which file has been analyzed. Lines will be shown preceded by their numbers: this will help you to find them later while editing the same file. If you expect that the displayed listing may happen to be too long, you may send output into a file (2.04-03) or to the viewer MORE.COM (6.19).

Having finished the search, FIND.EXE returns errorlevel 0, if it has found the specified string of characters at least once, or errorlevel 1, if this string hasn't been found in the analyzed text. Errorlevel may be used to determine the outcome of search (see articles 3.15-03 and 6.03).

The next less typical example shows FIND.EXE counting lines in a textual file :

where :

Void string to be searched for is regarded by FIND.EXE as a special non-existing object. Therefore FIND.EXE will simply count all the lines, including the empty ones. After counting the lines FIND.EXE always returns errorlevel 0.

The third usage example presents lines of a batch file. Suppose that the target path is given as a value of environmental variable %P%, and it is not known, whether it has a final backslash or not. Since DOS is not indifferent to absence of a the final backslash, you need to append it, if it isn't specified yet. This may be done in the following way: In the first line FIND.EXE analyses redirected output of the ECHO command and tries to find specified combination of symbols, which will be present there if the given path contains final backslash. STDOUT output of FIND.EXE presents no interest and is sent to NUL (into nowhere). The result becomes known via the errorlevel value, left by FIND.EXE. It is analyzed in the second line of the presented example. Errorlevel 1 means that FIND.EXE has found no final backslash in the given path, and then the SET command (3.26) will append the missing backslash.

The last (fourth) usage example is also a part of a batch file. Suppose that you have activated a procedure, which prepares a list of files (%Temp%\Files.lst) to be packed into an archive, and want to prevent twice-fold packing, when this list contains nothing more except archives of the same kind (RAR, for example). This can be achieved by the following command lines: In the first line the leftmost call for FIND.EXE reads filenames from the list line-by-line via input redirection, and counts only those lines, which don't contain filenames with ".RAR" suffix. The count result is redirected via STDOUT to the second (rightmost) call for FIND.EXE, which is "waiting" for zero count. When the count result really is zero (i.e. there are no other files except RAR archives), the rightmost call for FIND.EXE leaves errorlevel 0. This errorlevel value is checked in second and third lines of the example. The second line displays an error message, and the third line performs a jump to label "NO_PACK", thus enabling to bypass packing operation.

6.15 FORMAT.COM – formatting tool for disks
The FORMAT.COM utility arranges logical disks on storage media, including diskettes and partitions of hard disks. Formatting includes testing of each sector's readability, writing sector's headers, creation of boot sector, of file allocation table (FAT) and of root directory. Clusters found to have non-readable sectors are marked in FAT as "BAD" and thus get out of use. Disks of 16 Mb and smaller are formatted with file system FAT-12. Choice of file system (FAT-16 or FAT-32) for partitions of hard disks is made with respect to FAT type identifier (A.13-6), assigned to particular partition beforehand by FDISK.EXE (6.13). Cluster size is calculated automatically as allowable minimum for given disk's size and FAT type.

Formatting of floppy disks (diskettes) implies low-level recalibration of tracks, so that actual capacity of a diskette may be altered. An example of command line for formatting a diskette may look like this :

where :

Modern hard disk drives have a fixed track structure. It can't be altered by formatting procedure. Therefore disk's size, number of sectors and other similar format parameters shouldn't be specified for formatting HDD's partitions, for example :

where :

<ol> <li id="note-6.15-1">Instead of total size of a floppy disk you may specify number of tracks and number of sectors in each track, for example. Another alternative to  is to use the following : <li id="note-6.15-2">The original FORMAT.COM from Microsoft (dated 1998) cannot cope properly with formatting partitions beyond 64 Gb. A corrected version (dated 2006), packed into SFX archive FDSKFRMT.EXE, can be downloaded from http://www.mdgx.com/files/FDSKFRMT.EXE .</li> </ol>
 * Notes

6.16 LABEL.EXE – volume's label changing tool
Volume's label is a word or a group of words of up to 11 characters long, used as a storage media identifier. Volume's label is written into boot sector (A.03-4) and, besides that, into a hidden entry of the root directory. Most often volume's label is appointed during formatting procedure, but it may be assigned or changed later by the LABEL.EXE utility, for example :

where :

When volume label is omitted, LABEL.EXE shows current label of specified disk and offers to type a new one. New label specification may be accepted via redirection too (2.04-02, 2.04-05). If user rejects the offer, he is prompted to delete (or to preserve) the current label.

Having finished its job, the LABEL.EXE utility leaves behind the following errorlevel values :

The returned errorlevel value may be determined just as it is shown in articles 3.15-03 and 6.03. As far as the returned errorlevel value is informative, the LABEL.EXE utility is sometimes used to test disk's accessibility (example in article 9.03-02).

6.17 MEM.EXE – memory allocation explorer
The MEM.EXE utility is called in order to display information about amount of available memory, about its allocation, about loaded resident modules, for example :

where options are :

6.18 MODE.COM – peripherals interface tuner
The MODE.COM utility implements a number of interface configuration functions for ports, for video card and for character generator. A summary table of current subordinate equipment settings is displayed by MODE.COM utility, when it is called with  option :

6.18-01 MODE.COM: ports tuning operations
Interface tuning operations for serial ports (COM1, COM2, COM3, COM4) are performed by MODE.COM as it is shown in the following example :

where :

Interface tuning operations for parallel ports (LPT1, LPT2, LPT3) imply that the connected device is a printer. This is why for parallel ports the MODE.COM utility accepts other parameters, for example :

where :

The MODE.COM utility can re-address messages from parallel port ( – ) to any serial port ( – ), thus enabling to use a printer with serial interface :

In order to cancel readdressing the MODE.COM utility should be called once more without further specifications after the same parallel port's name :

6.18-02 MODE.COM: textual video modes switching
The MODE.COM utility allows two forms of commands for switching textual video modes (A.10-1). Here is an example of the first (most obsolete) form of command :

where :

The second form of command for switching textual video modes looks like this :

where :


 * Notes
 * 1) Switching of textual video modes is accompanied with loading fonts anew. If current font has been installed by some other program (except MODE.COM), then change of a video mode by MODE.COM may cause a return from national font to default american font codepage 437.

6.18-03 MODE.COM: codepage selection
Commands for codepage preparation and selection operations, performed by MODE.COM utility, usually are written into the AUTOEXEC.BAT file (9.01-02). All these operations need the DISPLAY.SYS driver (5.02-02) to be loaded yet. The first of these operations is preparation of several codepages for further activation :

where :

Then one of prepared codepages should be made active by means of selection operation :

where :

The codepage, activated for the CON (console) device, defines visual presentation of letters and symbols on the screen. In order to determine which codepage is currently active for a particular output device, you should call for the MODE.COM utility with device specification (, ,   or  ), with   (Code Page) operation name and with the   option :

Any loaded codepage may become corrupted because of malfunction or because of undue actions of other software. In such cases the MODE.COM utility enables to load the active codepage once more with command :

where :

6.19 MORE.COM – page-by-page viewer
When long messages are sent to display as a whole, text is scrolled over the screen too fast to be perceived. In order to make long messages readable, the MORE.COM viewer sends them to display in a page-by-page manner. Each time the screen is full with text, the MORE.COM viewer suspends output, giving an opportunity to read the text. Each user's keystroke initiates display of the next text page.

The MORE.COM viewer intercepts the messages, sent into standard output channel (STDOUT), either by means of input redirection (2.04-02) :

or by means of intermediate redirection (2.04-05) :

where :


 * Notes
 * 1) Messages sent to display via BIOS' interrupts or via STDERR output channel can't be intercepted by MORE.COM.
 * 2) When the MORE.COM viewer accepts a message by means of intermediate redirection (2.04-05), this message is written into a temporary file, and access to a writable media is necessary. If current disk is non-writable or write-protected, and if a path to a writable media is not defined in environmental variable %TEMP%, then the MORE.COM viewer can't perform this mission. Therefore interception by means of input redirection should be preferred.

6.20 MOVE.EXE – copying and renaming utility
The MOVE.EXE utility is used to rename directories and to move files from one directory into another.

When source and target directories belong to different logical disks, moving is equivalent to copying, followed by deleting the copied file in the source directory. But when both source and target directories belong to the same logical disk, moving can be performed much faster by rearranging directory entries: reference record to file's first cluster is moved from one directory table into another without touching the file itself. The MOVE.EXE utility is able to decide, which way of moving should be implemented in each particular case.

Moving of file(s) may be accompanied by renaming. Renaming of a directory is also performed by correcting an entry in parent directory table.

Here is an example of MOVE.EXE usage for moving files from one directory into another :

where :

In order to rename a directory, the last name in source specification must be not a mask and not a filename, but a name of an existing directory. In this case the target specification must consist of a new name only without path, even if the directory to be renamed is not a subdirectory inside the current directory.

6.21 SCANDISK.EXE – disk(s) repairing tool
SCANDISK.EXE is a program for examination and repairing diskettes and hard disk drives, formatted with FAT12, FAT16 or FAT32 file systems. SCANDISK.EXE checks boot sector, reveals lost clusters, corrects crosslinks in FAT table, examines writeability of disk's surface in each cluster. Non-readable clusters are marked in FAT as BAD and therefore get out of further use. The course of testing and location of bad clusters are displayed in a chart, shown below in fig.4. SCANDISK.EXE tries to rewrite information from bad clusters into good ones so as to restore integrity of each file. Being launched regularly, SCANDISK's maintenance procedures enable to keep your computer in good health for a long time.

Details of test's structure are defined by parameters, stored in a separate file SCANDISK.INI, which must be present in the same directory with main SCANDISK.EXE file. SCANDISK.INI is a textual file. It contains comprehensive commentaries and can be edited by the user. If you have to check and repair a drive according to all parameters in SCANDISK.INI, you have to launch SCANDISK.EXE with  option in command line. When  option is not specified, only those parameters in [ENVIRONMENT] section of SCANDISK.INI file will be taken into account.

Parameters in command line have priority over those specified in SCANDISK.INI file. SCANDISK.EXE is able to fix automatically most part of the errors it finds, but for that it has to be launched with parameters in command line, for example :

where :

When  option is not specified, then before making any changes SCANDISK.EXE offers you to write disk's current state onto UNDO-diskettes. This gives an opportunity to restore current disk's state later, if fixes will happen to inflict something wrong. While making a decision about UNDO diskettes, it should be taken into account, that amount of data in current state record may be enormous. Large partitions of modern HDDs may require hundreds of UNDO-diskettes and a lot of time. This is why SCANDISK's offer about UNDO-diskettes most probably should be rejected.

If nevertheless original disk's state was saved in UNDO-diskette(s), and restoration of this state has been found necessary, then restoration procedure must be performed at once, before any new files are written onto this disk :

where :

One more operation, performed by SCANDISK.EXE, is exploration of whether a particular file is fragmented or not :

where :

Regardless to performed operation, SCANDISK.EXE accepts from command line one more option – the  option, prescribing to configure its output for a monochrome display (by default the output messages are displayed in color).


 * Notes
 * 1) SCANDISK's procedures can't be applied to network drives, to CD/DVD-ROMs, to RAM-disks and to virtual disks, created by utilities ASSIGN.COM, JOIN.EXE and SUBST.EXE. SCANDISK.EXE also can't cope with those damages of disk's data, which make this disk inaccessible. However, inaccessible disks with damaged boot sector sometimes may be restored with NDD.EXE or with DISKEDIT.EXE utilities from Symantec Co.
 * 2) SCANDISK.EXE needs direct access to the processed disk and therefore can't be used inside a multi-tasking environment. A call for SCANDISK.EXE inside the DOS "window", arranged by WINDOWS OS, in fact invokes another program – the SCANDSKW.EXE from the \WINDOWS directory.
 * 3) SCANDISK.EXE with  option shouldn't be applied to disks, suspected of being infected by virus. This may cause irreparable data loss. Such disks should be processed by an antivirus scanning program first (for example, by DRWEB.EXE).
 * 4) By default SCANDISK.EXE regards as an error each long filename appointed by Windows OS. Attempts to fix all such errors may have awful consequences. SCANDISK.EXE will not harm long names if section [ENVIRONMENT] of SCANDISK.INI file contains lines :  The improved version of SCANDISK.EXE of Windows ME is more tolerant to long names and can be used under MS-DOS 7.
 * 5) data rewriting from bad clusters into good ones can't be performed, unless there are some free clusters on the same disk. Of course, you can remove any file in order to get some free space, but there are utilities (version 2.50 of PKZIP.EXE archiver, for example), which fill diskette(s) with a single file leaving no free space at all. Because of one corrupted sector such file can't be neither read nor repaired, since there are no spare sectors. Filling of the whole media with one file should be avoided.

6.22 SORT.EXE – lines sorting filter
The SORT.EXE utility accepts textual lines from a file or via redirection and sends the same lines in another — sorted — order via STDOUT channel to the screen (the default), or to another file or device. Sorting is defined by the order of characters in ASCII code table.

The following example shows SORT.EXE usage for displaying a changed order of textual lines on the screen :

where :

Second usage example shows input from a source file via redirection and output redirected into another (target) file :

where :

The last example shows input via intermediate redirection from another command and output of sorted lines to a printer :


 * Notes
 * 1) Redirection to a printer shouldn't be attempted unless you are sure that your printer is properly connected to LPT1 port, is switched on and is able to cooperate with MS-DOS.
 * 2) Both output redirection and redirection via a "pipe"  need access to a writable media and can't be performed, if this condition is not met (2.04-03 – 2.04-05).

6.23 SUBST.EXE – arrangement of virtual disks
The SUBST.EXE utility arranges virtual disks, used as an equivalent replacement for real paths. Originally SUBST.EXE has been developed as a means of access to subordinate directories for old programs (from DOS versions earlier than 3.0). Early DOS versions didn't "know" hierarchical directory structures, all files were stored in a single root directory. The SUBST.EXE utility enables to address a file in any subdirectory as though it were in the root directory of a disk. Nowadays the SUBST.EXE utility is used rarely in order to squeeze more data into a limited length of command line and of environmental variable %PATH%.

Here is an example of arranging a virtual disk with SUBST.EXE :

where :

In order to delete virtual disk, command line with a call for SUBST.EXE utility may look like this :

where :

Being executed without parameters, the SUBST.EXE utility displays a list of currently active virtual disks.


 * Notes
 * 1) Virtual disks, arranged by SUBST.EXE, can't be subjected to actions of the following utilities: Assign.com, Backup.exe, Chkdsk.exe, Defrag.exe, Diskcomp.com, Diskcopy.com, Fdisk.exe, Format.com, Label.exe, Mirror.exe, Recover.exe, Restore.exe, Scandisk.exe, Sys.com, Undelete.exe, Unformat.com.
 * 2) The paths assigned to virtual disks remain accessible in an ordinary way.
 * 3) Virtual disks can be accepted by Windows OS, but can't be arranged, when Windows OS is loaded yet. If necessary, virtual disk(s) should be arranged before loading WINDOWS, preferably by SUBST.EXE utility launched from a line of AUTOEXEC.BAT file.

6.24 SYS.COM – utility making disks bootable
At a certain stage of PC's booting process control is transferred to executable code, read from boot sector of the boot disk. In its turn, this executable code transfers control to a loader file, specified inside the same boot sector. In order to make a disk bootable with MS-DOS 7, an appropriate executable code and the name IO.SYS of MS-DOS 7 loader file must be written into disk's boot sector beforehand. Besides that, the IO.SYS loader itself together with command interpreter COMMAND.COM and MSDOS.SYS file (5.01-01) must be present in the root directory of bootable disk. These boot ability conditions are prepared by SYS.COM utility.

Command line for making a disk bootable may look like this :

where :


 * Notes
 * 1) SYS.COM utility can't be applied to network disks, to CD/DVD-ROMs and to virtual disks, created by RAM-disk drivers or by utilities ASSIGN.COM, JOIN.EXE and SUBST.EXE.
 * 2) The operations, performed by SYS.COM utility, are necessary, but are not sufficient for making bootable a HDD's partition. This partition must be marked active in disk's MBR by FDISK.EXE (6.13) or by some other similar program. Executable code of boot sector will be read for execution just from that single active partition.
 * 3) Contrary to IO.SYS and_COMMAND.COM system files, the MSDOS.SYS file (5.01-01) is not copied. SYS.COM creates it empty anew. Loading from a new disk with default settings is considered more safe, because former settings may be unsuitable in other circumstances.
 * 4) In the 8th version of MS-DOS the SYS.COM utility has been changed: it always uses the default path to the source directory, and can't accept this path from command line.

6.25-01 Main properties of Volkov Commander shell
The Volkov Commander file manager (VC), written by Vsevolod V. Volkov (Kiev, Ukraine), resembles the known Norton Commander file manager, but VC is more compact and more flexible for adaptation to user's demands. Though VC is an unfinished project and can't be considered quite good, nevertheless it is the best for making reparatory work comfortable under MS-DOS 7. Version 4.99.07 of VC, packed into archive vc499.zip, can be downloaded from internet site http://www.fdd5-25.net/shells.php. Just this version, dated 1998, is described below. The latest alfa-version 4.99.08 of VC Shell is dated 2000. This latest version, packed into archive vc49908a.zip, can be downloaded from site http://vvv.kiev.ua/download/.

VC.COM is not a file manager itself, it is just a start file. The whole VC release includes the main overlay VC.OVL, a number of code translation tables *.TBL, and the following configuration files :

All VC's configuration files, except VC.INI, are ordinary textual files, which can be edited with EDIT.COM (6.09) or with any other editor program for non-formatted textual files. Examples of several VC's configuration files are shown in articles 6.25-02 – 6.25-04.

All files of the VC release must be stored in one directory, and the path to this directory should be assigned as a value to environmental variable VC. Therefore file AUTOEXEC.BAT should include a line, for example :

VC Shell may be launched from command line as an ordinary program, but it is usually launched automatically from the last line in AUTOEXEC.BAT file, for example :

where options are :

Other allowable options for VC.COM are :



Behind all parameters in command line VC.COM allows to specify a command, which should be executed just after launching the VC Shell itself. This opportunity may be expedient, for example, for refreshing a record of interrupt table contents saved beforehand by ESCAPE.COM utility.

When VC Shell is running, its appearance on the screen may be different, depending on initial settings, stored in VC.INI file. Usually directory's contents are displayed in one or two panels, as shown in fig.5.

Main functions of VC Shell are accessible via "hot keys" and via mouse's buttons clicks as well. Those "hot keys", which are kept active by VC Shell, are enlisted below in decreasing importance order.

Functions of some "hot keys" are duplicated. Ctrl-J and Ctrl-Enter act just as Ctrl-i : write name of the selected file into command line. Ctrl-Z acts as ALT F10 – shows active panel tree. "0" in the numeric keypad acts just as INS: adds the selected item to a list of items, being prepared for performing a group operation. Items, included in the list, are highlighted with colour. Several keys in the numeric keypad are charged with auxiliary functions for preparing group operations :

When a list of highlighted items is prepared, then operations F5 (copy), F6 (move), F8 (delete) involve all the items in the list. List of highlighted items exists as a temporary file VCLIST.000 in the directory, defined by environmental variable. Inside VC configuration files the prepared list of highlighted items is accessible via special macro commands   (for the active panel) and   (for the passive panel). Thus the user is given an opportunity to define its own group operations (examples in article 6.25-02).

If both VC's panels are switched OFF, VC shell provides more opportunities to navigate along the command line with LEFT ARROW and RIGHT ARROW keys, to insert characters into command line, and enables to access its history list with UP and DOWN arrow keys. When NUMLOCK key is switched OFF, arrow keys in numeric keypad act in the same way.

Development of the described VC's version (4.99.07) has not been completed. Some functions, defined by the user via configuration files, may go wrong, when there are alien  or   files in the current directory, and also when an archive file is left opened in the non-active panel. Several "hot keys" are claimed active, but in fact are not, or act in a wrong way :

6.25-02 Volkov Commander's menu file VC.MNU.
VC's wide capabilities of adaptation are achieved due to a variety of macrocommands, which are available inside its menu files and inside its extension files.

Certain groups of syntax symbols and digits, being encountered in VC's configuration files, are interpreted by VC Shell as a call for a macro, and then are replaced by the result, returned by the same macro. This result may be a name, a path, a line, etc.

Here is a list of syntax symbol groups and corresponding macros, provided by VC file manager version 4.99.07 :

Combinations of symbols, including the tilde sign, invoke those macroinstructions, which truncate "long" filenames to 8 characters, and "long" suffixes – to 3 characters. In all such combinations of symbols the tilde sign can be omitted, and then the same macros, being executed in "DOS window" of WINDOWS-95\98\ME OS, return long filenames "as they are", without truncation.

The user is given an opportunity to specify groups of symbols, invoking any macro, in any command line inside menu file (*.MNU) and inside extension files (*.EXT). All lines in these files can be typed with editor program for non-formatted textual files (6.09). Each item of menu is represented in VC.MNU file by a header line and by at least one command line. VC file manager considers command lines are those non-empty lines, which begin with at least one space (ASCII code 20h). On the contrary, the header lines must not begin with a space. In the header lines the first group of characters, followed by a colon, is interpreted as specification of the "hot key" to invoke function of this menu item. The rest group of words to the right of colon is interpreted as a name, representing this item of menu, when menu is displayed on the screen.

When the user has chosen a menu item for execution, the VC file manager replaces all groups of symbols, used to call any macro, by those data returned by corresponding macro. This is done at once in all command lines, following the header line of the chosen menu item. Then these command lines are sent one-by-one for execution to COMMAND.COM interpreter, which is called anew for each command line. Because of this reason jumps between command lines are not allowed, and the values of environmental variables can't be transferred from one command line to the following command lines within the same menu item. Of course, all conditions for proper execution of batch files should be met (see introduction article to chapter 9).

An example of VC.MNU file is shown below. Mentioned there files Edit.com (6.09), Fc.exe (6.12), Scandisk.exe (6.21) are programs taken from Windows-95/98 release. Files Arc.bat and Turn_off.com are those described in articles 9.03-01 and 9.05-02 of this book. All these files must be present inside directories, specified in the value of the %PATH% environmental variable (2.02-02). As far as VC file manager has no internal help, file HELP.TXT, mentioned in the first item of the menu, is implied to contain a text written by you yourself. A path to HELP.TXT file is required to exist on one disk with COMMAND.COM interpreter.

Each group of command lines related to one menu item can be regarded almost as a batch file. The purpose of the first item is just display of a prepared text. But when DOS is transposed to a RAM-disk (9.04, 9.09), letter-name of this RAM-disk can't be known beforehand. Letter-name problem is solved otherwise: the first command line makes current the disk, specified in a reference to command interpreter. If DOS is transposed, the HELP.TXT file is copied to the same disk too. Therefore the path to HELP.TXT file in the second command line refers to the root directory of a current disk, whichever it is. After that the last command line of the first menu item restores former appointment of the current disk.

The second menu item, called with "hot key" F4, presents a simple example of a query, performed by VC file manager, and also an example of conditional execution of a command, if user's response to the query isn't empty. Just the same can be said about the sixth menu item, called with "hot key" F8. Appeal to SCANDISK.EXE program via menu is expedient because otherwise a very important  parameter (6.21) is often forgotten, and therefore testing procedures may go wrong.

The third menu item, called with "hot key" F5, presents a useful procedure of finding differences between synonymous textual files, shown in the left panel and in the right panel simultaneously. The first command line checks, whether different directories are opened in VC's panels. If yes, the FC.EXE utility in the second command line compares selected files and sends a report into a temporary file. The third command line displays this report on the screen, and the fourth command line deletes temporary file.

Unfortunately, the described procedure of finding differences doesn't include all the checks, which should be conducted. The reason is that VC file manager performs substitutions of macroinstruction's data in its own buffer. As far as this buffer is only 128 bytes long, returned data increase risk of truncating command line before it is sent to command interpreter COMMAND.COM for execution. The threat of truncation is quite real, in particular, for the second command line with a call to FC.EXE. Besides that, a call to a version-specific utility via the %PATH% environmental variable is not reliable enough (see introduction article to chapter 6), and separate loading of command interpreter for each command line makes execution slow, especially when command interpreter is loaded from a diskette.

It is better to arrange complex procedures in a form of separate batch files. An example of this alternative approach is represented by batch file ARC.BAT (9.03-01), called from command lines in the 4th and 5th menu items. Batch files decrease risk of command line's truncation, eliminate restrictions on jumps, on searchless addressing, on usage of environmental variables.

At last, a batch file, launched from VC.MNU, is executed much faster, than equivalent separate command lines.

In command lines of VC's configuration files, including VC.MNU, VC file manager allows to specify other menu files with  suffix, i.e. a submenu may be specified instead of a call for an executable utility. Potentially this gives an opportunity to compose hierarchical menu structures.
 * Notes
 * 1) In VC's configuration files, including VC.MNU, all lines, beginning with a quote sign, are skipped. The rest part of these lines may be filled with commentaries.

6.25-03 Extension files VC.EXT and VCEDIT.EXT.
Volkov Commander is able to arrange specific treatment for selected types of files according to their suffixes. Suffix-dependent VC's reaction on ENTER keystroke (and equally on mouse's left button double-click) is defined by textual configuration file VC.EXT. Similarly suffix-dependent reaction on F3 (VIEW) keystroke is defined by textual file VCVIEW.EXT, and reaction on F4 (EDIT) keystroke - by textual file VCEDIT.EXT.

Suffix definitions in these files are specified just at the left edge of a line and must be followed by a colon. To the right of a colon there is specification of a command to be performed. If a keystroke must invoke more than one command, lines with the next commands follow just below; these lines must begin with one or more spaces (instead of suffix definition). If suffix definition is not followed by a command, then a file with this suffix invokes command(s) specified in the nearest line(s) below. Suffix definitions may include wildcards ( and  ).

Each user has to choose particular programs, called via extension files, according to his own needs. The following example of VC.EXT file is not intended to show as much functions as can be invented, it just reflects the author's taste.

The shown example of VC.EXT file begins with a simple line : command files written in QBASIC language are directed to their interpreter. The latter can be found in MSDOS6.22 release or in SFX archive OLDDOS.EXE, available at Microsoft's ftp-server ftp://ftp.microsoft.com/softlib/mslfiles/. You have to remember that a corresponding record must be written into versions table of SETVER.EXE driver (5.01-02) in order to enable QBASIC.EXE usage under MS-DOS 7.

The next group of lines in VC.EXT file directs picture files to picture viewer LXPIC.COM, developed by Stefan Peichl. Version 7.3 of this viewer (dated 2002), packed into archive LXPIC.ZIP, can be downloaded from internet site http://hplx.pgdn.de/.

Further in VC.EXT file a large group of suffixes is enlisted (, , etc.), which usually denote textual files. The main problem of reading textual files in russian is caused by a large variety of possible codes. This problem is solved by utility EMAGIC.EXE, written by Sergey Gernshtein. EMAGIC.EXE analyses statistics of text, determines the type of code and then automatically translates text into codepage CP866. Archive EMAGIC.ZIP with EMAGIC.EXE utility inside can be downloaded from internet ftp-server ftp://ftp.botik.ru/pub/msdos/convert/. Those, who don't use codepage CP866, are suggested to delete a line with a call for EMAGIC.EXE out of VC.EXT file.

Display of textual files on the screen is a mission of viewer SVTXT.COM, written by Lo Hung Che for FreeDos project. This viewer, packed in archive PG116.ZIP, can be downloaded from server ftp://sunsite.unc.edu/pub/micro/pc-stuff/freedos/files/util/file/pg/. The SVTXT.COM viewer shows long textual lines in wrapped form and is able to cope with the first 64 kb of indefinitely long files. The SVTXT.COM viewer can't extract parts of text, but this can be done later with EDIT.COM editor (6.09), because a copy of the shown text, translated into codepage CP866, will be saved as T.TXT file in a directory intended for temporary files.

Hypertext files with  suffix may be treated just as ordinary textual files, if their hypertext markup is taken off beforehand. The latter mission is performed by HTML2TXT.COM utility, written by Shin Chan. Archive HTML2T08.LZH, containing the HTML2TXT.COM utility, can be downloaded from internet site http://www.vector.co.jp/download/file/dos/net/fh050307.html. The shown sequence of hypertext file's translations can't be recommended for those who don't read in russian. It is better for them to send *.HTM files directly to hypertext viewer VH.EXE. This viewer, packed into VIEWHT25.ZIP archive, can be downloaded from internet server ftp://ftp.bu.edu/pub/mirrors/simtelnet/msdos/html/.

Suffix  most often marks command files for debugger DEBUG.EXE, but there may be exceptions. Besides that, execution of some debugger's command files may inflict undesirable consequences. Therefore for files with  suffix a query is issued by Volkov Commander. If the user responds to the query with ENTER keystroke, command file will be sent to debugger, and the returned listing will be presented for editing on the screen. This procedure is very convenient for correcting those errors in command files, which are revealed in returned listing (9.07-01).

Files with  suffix are images of diskettes. These files may be either subjected to unpacking or written back onto a diskette. An appeal to user's choice compels to create a new submenu. Let it be named DISKIMG.MNU. In this submenu writing to disk is performed by utility IMG.EXE, and unpacking – by utility DDI2HDD.EXE. Both these utilities can be downloaded from internet ftp-server ftp://ftp.elf.stuba.sk/pub/pc/utildisk/ inside archives IMG.ARJ and DDI2HDD.ZIP accordingly. An example of submenu is shown below ; its text must be stored as unformatted textual file DISKIMG.MNU in common directory with other VC's configuration files. In DISKIMG.MNU, just as in VC.MNU, names of "hot keys" must be typed just at the left edges of lines without preceding spaces.

While composing your own samples of VC's extension files you have to keep in mind, that besides explicitly specified operations Volkov Commander performs some implicit suffix-dependent processing. In particular, after interpretation of all lines in VC.EXT file, selected files with,   and   suffixes are by default transferred to command interpreter for execution, and archive files are further processed according to specifications in VCARCH.EXT file (6.25-04). If the mentioned suffixes are specified inside VC.EXT file, then the default treatment of the corresponding files will be intercepted and wouldn't be performed. Because of this reason suffixes of archives and of executable files are not specified in VC.EXT.

Similarly, after F3 (VIEW) keystroke Volkov Commander transfers to its internal viewer only those files, which are not intercepted by suffix specifications in extension file VCVIEW.EXT. Internal VC's viewer shows contents of any file in binary and textual forms. The opportunity to view any file "as it is" is itself valuable, and therefore the VCVIEW.EXT file, in my opinion, is not needed. If your opinion is different, you may write your own version of VCVIEW.EXT, taking the shown VC.EXT file as example. Syntax of records in VCVIEW.EXT and VC.EXT files is identical.

When a file, which is to be viewed or edited, is selected inside an opened archive in active panel, then both F3 and F4 keystrokes invoke file's unpacking from that archive into temporary directory %TEMP%\VC.000. Then the  mark in lines of VCVIEW.EXT and VCEDIT.EXT files is replaced by corresponding macro with name of the unpacked file, preceded by path to that temporary directory. Thus the F3 keystroke enables viewing inside archives without their explicit unpacking. Similarly the F4 keystroke subjects the unpacked file to just any operation, specified in lines of VCEDIT.EXT file.

Editing operation isn't as safe as viewing: the editor program may inflict damage to the subjected file, especially harmful, when the subjected file is not an unpacked copy. Succession of commands in VCEDIT.EXT file must protect susceptible non-textual files against accidental damage. Therefore binary files and archives in the example below are intercepted by an empty operation (REM) and thus escape the risk of being damaged.

Picture files are protected by separate interception : it enables to view pictures inside archives. All the rest files are directed to editor program by asterisk wildcard specification (instead of suffix) in the last line. As far as version 4.99.07 of Volkov Commander provides no internal editor, in the proposed example of VCEDIT.EXT file the EDIT.COM editor (6.09) is charged with this mission.


 * Notes
 * 1) All  files are read by VC shell once when it starts. Changes in   files will not come into effect unless VC shell is shut down and then launched anew.
 * 2) In VC's extension files all lines beginning with a quote sign are skipped. The rest part of these lines may be filled with commentaries.

6.25-04 Archives processing configuration file VCARCH.EXT
In panels of VC's version 4.99.07 archives can be opened just as directories. This feature is achieved by intercepting STDOUT output of archiver utilities and parsing it word-by-word according to a predetermined order. If the output line is found conforming to the order, then selected words from this line can be identified as a name of a file, its date, length, etc. These data are displayed in VC's panel just as it is done for an ordinary directory.

As far as output data display format is not the same for different archiver utilities, VC shell has to adapt the parsing order according to type of archive file, defined by its suffix. Parsing order models for different archive types are specified in configuration file VCARCH.EXT. Moreover, VCARCH.EXT enables to specify several parsing order models for archives of one type, and the output line will be parsed if it is found conforming to at least one model.

VCARCH.EXT consists of separate entries for each archive type, each entry is up to 5 lines long. The first line in each entry defines archive suffix (it must be specified just at the left edge of the line) and corresponding parsing order model(s). Suffix is separated from parsing order model(s) with a colon. Definitions of parsing order models are composed of space separators and upper case characters, interpreted in the following way :

The next four lines in each entry commence with at least one space and define calls to the corresponding archiver utility for performing particular operations :

Unpacking operation, specified in the 3rd line, can also be initiated by F3 (view) and F4 (edit) keys. In this case the result of unpacking is written into directory for temporary files and is immediately presented for viewing or editing according to specifications in extension files VCVIEW.EXT and VCEDIT.EXT.

Out of a large variety of archive types only a few are actively used for packing. Most part of other entries in VCARCH.EXT file is preserved for a single purpose: for access to archives types, which may be occasionally encountered in software stores. Entries for such archive types in VCARCH.EXT file may be reduced to three lines.

During interpretation of command lines in VCARCH.EXT file Volkov Commander gives no access to environmental variables, but provides specific macros, which differ from those available in other extension files. Macro command calls in VCARCH.EXT file are induced by the following marks :

Proposed examples of entries for VCARCH.EXT file are shown below. All executable files, mentioned in entry examples, must be accessible along path(s), specified in value of environmental variable  (2.02-02).

Volkov Commander's version 4.99.07 release is supplemented with VCARCH.EXT file, containing entries for many archive types. Examples of entries, shown in this article, shouldn't be regarded as a complete VCARCH.EXT file. These examples represent separate entries, which differ from those in original release. Proposed entries may be added to original VCARCH.EXT file or may replace original entries in this file. All archiver programs, mentioned in proposed entries, can be downloaded from a vast collection of archivers in ftp-server ftp://ftp.elf.stuba.sk/pub/pc/pack/.

6.26 XCOPY.EXE – copying utility
The XCOPY.EXE utility copies files and can copy directories with all their contents, including subdirectories. XCOPY.EXE needs an auxiliary file XCOPY32.EXE to be present in the same directory. A command line with a call for XCOPY.EXE may look like this :

where:

<ol> <li id="note-6.26-1">Being launched under MS-DOS, XCOPY.EXE can't copy files having H (Hidden) or S (System) attributes. This and some other functions can be performed by XCOPY.EXE inside Windows's "DOS box" only.</li> <li id="note-6.26-2">^ Data format, specified after the  parameter, depends on national settings, defined by COUNTRY command (4.05). In any case data format must be just that returned by DATE command (3.08).</li> <li id="note-6.26-3">In MS-DOS 8 auxiliary file XCOPY32.EXE is renamed to XCOPY32.MOD.</li> <li id="note-6.26-4">A synonymous utility XCOPY.EXE has been written as a part of FreeDOS project in 2003 by Rene Ableidinger. This utility needs no auxiliary files and is able to copy files with HS attributes under MS-DOS 7. Archive RXCOPY2.ZIP, containing this utility, can be downloaded from internet server ftp://sunsite.unc.edu/pub/micro/pc-stuff/freedos/files/dos/</li> </ol>
 * Notes