Simtel MSDOS 1992 June

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / info / dostips6.arc / DOSMISC < prev next >

Wrap

Text File | 1987-02-22 | 20.0 KB | 476 lines

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 <Esc>[0;32;"DIR /P";13p The <Esc> 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: <Esc>[0;65;"DIR";13p <Esc>[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.