An Operating System usually comes with a number of untilities, and the ability to script files that can be executed as a command. In DOS, we have internal and external commands (actually, a form of utility), and out ability to create script files that contain text and are named with the extention .BAT. Pretty much anything you can type in as a single line commmand under DOS can be created and used in a BAT (short for BATCH) file.
DOS incorporates three special device names called STDIN, STDOUT, and STDERR.
By default, STDIN is associated with the keyboard, and STDOUT and STDERR are associated with the CONSOLE Screen. Thus, what you type is treated as standard input, and what is sent to the standard output goes to the screen, as does any errors that are reported. Now the pipe symbol, or vertical bar "|" is designated to take the standard output from one command and use it as standard input for the next command, such as print list.txt | sort.
The print command will print out the contents of the list.txt file, but the pipe symbol will cause DOS to create a temporary file and redirect the standard output to it instead of the screen. Then the piple symbol will cause DOS to cause the temporary file to act as standard input to the next command, which is SORT. SORT will then sort the file and send it to the standard output, which would be the console. So you seen the sorted output on the screen, but it only effected the temporary file, and list.txt is still as it was.
Then you have three redirect symbols, <, >, and >>. The < would take the output of the second command and pass it back as input to the first (left command), but this is rarely used, since it is easier to work the command sequence from left to right. The > takes the output of the left command and redirects it to the input of the next command, or to a device, or file. This
fexibility makes > more commonly used than the pipe (|). The double greater than symbol acts to append the output to any previous content, and is most often used when the target is a file, because the single greater than symbol would overwrite any file that had the same name.
When you call programs, you often have to pass parameters or switches to them. Batch files might need their own parameters, and these are numbered 1 to 9, but with a preceeding "%" (percent sign) that identifies them as a reference to the order of passed arguments. Thus I could write a general purpose BAT file that did something like this:
\masm32\bin\dumppe %1 > %2
Let's call this BAT file Temp.bat. Now dumppe is a free PE (Portable Executable)
file format analyzer that comes with the free MASM32 distribution, and works on DLL (Dynamic Linked Libraries), and particularly useful for identifying the Export, which is the number of functions and what their external names are, and sometimes (depending upon the format), the number of bytes required on the stack by all the calling arguments. But it only sends its output to the console when you try to SHELL to it from within another language, such as FreeBasic or PowerBasic (a limitation of Windows). To get around this, this simple batch file will stand in for us when we actually want to call dumppe, and we will let it do its redirect to the second parameter, which we will supply as a file name.
So here is an example of using our BAT file to analyze a dll:
temp mydll.dll mydump.txt
The advantage is that I can depend on this to work if I put this into a BASIC program:
SHELL "temp mydll.dll mydump.txt"
Whereas if I tried this in a BASIC Program instead:
SHELL "i:\masm32\bas\dumppe mydll.dll > mydump.txt"
The results could be problematic.
SHELL and BAT files can work around many issues involving legacy and standalone problems. Being able to SHELL to an outside program sometimes works, but cases occur where it presents problems. Being able to shell instead to a BAT file that calls the program in question sometimes can be made to work better. But there are times when even that won't work, and your solution might be to create a BAT file that first calls the needed program, then calls another process that you want perform, which might be some of your own code.
Here is a somewhat elaborate way that this last method can be made to work,
You have to think about pre-call, call, and post-call activities that involve the program in question. And you can either use environmental variables or the presence or absences of key BAT files to judge which state you are currently in when actually performing the whole operation.
The tricky part, at least mentally, is then to conceive of writing each of those
BAT files from whithin your own BASIC program, then calling them via the SHELL statement with the necessary arguments passed in the SHELL's CmdString or as set up in environmental variables. After creating the BAT files and SHELLing to them, the BAT files can even write, detect, or delete other BAT or incidental files. Then after the SHELL is done, you can KILL the BAT files, and there is no
evidence that you had to resort to such a crude method to get the job done, because it is all masked as part of your own BASIC coding.
And then there is the really rough case where trying even this approach will not work, because our efforts to SHELL are not supported, possibly because of memory restraints. So what you then have to think about is calling your program initially via a BAT file, and that bat file makes sure a secondary BAT file,
call it Stage2.BAT, is erased. Because the BAT file used CALL when it called your program, when you exit, you return to the BAT file, You can return an error code if you like, which can be checked with ERROROLEVEL in the BAT jargon.
The BAT file can then do a CALL to the problematic program next. then it checks for Stage2.BAT, and if it exists, it calls it next.
But wait! Didn't we just delete State2.bat? Yes we did. So how can it exist at this point? It can only exist if your called program created it, assuming that the problematic program did not do it. So what is Stage2.BAT? It's whatever you want it to be. It is the next stage, or the next program, that you want to have run when the problematic program got finished. Thus, by beginning life as part of a BAT file, you can create a series of steps or stages to bind several programs together into a sequence of actions that simply will not come together otherwise.
