DOS Batch files - Master Class

Concepts

  • In theory, a batch file is nothing more than a recording of any series of commands that you would issue at the command prompt. As such a batch file can automate a large and repetitive task and save the user from having to type a series of commands to configure the system and run a program every time the system starts up. In that case those commands would be ideally placed into the AUTOEXEC.BAT file. This is a plain batch file in content and the only thing that makes it unique is that when COMMAND.COM loads it will search for a file in the root of the booting diskette or partition with this exact name, if COMMAND.COM finds it then it will automatically execute it during the boot up process prior to issuing the first command prompt.

  • So when a batch file is "executed" what really happens is that COMMAND.COM recognizes the .BAT extension and opens the file and begins reading it line by line. As it reads in the first line it will process it like a normal command that would have been issued at the command prompt. Therefore any command that will work at the command prompt will also work in a batch file. There are some strange circumstances in which some commands will not work, but this is extremely rare and usually has to do with software that has timing issues or other bizarre circumstances like that. 

    dir 
pause
dir /w
pause
dir /o

    (See PAUSE below). Copy and paste the above into a Notepad file and save it as DIRP.BAT. Notepad insists on sticking the .TXT on the end of file names, so in the Save As dialog box, pull down the Save As Type and select "(*.*) All Files", then name it and click Save. Open a DOS box and change to the "C:\MYDOCU~1" folder and execute the batch file:

    C:\WINDOWS>cd\mydocu~1
C:\MYDOCU~1>dirp
...

  • COMMAND.COM in addition to the fact that it will recognize and execute any internal command will also perform the standard search sequence and execution of external commands exactly as if they were also issued from the command prompt as well.

  • COMMAND.COM maintains a current drive and current path during the execution of the batch file and this is critical to the success of commands that need to refer to files by name. If the path reference is wrong then the batch file will fail with errors. 

    dir 
pause
cd\
dir 
pause
cd\windows
dir /o /p

    Copy and paste the above into a notepad window and save it as DIRP2.BAT in My Documents. Open a DOS box, change to "C:\MYDOCU~1" and execute it. When it ends notice where the DOS prompt is now compared to when the batch file was first executed.

  • COMMAND.COM has a few internal commands that are unique to batch files and make them more powerful than just a list of commands to execute. The "DOS batch programming language" is incredibly weak, but it does have some limited logical processing power that can be utilized to create very powerful batch files that are almost indistinguishable from real EXE's. 

    if exist dirp.bat goto good
echo Where is the first example batch file from this page?
goto end
:good
echo Excellent! Be sure to try each example.
:end

    (See IF and GOTO below).Again, copy and paste the above batch file into notepad and save it as EX1.BAT in My Documents. Open a DOS box and change to C:\MYDOCU~1 and execute it:

    C:\WINDOWS>cd\mydocu~1
C:\MYDOCU~1>ex1
C:\MYDOCU~1>if exist dirp.bat goto good
C:\MYDOCU~1>echo Excellent! Be sure to try each example.
Excellent! Be sure to try each example.
C:\MYDOCU~1>_

  • COMMAND.COM supports references to environmental variables from within batch files and it also supports references to commandline parameters so that you can pass parameters to the batch file from the commandline just like a real EXE: 

    if %COMSPEC%=="C:\WINDOWS\COMMAND.COM" goto winc
if %COMSPEC%=="C:\COMMAND.COM" goto dosc
if %COMSPEC%=="A:\COMMAND.COM" goto flop
echo Where did you boot from?
goto end
:winc
echo Your boot HDD has a full Windows installation.
goto end
echo You booted from the HDD.
goto end
echo You booted from a floppy.
goto end

    (See DOS Environmental Variables). Try this batch file from a DOS box, then boot to a floppy and try it.

  • The conventions used in DOS boxes on this page (and throughout this site) are: white text: DOS output to the screen, green text: input that you must type at the screen, yellow text: notes explaining what is happening.

Procedures

  •  Automatic Floppy Format with Finished Chime:

    This one will be developed in stages. It turns out that FORMAT.COM does have an undocumented switch which works almost as well as this batch file: "/autotest" but the batch file can still be made to look and feel quite nice and offer options that the plain and simple FORMAT switch cannot do.

    First insert a blank diskette into the A: drive and open a DOS box. Run format a: /q/u/s and remember each input you must give to FORMAT. You press: [Enter], [Enter], [N], [Enter]. Now use COPY CON to create an input file for the FORMAT command:

    C:\TECHDISK>cd \windows\command
    C:\TECHDISK>copy con fmt.ans
    [Enter]
    [Enter]
    N[Enter]
    ^Z <-[F6] key!
       1 file(s) copied.

    Now insert the floppy and execute the command and use the commandline redirector to feed it the answer file:

    C:\WINDOWS\COMMAND>format a: /q/u/s < fmt.ans
...

    The format should proceed to completion and return to the prompt with no need to press any keys. The answers will be taken from the answer file as they are needed. If the process hangs, then close the DOS box and do the manual FORMAT again and monitor the keyboard answers then create the answer file again and then try again.

    Now while still in the C:\WINDOWS\COMMAND directory execute the following: 

    C:\WINDOWS\COMMAND>copy con bell.txt
^G^Z <=[Ctrl]+[G] then [F6])
 1 file(s) copied
C:\WINDOWS\COMMAND>_

    This places ASCII character code 7 into the text file. When the system attempts to "print" an ASCII 7 it beeps the speaker instead.

    Now that the FORMAT can proceed unattended and we can beep the speaker, we can create a batch file to execute all of these instructions:

    C:\WINDOWS\COMMAND>copy con fmt.bat
c: <= change to C: drive
cd \windows\command <= change to this working directory
format a: /q/u/s < fmt.ans <= perform unattended format
type bell.txt <= beep the speaker after the format
^Z <= end of the batch file
 1 file(s) copied
C:\WINDOWS\COMMAND>_

    Now insert a floppy diskette into the A: drive and type FMT at the prompt. The batch file should format the floppy and then beep the speaker when done.

  •  Cleaning up the Display of FMT.BAT:

    As COMMAND.COM executes each command within the batch file it displays it on screen. It is not really necessary to see these commands and they are actually rather ugly and since FORMAT will execute automatically and the batch file will beep the speaker when it is done, the entire output of the FORMAT command is unnecessary and rather unsightly as well. Open FMT.BAT in Notepad and add these lines:

    @echo off <= suppresses display of all subsequent commands to screen
echo Formatting A: . . . <= displays this simple message
c: 
cd \windows\command
format a: /q/u/s < fmt.ans > nul<= redirect output of FORMAT to nul = nowhere
type bell.txt

    Save the changes and execute the command again. The output to the screen is simply the message that we need:

    C:\WINDOWS\COMMAND>fmt
Formatting A: . . .
C:\WINDOWS\COMMAND>_
  •  Integrating FMT.BAT into Windows 98

    For now you can check out the integration of batch files, file associations and the Windows Scripting Host tutorial. More information on these subjects will be added here.

  •  Windows 98 Boot Logger:

    First open the DOS box in Windows 98: Start > Programs > MS-DOS Prompt. Then change to the root of the C: drive and create a folder named "STAY OUT" (without the quotes, please). The space however, is NOT a space made by the spacebar of the keyboard. The space is an illegal character and will never work. Instead it is an extended ASCII character number 255. (See Extended ASCII Characters for how to create one at the command prompt). Once this is done, change into that new directory:

    C:\WINDOWS>cd \
    C:\>md stay out
    C:\>cd stay out
    C:\STAY OUT>_

    Now open EDIT and type in the following batch file lines:

       File    Edit    Search    Options    Help    
      Untitled  
    ECHO System Boot Up Occured >> BOOT.LOG
    ECHO ================================ >> BOOT.LOG
    ECHO. | DATE | FIND /i "current" >> BOOT.LOG
    ECHO. | TIME | FIND /i "current" >> BOOT.LOG

    A little trick is employed here using the ECHO command and the DOS redirectors. It turns out that someone needed a command that would output just a "carriage return" and "line feed" with nothing else. The carriage return and line feed characters back to back are the [Enter] key. So the feature was added to the ECHO command. If ECHO is followed immediately by a period (no space between the command and the period) then it will output the pair of control characters effectively outputting the press of the [Enter] key. Using the "pipe" redirector, this is forwarded to the DATE command which will display the "current" Date and await the user to enter the new date or hit the [Enter] key to quit the DATE command. Since we "piped" it an [Enter] key from the ECHO command it will display this information and immediately quit. Now, DATE's output is captured away from the screen and "piped" to the next command: FIND. FIND has been asked to find the line of text that contains the word "current" and only display that one. But wait...that output has been captured from the screen and been appended to the existing file BOOT.LOG using the append redirector. Whew!

    The same is then done for the TIME command which functions exactly like the DATE command. So the current date and the current time are both written into the file. If these instructions are now saved into a batch file and were to get executed at boot up, then the current date and time at boot up would get recorded into the log file. This is the desired effect. Save the file as "DRIVER.BAT" (a purposely misleading name...heh, heh, heh) in the root of the C: drive and we will see how to add the change directory command with the extended ASCII character in it. From the root execute the following command:

    C:\>copy con + driver.bat driver.bat
    Overwrite the file DRIVER.BAT [Y/N]?y
    CON
    @ECHO OFF
    REM Driver.bat logs each boot up into C:\STAY OUT\BOOT.LOG
    CD STAY OUT
           ^
           This is the extended character!
    ^Z <-This is made with the [F6] key!
    DRIVER.BAT
       1 file(s) copied
    C:\>_

    The extended characters cannot be typed into EDIT with any reliability so we use COPY CON to add the lines in front of the existing ones using the COPY command's ability to concatenate files together with the "+" operator. So the construction copy con + driver.bat means: "We will take input from the keyboard first and when that file is done we will attach DRIVER.BAT to the end of it." The second driver.bat in the command means: "and save the resulting concatenation of files as DRIVER.BAT." This is why COPY asks right away if you are sure you want to overwrite the existing file.

    One last thing: we better add the line to the end of the batch file to change out of the STAY OUT directory because Windows 98 does not like that ASCII character 255 at all:

    C:\>echo cd.. >> driver.bat
    C:\>_

    (See Using ECHO to create a one line text file, in our case here we use the append redirector to add the text to the end of the existing file). That does it. Now reboot the system and then open a DOS box and change into the STAY OUT folder and read the text file. Here is what the system in the lab did:

    C:\WINDOWS>cd ..
    C:\>cd stay out
    C:\STAY OUT>type boot.log
    System Boot Up Occured
    ===========================
    Current date is: Sat 12-13-2003
    Current time is: 2:27:00.04p

    C:\STAY OUT>_

  •  Automatic Technician's Boot Diskette Maker

    First open a DOS box and create the directory "TECHDISK" in the root of the C: drive. Then move into it and copy all files that you would like to put onto the technician's boot diskette:

    C:\WINDOWS>cd ..
    C:\>md techdisk
    C:\>cd techdisk
    C:\TECHDISK>copy \windows\himem.sys
       1 file(s) copied.
    C:\TECHDISK>copy \windows\command\fdisk.exe
       1 file(s) copied.
    C:\TECHDISK>copy \windows\command\format.com
       1 file(s) copied.
    C:\TECHDISK>copy \windows\command\attrib.exe
       1 file(s) copied.
    C:\TECHDISK>copy \windows\command\smartdrv.exe
       1 file(s) copied.
    C:\TECHDISK>copy \windows\command\mscdex.exe
       1 file(s) copied.

    See Commandline Shortcuts and Doskey for more information on how all of these copies can be made quickly and easily. OAKCDROM.SYS would be a nice addition to the technician's diskette but it did not unpack from the CAB's during installation of Windows 98 on this particular machine. So we will have to go extract it from the CAB's (See Using the Extract command for details):

    C:\TECHDISK>extract /a /d d:\win98\base4.cab oakcdrom.sys | more

    Microsoft (R) Cabinet Extraction Tool - Version (16) 1.00.603.0 (08/14/97)
    Copyright (c) Microsoft Corp 1994-1997. All rights reserved.

    Cabinet base4.cab


    Cabinet BASE5.CAB

    04-23-1999 10:22:00p A---      41,302 oakcdrom.sys

    Cabinet BASE6.CAB


    Cabinet NET7.CAB


    Cabinet NET8.CAB


    Cabinet NET9.CAB


    Cabinet NET10.CAB


    -- More --^C
    C:\TECHDISK>extract d:\win98\base5.cab oakcdrom.sys
    Microsoft (R) Cabinet Extraction Tool - Version (16) 1.00.603.0 (08/14/97)
    Copyright (c) Microsoft Corp 1994-1997. All rights reserved.

    Cabinet base5.cab

    Extracting oakcdrom.sys

    C:\TECHDISK>_

    Now all the files that are needed on the technician's diskette are in the TECHDISK directory. The answer file for the FORMAT command was already created in the Automatic Format batch file above. The batch file that will create the technician's diskette can be now created in EDIT:

       File    Edit    Search    Options    Help    
      Untitled  
    @echo off
    rem Creates a technician's boot diskette
    echo Formatting the Floppy...
    format a: /q /u /s < c:\windows\command\fmt.ans > nul
    echo Copying Files...
    copy c:\techdisk\*.* a: > nul
    echo Creating CONFIG.SYS and AUTOEXEC.BAT...
    echo device=himem.sys /v > a:\config.sys
    echo device=oakcdrom.sys /d:cd01 >> a:\config.sys
    echo dos=high,umb >> a:\config.sys
    echo stacks=9,256 >> a:\config.sys
    echo mscdex.exe /d:cd01 /L:Q > a:\autoexec.bat
    echo smartdrv.exe >> a:\autoexec.bat
    echo Complete.

    Save the file as techdisk.bat in the WINDOWS\COMMAND folder. Exit EDIT and execute the batch file. Be sure to put a floppy diskette in the drive before you run it:

    C:\WINDOWS\COMMAND>techdisk
    Formatting Floppy...
    Copying Files...
    Creating CONFIG.SYS and AUTOEXEC.BAT...
    Complete.
    C:\WINDOWS\COMMAND>_

    Now check the contents of the diskette and if it looks good, reboot to it. If all of the files were in the C:\TECHDISK folder and the FMT.ANS file and the batch file were all error free then the diskette should work.

  •  MBR Utility

    This is a huge batch file project that will be developed in sections. The first section which will be used to demonstrate the core concepts is a small section of the overall project that can display the contents of the MBR to screen.

    Check out the DEBUG Home page to see how to read the MBR with DEBUG. Record each actual line of commands that have to be made to accomplish this within DEBUG on paper. Once this is done record these into a text file:

    a 300
mov ax,201
mov bx,100
mov cx,1
mov dx,80
int 13
int 3
(hit [Enter] and leave a blank line here!)
g=300
d 100 1ff
q

    Normally one would put in the d 200 2ff command to see the bottom half but this would scroll the top half off of the screen so the automated script must end here and then run again to display the bottom half of the MBR. Save this file as MBRTOP.SCR. Copy it to another file named MBRBOT.SCR. In MBRBOT.SCR change the line that reads d 100 1ff to read d 200 2ff instead and save it.

    Now a batch file can run DEBUG and redirect all of the input to DEBUG from this text file having the effect that DEBUG will create the small assembly language program and then run it and then display the top of the MBR to screen and then quit back to the prompt. Here is the batch file:

    @echo off
debug < mbrtop.scr

    Save this as SHOWMBR.BAT in the same directory where the script file MBRTOP.SCR is located. Run the batch file by typing its name at the DOS prompt and the top half of the hard drive's MBR will appear on screen.

    The output is kind of polluted by the assembly instructions and the debug registers display and so on. It would be nice if the output could be limited to only the actual lines of hexadecimal and ASCII codes that represent the top half of the MBR. It would be really nice if the batch file could determine if the INT 13 read request of the HDD succeeded and then inform the user if it failed or display the top half of the MBR if it succeeded.

    First, the output has to be searched for the test strings that indicate that the read request failed. This is indicated by the last flag in the registers display after the little program executes. If the last flag is "NC" then all went well. If the last flag is "CY" then all did not go well: an error occured. The flag in front of it is the parity flag which can be set to either PE (parity even) or PO (parity odd). This one is unpredictable in the event of an error condition so we will have to test for both strings: "PE CY" and "PO CY" both of which would be a fairly rare random occurence within the output strings on the ASCII side of the screen within an MBR. To perform this check and then filter the rest of the output it is best to redirect all of the output from the screen into an output file. Call it MBRTOP.OUT. Open SHOWMBR.BAT and make this change:

    @echo off
debug < mbrtop.scr  > mbrtop.out

    Now that the output is captured into a file it can be searched to see if the error occured and it can be filtered and then be displayed on screen. The FIND command will attempt to match a string within a text file. The /c switch tells it to display only the number of lines within the file where a match occured. So the output of "find /c "PE CY" mbrtop.out" should be simply "0" on screen and that would mean that the error condition did not occur. If the output to the screen were a "1" then the error did occur and the MBR was not read from the hard drive.

    Instead of displaying the number on screen, it can be "piped" from the output of the FIND command into the input of the CHOICE command. CHOICE accepts a single keystroke input from the user and then sets an "ERRORLEVEL" that DOS will hold onto until another command is executed that sets its output errorlevel to something other than zero. This value can be acted upon by the batch file processing command "IF ERRORLEVEL" So if we executed the CHOICE command within the batch file like this: choice /c:01 /n then a blinking cursor would appear waiting for input. If we pressed the "0" key, that would appear on screen and the next line of the batch file would execute. The errorlevel that the IF ERRORLEVEL command would find would be 1. If the second possible key of "1" were pressed instead, then the errorlevel would be 2. Armed with this information lets set up the output of the find command which is going to be either 0 or 1 to go to this choice command and redirect the output (to the screen) of it to nul so that the number (whichever comes out of find and into choice) will not be displayed:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul

    Now we can set up the "IF ERRORLEVEL" commands to detect the level set by CHOICE and jump to a section of code in the batch file to deal with each possibility:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
if errorlevel 1 goto nextchk
...

    We would fall to the location of the ellipsis (...) if the error condition is not met so we do not have to put the IF ERRORLEVEL 1 line at all and we can put the next check code right there:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
...

    If the batch file reaches this ellipsis then the read was successful and so the output can be displayed on screen. But again, we would like to filter it so that only the actual output hexadecimal and ASCII lines get displayed and the other lines creating and running the little program are suppressed. Notice that in the output lines each begins with some unpredictable four digit hex value then a colon and the offsets starting with 0100 then 0110 then 0120... So each output line must contain the string ":01" FIND can do that:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find ":01" mbrtop.out
...

    That will display exactly what we want to see and none of the other garbage. Now we still have to embed the readfail section and then end the little program we are writing here:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find ":01" mbrtop.out
goto end
:readfail
echo Error in INT 13h attempt to read the MBR
:end
del mbrtop.out

    That's it. You can see that every "goto labelname" must have a corresponding ":labelname" where it can literally go to. While we are at it we will have the batch file clean up the temporary file it creates right at the end. Save it and run it and see how things look. Notice that nasty output at the beginning coming from FIND that reads: "--------mbrtop.out" We can't have that. FIND accepts piped data and of course the pipe does not have a file name and so it won't pollute the output like this. Here's the change:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
type mbrtop.out | find ":01" 
goto end
:readfail
echo Error in INT 13h attempt to read the MBR
:end
del mbrtop.out

    Try this. The output should be very clean. Now add the second half of the MBR. This means that the "end" of the program must be changed to the middle since it must now go and run the second debug script, test it, then output it to the screen. A pause will also be needed while the user inspects the top half of the MBR and then when he decides to go on he can press a key and then have the bottom half displayed on screen and then return to the prompt. First change all mentions of end to middle and put in the pause command:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
type mbrtop.out | find ":01" 
goto middle
:readfail
echo Error in INT 13h attempt to read the MBR
:middle
pause
...
del mbrtop.out

    We will save the clean up to the end. Now put in the line to run the debug script to generate the bottom half of the MBR:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
type mbrtop.out | find ":01" 
goto middle
:readfail
echo Error in INT 13h attempt to read the MBR
:middle
pause
debug < mbrbot.scr > mbrbot.out
...
del mbrtop.out

    OK now here's where the famous program bugs come from...programmer's laziness. Should we test the INT13h read success of the MBR again? After all if it read it the first time, then it should be able to read it the second time right? We can leave the success checks of the second read attempt out. But that error message up above used to run right into the end of the program, but it does not do this anymore because we have moved the end of the program further down. It should be moved next to the end of the program again, AND we will finish up the display code too:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
type mbrtop.out | find ":01" 
goto middle
:middle
pause
debug < mbrbot.scr > mbrbot.out
type mbrbot.out | find ":02" <=you need a 2 here!
goto end
:readfail <=moved to here
echo Error in INT 13h attempt to read the MBR <=moved to here
:end
del mbrtop.out
del mbrbot.out

    Notice that by moving the readfail section there is a goto middle followed by the line :middle. We don't need to jump there, that is where the batch file will fall to anyway. Delete both lines:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
type mbrtop.out | find ":01" 
pause <=deleted unecessary jump here
debug < mbrbot.scr > mbrbot.out
type mbrbot.out | find ":02" 
goto end
:readfail 
echo Error in INT 13h attempt to read the MBR 
:end
del mbrtop.out
del mbrbot.out

    At this point the batch file is fully functional. All that is left is some nice descriptive output:

    @echo off
debug < mbrtop.scr > mbrtop.out
find /c "PE CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
find /c "PO CY" mbrtop.out | choice /c:01 /n > nul
if errorlevel 2 goto readfail
echo Top Half of the MBR:
type mbrtop.out | find ":01" 
pause 
debug < mbrbot.scr > mbrbot.out
echo Bottom Half of the MBR:
type mbrbot.out | find ":02" 
goto end
:readfail 
echo Error in INT 13h attempt to read the MBR 
:end
ctty nul
del mbrtop.out
del mbrbot.out
ctty con

    The CTTY NUL command switches the system console to the NUL device which means that the PC will no longer accept any input from the keyboard (although {Ctrl]+[Alt]+[Del] will still work) and no output will reach the screen. This is an old DOS batch file master's trick for arresting all possible output to the screen. You see although it is difficult for you to test the batch file on a system that will fail to read the MBR, I do have such a problem child HDD. And when that happens the program jumps to display the error message and never creates the *.OUT files. Then the DEL commands complain with "File not found" errors. Very ugly but they don't hurt anything so the CTTY NUL and CTTY CON (which returns control to the keyboard which I think you would appreciate) effectively sweep these messy error messages right under the rug.

    If all went well, you have a batch file with two scripts that requires DEBUG.EXE, FIND.EXE and CHOICE.COM. Copy these to a bootable diskette and you have an a nice MBR viewer. It creates temporary files so it cannot be write protected. An issue that will be dealt with in the Technician's Tips and Tricks page.

  •  MBR Utility Phase 2

    Being able to display the MBR is nice, but nothing to write home about. Now we will introduce a menu and some nice formatted output to the screen. The menu choices will be: Display MBR, Backup MBR, Restore MBR, Delete MBR. This will now be a fully functional and versatile MBR utility, and all with batch files and DEBUG scripts.

    Pending...

Batch File Specific Commands, Syntax, and More
Back to Page Top

Copyright©2000-2004 Brian Robinson ALL RIGHTS RESERVED