The Command Prompt

Console applications, then, are just programs with access to the three basic data streams. Windows makes the data streams available to you through the console window. So far, this is probably more nostalgic than useful, but Windows comes with a special console application called cmd.exe that allows you to do some more interesting things with the three standard data streams. For example, open a command prompt and type the following ("C:\>" of course represents the actual command prompt and should not be typed into the box):

C:\> at.exe /?

You should see some reference information for the at.exe program. Now type the following:

C:\> at.exe /? >atref.txt

Although nothing appears on the screen, the atref.txt file now contains the reference information for the at.exe program. Cmd.exe provides the special > (greater-than) operator for sending standard output to a file. The important point is that the > operator is not part of the operating system, but part of cmd.exe. If you need proof, try typing the same command line into the Run box of your Windows Start menu (thus bypassing cmd.exe altogether). You will see the Windows console briefly appear, but atref.txt is nowhere to be found.

Cmd.exe isn't a magical window on the guts of the operating system—it is just a particularly useful console application that allows you to do some convenient (and powerful) things with the standard data streams of other console applications. This becomes very interesting when you consider that standard input and output are really compatible ideas and that standard output from one program can serve as standard input to another, and so on and on. This idea is nearly as old as the idea of standard data streams themselves and dates back to a version of Unix that first appeared in 1972. The mechanism for linking together console applications in such a way is called the "pipe." Its command-line representation (on Windows and Unix) is the vertical bar character (|). Since its inception, the pipe has had a profound influence on Unix software, which is famous for being comprised of many simple, single-purpose, "pipeable" programs.

Cmd.exe supports pipes too. For example, the following command line sends the reference information for the at.exe program to a program called findstr.exe:

C:\> at.exe /? | findstr.exe "\/delete"

Findstr.exe is a pattern-matching text searcher that comes with Windows. In this case, you are telling it to output only the lines with the word "/delete" in them. The findstr.exe program is highly specific in its purpose. So are most of the basic Windows commands, for that matter. The pipe allows you to string them together to form complex commands. If cmd.exe didn't allow use of the pipe, you would end up with a proliferation of console applications that differed only in some small detail, such as the ability to sort or filter their output. Or, you would end up with prohibitively complex commands with lengthy and confusing command-line switches. Without the pipe, the command I just showed might have been written like so:

C:\> at.exe /? /filter:\/delete /write:atref.txt

This would require the developer of at.exe to understand string pattern matching and file writing in addition to what the at.exe program actually does.

The world of console applications is like an ecosystem, in which programs forge symbiotic relationships and thus become useful. This is especially true on Unix, where that ecosystem has existed much longer. Some of the most useful programs on Unix ("sort," for example) are utterly useless on their own. For some reason, interoperability via the pipe and standard I/O is a relative rarity in the world of Windows. This might be because Windows has historically been more graphically oriented than Unix, or perhaps it is because Visual Basic® (through version 6.0) didn't make it easy to write console applications. Regardless, the .NET Framework takes a great leap forward by looking back. It is easier than ever to write applications that take advantage of standard I/O and the pipe. The rest of this article looks at two sides of console applications—first, how to build them using the .NET Framework, and second, how to interoperate with them from the .NET Framework.