Use SHELL with Legacy and StandAlone Programs

[Donald Darden]

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:

Code Select Expand


\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:

Code Select Expand


temp mydll.dll mydump.txt

The advantage is that I can depend on this to work if I put this into a BASIC program:

Code Select Expand


SHELL "temp mydll.dll mydump.txt"

Whereas if I tried this in a BASIC Program instead:

Code Select Expand


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.

[Charles Pegge]

That technique with the batch files was very useful when you only had 640K of memory to play with. I used it for document retrieval, switching between the database system and Wordperfect. There wasn't room for both, so, batch files were generated by the database, which then saved its state and terminated. the second batch file then fired up Wordperfect with the requested document. When wordperfect was terminated, the  database was reloaded and restored its previous position.

The database system was written in Turbobasic, and the task switching only took 3-4 seconds on an early 90's PC. Programs were much smaller then, so the load times were often better than today's Windows based applications.

[Eros Olmi]

I assume we (yes, I still do it too) use those techniques because we come from old DOS time where that was the way. Mainly every well written program had a "Run command ..." option in order to shell many activities.

Nowday thare are much more complex and elegant way to do all this via the many scripting possibilities present in current OS or via 3rd party engines.

Problem is for those that never saw a console screen or even imagine that there is a console screen.
I even know many IT people never used a .BAT or .CMD file. Really some of them also do not know what a .BAT or .CMD file is, imagine about piping more in/out buffers.

Thanks to those people un-knowledge there are many others making money for easy.

Anyhow, I'm happy to see posts about that. Thanks
Eros

[Donald Darden]

I suppose I should mention that the method of writing batch files is usually covered in books about MS-DOS, and that every version of Windows (not sure about Vista) supports a Command Prompt (use the Start/Run option and enter "cmd" (short for command) and the Enter key.  The black screen you are then looking at is the Command Prompt).  Another way to get to the Command Prompt is to use Start/Programs/Accessories/Command Prompt (this might be easier, since no typing is involved, just mouse clicks).

The available system utilities are also described in books about MS-DOS.  Most have not changed since MS-DOS version 6.22, and even books that date back to MS-DOS 5.0 are still good.  You can ignore anything about memory management, such as discussions on HIMEM.SYS and EMM386, since Windows now manages memory for you.  Nor do you need to pay any attention to the
discussion about device drivers and working with a RAM drive - the windows
memory model and the tools provided as part of your BASIC compiler give you
access to arrays and other methods of making better use of memory.

There is another product available called WinBatch, that claims to offer more
functionality through scripting.  Now Scripting itself is a word worth looking at,
because it really refers to the ability to write some type of command syntax
that will be interpreted and acted on by the computer.  There are all manner of
programs that offer this capability - even Word and Excel can support VBA, which is Visual BASIC for Applications.  So sometimes you have a choice of ways in which to accomplish a task, and sometimes there is really only one good way to do it.

[Eros Olmi]

A command prompt will always been present in every OS, be sure. Vista 32 bit is also able to still execute 16 bit DOS application.

Regarding WinBatch, maybe it started as an evolution of batch programming (.BAT) at first but now it is like the many script engine you can find around, nothing special. thinBasic is another example but you can get Euphoria, FBSL, just for listing few I follow.

Maybe woth to have a look at Microsoft pages talking about the many possibilities about OS scripting:
http://msdn2.microsoft.com/en-us/library/ms950396.aspx
http://www.microsoft.com/technet/scriptcenter/default.mspx

also a scripting game area:
http://www.microsoft.com/technet/scriptcenter/funzone/games/default.mspx

Eros

[José Roca]

 
Hi, scripting guys!

I have opened a new board for scripting where I will post wrappers and examples for the various Microsoft scripting technologies. I will eventually also add wrappers and examples for the LogParser when I will find the time to explore it with detail. Regarding the Active Directory, I could write wrappers to use it, but not having access to a network I could not test them.

I have done a successful test to implement the Active Script interface, that allows to host the script engine and expose your objects, making your application scriptable. This allows to run an script that, in turn, can call the methods and properties of the objects implemented in your application. The only problem is that without having native support for classes you have to implement the objects using low-level techniques. Therefore, for the moment, I just will post an example or two to show how it can be done.

I don't have any expertise with other script engines, like LUA, that can be used with PB. If I learn something about them or a member of this forum has expertise with them and is willing to share his knowledge, new forums can be added.

Although my main interest is to use scripting technologies with PB applications, I have nothing against other solutions, like standalone scripts. Just make your suggestions for new forums.