Category : Tutorials + Patches
Archive   : DOSTIPS6.ZIP
Filename : DOSMISC

Diagnostic Shortcut
(PC Magazine Vol 6 No 1 Jan 13, 1987 User-to-User)

A user had to use the IBM Diagnostics disk on his PC, but since
the problem was elusive he had to run multiple tests with errors
logged to the printer. This led to two problems that were both solved
by a single trick. The first problem arose because the disk drives
are tested in every loop. He was certain that there was no problem
in the disk drives, and the disk drive tests are time-consuming and
put a lot of wear and tear on the drives. The second problem arose
because the diagnostics do not provide a count of the number of loops
that have been run.
The trick is to put write-protected disks in the disk drives. The
diagnostics will quickly detect that a disk is write-protected, abort
the test on that drive, send an error message to the printer, and move
on to the next test. On a two-disk-drive system, each loop generates
two write-protect errors and one disk drive error. You can determine
the number of loops by counting the number of error sets.
The same effect can be achieved by putting no disks in the drives,
but the diagnostics take much longer to decide that there is no disk
in a drive than to decide that there is a write-protected disk in the
drive.
Editor's Note: This technique makes it less traumatic to figure
out what's wrong with your system. It was good of IBM to distribute
diagnostic disks, but it should have included a decent section in the
Guide to Operations explaining what all the tests do and what any
reported error codes mean. And it should also have given you a real
menu that lets you jump to the appropriate test rather than forcing
you to wade through the whole routine. But while the GTO is pathetic
about defining errors, IBM's Hardware Maintenance and Service manuals
are terrific. They tell you what tools you need, explain everything
in absorbing detail, and flowchart you painlessly through the testing
procedures. It's all clear and concise, and the manual is crammed
with helpful illustrations. And you get a copy of the Advanced
Diagnostics with it.

-----------------------------------------------------------------
Memory Checker
(PC Magazine Vol 6 No 1 Jan 13, 1987 User-to-User)

With all the memory-resident programs and different ways that you
can configure these programs -- as well as your own system -- with
buffers, it would be nice to know how much available memory is left
for your applications programs.
MEMORY.COM is a simple program that returns the current free RAM.
To create MEMORY.COM, run the following MEMORY.SCR file with DEBUG:

DEBUG < MEMORY.SCR

Be sure the blank line after DB 0 near the end of the program is
there; it's necessary. You must have DOS 2.0 or later for MEMORY.COM.
MEMORY.COM reports bytes free in Ks (1024s) while CHKDSK reports them
in 1000s.

A
XOR BX,BX
MOV AH,4A
INT 21
MOV AH,48
MOV BX,FFFF
INT 21
MOV AX,BX
XOR DX,DX
MOV CX,40
DIV CX
CMP DX,20
JB 11C
INC AX
MOV BX,AX
MOV CX,64
CALL 139
MOV CX,A
CALL 139
MOV CX,1
CALL 139
MOV DX,15C
MOV AH,9
INT 21
INT 20
MOV AX,BX
XOR DX,DX
DIV CX
MOV BX,DX
MOV DL,AL
CMP AL,0
JZ 14B
OR [15B],AL
CMP BYTE PTR [15B],0
JA 153
RET
ADD DL,30
MOV AH,2
INT 21
RET
DB 0

E 15C "K Bytes free$"
RCX
69
N MEMORY.COM
W
Q

-----------------------------------------------------------------
What is a PIF?
(PC Magazine Vol 6 No 1 Jan 13, 1987 PC Tutor)

PIF stands for "Program Information File." IBM invented the .PIF
file for use with its TopView operating environment. Although TopView
has pretty much bitten the dust, Microsoft has also used .PIF files for
its Windows operating environment.
There are several different kinds of programs you can run under
Microsoft Windows. The first category is a "Windows application."
This is a program specifically written for Windows, and it does not
run under plain DOS. This category includes the utilities that come
with Windows (Write, Paint, Clock, etc.) and a few programs from other
manufacturers. Many normal programs that run under DOS can still run
under Windows, however. These programs are called either "standard
applications" or "old applications."
When you want to run an old application under Windows, Windows
looks for a .PIF file with the name of that application. The .PIF file
contains information about the program. Among other things, it tells
Windows how much memory the application needs and just how "well
behaved" the program is.
The "well behaved" criterion covers several items, but in most
cases it comes down to the following question: Does the application
write directly to the display memory? In the case of virtually all
word processors, spreadsheets, and graphics programs, the answer is
yes. Windows cannot run these programs in a window, and it cannot
multitask them. Windows must give up the entire display because it
has no way of knowing when the program will write to the screen.
A program that does not write directly to display memory (but
instead goes through DOS or the BIOS to display something on the
screen) can be run in a window, share the screen with other
applications, and be multitasked.
These two categories of programs not designed to run under Windows
are sometimes called "bad applications" (cannot be run in a window) and
"good old applications" (can run in a window). The terms "good" and
"bad" here denote only how the program uses the hardware of the PC and
not how well the program works. Some of the best programs around are
"bad applications" as far as Windows is concerned. Some of them are
so bad they cannot be run under Windows at all. The "baddest" program
of them all, for instance, is probably SideKick.
Windows also allows "good old applications" to be listed in the
WIN.INI file so they don't need .PIF files. If you try to run an old
application under Windows without a .PIF file, Windows will ask if you
want to use the default .PIF settings, which assume that it's a "bad
application."
Windows includes a program called PIFEDIT to create or modify .PIF
files. The actual internal format of the .PIF file is documented in
IBM's TopView Programmer's Toolkit.
The .PIF file is a convenient way for an advanced operating system
to deal with programs written for the anarchic "anything goes" DOS
environment. A .PIF file (or something like it) may appear to play an
important role in a future version of DOS that supports the PC AT's
80286 microprocessor in protected mode.

-----------------------------------------------------------------
Another ANSI Solution
(PC Magazine Vol 6 No 3 Feb 10, 1987 PC Tutor)

You can use ANSI.SYS to redefine the keyboard. For example, to
execute the command line "DIR/P" by hitting an Alt-D on the keyboard,
you can include the following line in your AUTOEXEC.BAT file (ANSI.SYS
must be loaded by including the line DEVICE=ANSI.SYS in your CONFIG.SYS
file):

ECHO [0;32;"DIR /P";13p

The doesn't mean the characters <, E, s, c, and >. It means the
ASCII escape character must be there. The escape character is a
difficult character to enter in many text editors. It's fairly easy
in EDLIN, however: you type a Ctrl-V followed by a left bracket. So,
when typin in the line in EDLIN, you would actually type: ECHO, a
space, a Ctrl-V, a left bracket, another left bracket, a 0, and so on.
The 0;32 means that you're defining an extended keyboard key that
has a code of 32. That's the Alt-D combination. The 13 means a
carriage return, and the p at the end identifies the control sequence
as a keyboard redefinition.
In this example, you can't use $e to represent the escape character
because that's something only the PROMPT command understands. However,
you can use the PROMPT command instead of ECHO for redefining the keys,
as shown in the next item.

-----------------------------------------------------------------
And an ANSI Problem
(PC Magazine Vol 6 No 3 Feb 10, 1987 PC Tutor)

Using ANSI.SYS and the PROMPT command, the following lines were
included in an AUTOEXEC.BAT file in an effort to redefine the function
keys:

PROMPT $e[0;64;"DIR";13p
PROMPT $e[0;66;"DIR /W";13p
PROMPT $e[0;67;"DIR /P";13p
PROMPT $e[0;68;"CLS";13p
PROMPT $e[33;44m$n$g$e[36;44m

The first four PROMPT commands redefine the function keys F8 through
F10. The last PROMPT command sets the prompt to brown-on-blue and the
text to cyan-on-blue.
When rebooting, every command flashes on the screen. ECHO OFF
cannot be added preceding the PROMPT commands, because it prevents the
PROMPT commands from executing.
The reason is ANSI.SYS is a video display driver. It will
interpret a control sequence only if some program makes an attempt to
display the control sequence on the screen. ANSI.SYS doesn't put the
control sequence on the screen because it recognizes it as a command
to do something (in this case, to redefine a key) rather than
displayable text.
When COMMAND.COM executes the batch file, then, the line with the
first PROMPT command is displayed on the screen. You'll see the whole
PROMPT command just as you've type it because that's not the control
sequence. An ANSI control sequence begins with an escape code and the
PROMPT argument begins with a $e. COMMAND.COM then executes this
PROMPT command, which sets a new prompt.
Next, COMMAND.COM displays the new prompt, followed by the next
line in the batch file. As it displays the new prompt, COMMAND.COM
replaces the $e with an escape code. That makes the new prompt an
ANSI control sequence. You won't see the new prompt on the screen
because ANSI.SYS interprets it as a command to redefine a key.
When you use ECHO OFF, COMMAND.COM doesn't display the prompt for
each line it executes. If it doesn't display these prompt, ANSI.SYS
never sees them. Thus, the keys don't get redefined.
If you want to use ECHO OFF, use an ECHO command instead of
PROMPT for the first four lines and replace the $e with an escape
code. Alternatively, you can place all the ANSI.SYS key redefinition
control sequences in a separate file (call it KEY.DAT) that looks like:

[0;65;"DIR";13p
[0;66;"DIR /W";13p

and so forth. You can even put them all on one line if you want.
Then, in your AUTOEXEC.BAT, you can display this file to the screen
(and have ANSI.SYS redefine the keys) by the command:

TYPE KEY.DAT

If you've done it right, you won't see the KEY.DAT file.

-----------------------------------------------------------------
Powerful F3 Tricks
(PC Magazine Vol 6 No 4 Feb 24, 1987 User-to-User)

Most users alrady know about the muscle of the F3 key, which
repeats the previous DOS command. You can use the F3 key in conjuction
with the Ins and Del keys to adapt the previous command.
Even better, if you want to repeat a DOS command but want to do
an intermediate DOS command before you repeat it, you can "park" the
command you want to repeat by hitting the Ins key, typing in the
intermediate command and adding an extra space at the end of it,
hitting the F3 to put the previous command at the end of the line,
and then hitting Enter.
DOS will stop reading when it sees the extra space and will
execute the intermediate command. Then you simply tap the Del key
the correct number of times to erase the intermediate command, hit F3,
and you have the original command back that you "parked." However,
this works only with certain DOS command that don't read switches off
the command line.
Two other sterling uses of the F3 key are in verifying copies and
deleting after copies are made.
If you want to copy all the .COM files from C:\DOS\BIN\UTILS to
B:, you could type:

COPY C:\DOS\BIN\UTILS\*.COM B:

To check whether the copies wer valid, you could type:

COMP

and hit the F3 key. Since the COPY and COMP instructions are the same
length and share the same command structure, this makes verifying the
copies a painless process. (You could have added a /V switch to the
end of the COPY command, but this doesn't do a real line-by-line or
byte-by-byte comparison the way COMP of FC or a real compare program
does.)
Another handy F3 technique is moving files from one subdirectory
to another. If you wanted to move:

C:\DOS\BIN\UTILS\COLOR.COM

to the current subdirectory, you could type:

COPY C:\DOS\BIN\UTILS\COLOR.COM

(and then COMP it if you wanted, by hitting COMP and then F3). Then
you can delete the original by typing:

DEL

and then tapping once on the space bar (since DEL is one character
shorter than COPY) and then hitting F3 and Enter.
Of course, when moving, copying, and deleting files, it may be
better to run the operation out of batch files.
Speaking of batch files, here are two related ones that let you
delete files selectively. They'll display the files you want deleted
and offer you the chance to delete them or leave them alone. The only
strictly non-DOS part is a tiny GETYES.COM utility that handles an
IF ERRORLEVEL branching operation. First, create a batch file called
DELETE.BAT:

ECHO OFF
IF %1!==! GOTO OOPS
FOR %%i IN (%1) DO COMMAND /C D %%i
GOTO END
:OOPS
ECHO Enter a filespec (like *.COM)
:END

Then create a companion batch file called D.BAT:

ECHO OFF
ECHO Delete %1 (Y/N)?
GETYES
IF ERRORLEVEL 255 GOTO DOIT
ECHO %1 NOT deleted ...
GOTO END
:DOIT
DEL %1
ECHO %1 deleted...
:END

To make this work, you need GETYES.COM. Use the GETYES.SCR below.
Make sure you leave a blank line after INT 21 and hit the Enter key
after each line, especially the last one. Then put GETYES.SCR and
DEBUG on a disk and at the DOS prompt type: DEBUG < GETYES.SCR

A
MOV AH,00
INT 16
CMP AL,59
JZ 010C
CMP AL,79
JNZ 010E
MOV AL,FF
MOV AH,4C
INT 21

N GETYES.COM
RCX
12
W
Q

(To use N and n rather than Y and y to trigger ERRORLEVEL, substitute
4E and 6E for 59 and 79, and change GETYES.COM to GETNO.COM.)
This may seem like a lot of files and a lot of typing, but it can
save you lots of anguish. To use it, just type DELETE followed by a
filespec (such as C*.* or *.COM). The batch files will display the
names of all matching files one by one and ask whether or not you wnat
to delete them. If you answer Y (or y) the file will be erased; an N
(or n) will skip over a file without erasing.

-----------------------------------------------------------------
No Bytes
(PC Magazine Vol 6 No 5 Mar 10, 1987 User-to-User)

Say you need a 0-byte file called XS.SYS. You can redirect the
output of a batch file to the file called XS.SYS. Create TEST.BAT as
follows:

COPY CON:TEST.BAT
GO

Then type:

TEST > XS.SYS

(You should get a "Bad filename" or "File not found" message; ignore
it.) Now issue a DIR command and you'll see a listing for XS.SYS that
is 0 bytes long.
An easier way to create a 0-length file named XS.SYS is to use
DEBUG:

DEBUG XS.SYS
W
Q

Again, ignore the "File not found" message.

-----------------------------------------------------------------
DEBUG and Disk Sectors
(PC Magazine Vol 6 No 5 Mar 10, 1987 PC Tutor)

DEBUG can be used to turn on the "hidden" attribute of a file or
directory on a floppy disk ("Keeping Your Files Private," PC Magazine
Vol 5 No 16 September 30, 1986). It can also be used to hide a
directory on a hard disk.

However, USING DEBUG TO ALTER DIRECTORY INFORMATION IS NOT
RECOMMENDED!!!!!

It's not so bad with a floppy disk because the worst that can
happen is that you lose 360K of data. With a hard disk, however, you
could lose the contents of the entire disk!!!! There is just too much
that could go wrong when you use the DEBUG L and W commands to modify
disk sectors.
There is also the problem of the sector where the root directory
on a hard disk begins. The root directory does not always begin a
specific sector. Its starting point depends upon the size of the hard
disk, the size of the DOS partition, and whether the file allocation
table contains 12-bit or 16-bit cluster entries.
The DOS function call that reports the starting sector of the
root directory has not been documented by Microsoft. (Some unofficial
documentation of this function call can be bound in "Diskscan Finds
Bad Sectors" in PC Magazine Vol 5 No 8 April 29, 1986.) Even with this
information, however, you can find the location of noly the root
directory. Subdirectories may be anywhere on the hard disk. You would
have to find the starting cluster number of the subdirectory from the
root directory, convert that to a sector number, and then load that
sector into DEBUG.
A much better method for changing file attributes is ATTR, a
program in PC Magazine Vol 5 No 11 June 10, 1986.
Nevertheless, this is how to do something that you don't want to
do.
To modify the root directory on a hard disk directly, you must
first determine the location of the root directory. You can do this
with information from the boot sector, which is sector 0. (This
information may not appear on a disk that is not bootable or that uses
its own driver files.) Load sector 0 of the hard disk into DEBUG with:

L 100 2 0 1

The 100 is the memory address where the sector is to be loaded, 2
refers to drive C, 0 means sector 0, and 1 means "read 1 sector."
Now do a DEBUG D command. The 2 bytes at offset 10Eh are the
number of "reserved sectors" and will probably be 1. (Remember to
switch the order of the 2 bytes to convert them into a word.) The
single byte at offset 100h is the number of the file allocation
tables (FATs). This will probably be 2. The 2 bytes at offset 116h
contain the number of sectors per FAT. On one particular 30-megabyte
hard disk this is 3Dh, or 59 in decimal. (Different 30-megabyte hard
disks may be different.) Multiply the number of FATs by the number
of sectors per FAT. Add the number of reserved sectors. For the 30-
megabyte hard disk on which this technique was explored, it came to
7Bh. That is the sector where the root directory begins.
The size of the root directory can be calculated just as easily,
though remember that you really don't want to do this. The number of
root directory entries is the word at offset 111h. For most hard
disks, this will equal 200h, or 512 decimal. Multiply this by 20h
(32 decimal), which is the number of bytes per directory entry. That
comes out to 4000h, which is 32,768 in decimal. Now divide that number
by the bytes per sector, which is the word at offset 10Bh and should be
200h (512 bytes). The result is 20h (32 decimal) sectors for the
length of the root directory.
(The information on the layout of the boot sector is documented
in the DOS Technical Reference manual in the section on device
drivers.)
You can load the root directory into DEBUG with the command:

L 100 2 7B 20

You should use the number you calculated for the starting sector of
your root directory instead of the 7B above, and the number you
calculated for the length of your root directory instead of 20. After
you do this you can see your entire root directory by executing:

D 100 L 4000

If you're still all right here, you can follow the directions given in
"Keeping Your Files Private" for modifying the attribute byte of a
file or directory. When you're done, take a deep breath and type
carefully:

W 100 2 7B 20

again substituting your own calculated values for the 7B and 20.
Notice that the W and L commands shown here use the same parameters.
That's the easiest and safest way to make sure that what you loaded
from the disk gets written back to the same place.
Again, using DEBUG to modify any disk directly is dangerous if
you value the data on the disk. If you try it and mess up your disk,
it's your own fault. Besides, ATTR.COM does the job much more
easily.