Character-Mode Sentenced to Execution


CExecutive also knows a lot about how to handle primitive character-mode programs. There are two types of character-mode programs: MS-DOS programs and Win32 console programs. Although they often look and work the same, ­32-bit Windows does a much better job of handling its native console programs. Unfortunately, you won’t find many of them under Windows 95. Even the command processor, COMMAND.COM, is an MS-DOS program. Things are much better under Windows NT. Its command processor, CMD.EXE, is a 32-bit ­console application, and so are most of its command-line tools such as FIND, SORT, and XCOPY.


If you’re stuck with a lot of old MS-DOS programs, there’s a limit to how much Win32 can do. You’ll often get better control if you define program information files (PIFs) and execute them instead of the programs.


When dealing with command-line oriented programs such as filters and other utilities, it’s important to understand what parts of the command line are handled by the operating system and what parts by the command processor. Redirection and command-line piping are done by the command processor. It won’t do you any good to provide the redirection and piping characters on a command line that is passed directly to the CExecutive Run method or to the Shell function. You need to ask the command processor to execute your program indirectly. Furthermore, if you go through the command processor, you can give built-in commands such as Dir and Type. Since the command processor differs depending on the operating system and potentially on settings made by the user, you should always use the COMSPEC environment variable rather than a hard-coded name. For example, this Shell statement redirects the output of the Dir command to a file: 

Shell Environ$("COMSPEC") & " /c dir > dir.out"

The Run method of CExecutive has a shortcut. It recognizes and expands environment variables enclosed in percent signs:

exec.Run "%COMSPEC% /c dir > dir.out"

If you’re curious how this works, check the ExpandEnvStr function in
UTIL­ITY­.BAS. It’s a Visual Basic wrapper for the ExpandEnvironmentStrings API
function.


Many CExecutive properties have no effect on Windows-based programs, but instead control Win32 console applications. Keep in mind that they’ll have limi­ted effect on MS-DOS programs. You can specify the title, the number of rows and columns, and the color:

.Title = "The Meaning of Life"
.Left = Screen.Width / Screen.TwipsPerPixelX * 0.1
.Top = Screen.Height / Screen.TwipsPerPixelY * 0.1
' Start a red on cyan command session 70 columns by 64 rows
.Columns = 70
.Rows = 64
.BackColor = qbGreen
.ForeColor = qbLightYellow
.Run "%COMSPEC%"

The color argument puts yellow text on a hideous green background. Does that take you back or what? Some of us remember when we had only 16 colors and specified them in the high and low nibbles of a byte. Those are the 16 colors that are still supported through the QBColor function. I added constants for them in the Windows API type library. Even those of us who remember the old colors don’t remember being able to make our screens 70 columns by 64 rows. Back in those days, you could have 80 or 40 columns and 25, 43, or 50 rows—take it or leave it.


The final trick in CExecutive’s bag is piping input and output. This is different than piping input and output between programs on a command line. You can give a string as the standard input of a program and then read its standard output back into another string:

.PipedInText = sUnsortedText
.Show = vbHide
.WaitMode = ewmWaitDead
.Run "sort"
sSortedText = .PipedOutText

This technique links the oldest style of programming with the newest. You can send the output of a command like Dir directly onto a web page and leverage your old programs rather than writing procedures that do the same thing. The technique works for MS-DOS programs, Win32 console programs, and for the few Windows programs that take advantage of standard input and output handles.