Design Ideas: April 27, 1995

If you use a PC to develop software for embedded systems, you probably still use good, old MS-DOS for most of your processing, because most compilers, assemblers, and linkers don't run under MS Windows.

If you're developing a sizable program, you probably use automated procedures such as batch files or "make" files to build and rebuild your target program. When you use batch files or make files, capturing the PC's screen output in a disk file is more convenient than sitting around, watching everything endlessly scroll by on the screen.

You can capture screen output by using the MS-DOS redirection feature, causing all MS-DOS console output to go to the disk file you specify.

However, DOS actually has two types of console output, known in DOS lingo as stdout and stderr. When you ask DOS to redirect screen output to a disk file, it only changes the destination of stdout's output.

The problem is that programs such as assemblers and compilers can send messages to the screen via either stdout or stderr. In general, programs should use stdout for ordinary output, such as status messages and nonfatal error messages, and stderr for catastrophic error messages such as disk failure, memory corrupted, etc. These distinctions make sense because, if the program detects a catastrophic failure, you probably want immediate notification on screen.

Unfortunately, not all programs follow this convention. Some programs send "good" messages to stdout and "bad" (though nonfatal) error messages to stderr (I guess that's what they thought stderr was for).

For example, I use a particular 68HC11 cross-assembler that sends the startup banner and termination message to stdout but sends all assembly-language syntax-error messages to stderr. Only the start and finish messages are captured in the disk file while the assembly error messages scroll off the top of the screen. So when I use MS-DOS redirection to capture the output in a disk file, all assemblies look as though they worked fine, with no errors[!].

To get around this problem, the simple "terminate and stay resident" program (TSR) in Listing 1 (which is also posted as EDN BBS /DI_SIG #1681), called STDERROR.ASM, sends all stderr output to stdout. If you don't use DOS redirection to capture screen output in a disk file, the STDERROR TSR has no apparent effect. However, if you use DOS redirection to capture screen output in a file, STDERROR causes stderr output to also go to the file. (DI #1683)