User Reports

An Easy Road to Windows?

Steven K. Graham

Steven K. Graham has worked for Hewlett-Packard, served on the Faculty at UMKC, and is currently a Senior Engineer with CSI.

WinDosIO 2.0, from Graubert-Cervone Software (and one of this month's C Users' Group volumes), provides a shareware dynamic link library (DLL) that hides many of the details of manipulating Microsoft Windows behind a familiar mask. When properly compiled and linked, some C programs can be transferred from MS-DOS to Windows without changing a single line of code. WinDosIO version 2.0 provides over 200 functions for standard terminal-style I/O and Borland/Microsoft graphics under Microsoft Windows 3.0 and 3.1, along with an online user manual, a reference guide, and several example programs. WindosIO must be used with a compiler that includes the Windows Software Development Toolkit. The simpler coding and the possibility of easy ports from MS-DOS to Windows make WinDosIO appealing, particularly since the full Windows API is always available.

An Overview of Functionality

WinDosIO's strength is the large number of functions it supports. Not once did I encounter a function that I had used in a test program that wasn't supported by WinDosIO. Functions provide access to colors, pixels, coordinates, graphics figures, fonts, and text. The few functions listed later, from the first few pages of the reference manual, may give the flavor of the extent of operations provided.

Conditions

The author, Jeff Graubert-Cervone, provides WinDosIO as "FreeWare" and states that "Everything on this disk can be given away for free." However, applications that use the WinDosIO DLL include a shareware message presented in an initial window. The message indicates that programs using WinDosIO can be distributed free, but may not be sold unless the developer has obtained a key generator and password from Graubert-Cervone Software (which will allow them to remove the message). Developers can obtain a key generator, password, update notices, and support for $69 from Graubert-Cervone Software, 5801 N. Sheridan Road, Suite #20B, Chicago, IL 60660-3811; CIS: [70761,2707]; Prodigy: WPJX24A.

WinDosIO Files and Installation

WinDosIO v2.0 contains the following files:

Despite the 70 or so pages of documentation in the online user guide and reference manual, there are some crucial omissions. First, there are no installation instructions. Working with Borland's C+ + 3.0, and Windows 3.1, I began by creating a C:\windosio directory and copying all the files into it. However, I found a number of additional steps are necessary that are not documented. The testdos makefile expects the example programs to be used with two subdirectories, src and obj, for the source and object files, respectively. The include file windosio.h needs to be somewhere the compiler can find it (perhaps simplest is copying it to the include directory), and the DLL has to be somewhere Windows can find it, such as the \WINDOWS\SYSTEM subdirectory. Additionally, the online documentation provides no information regarding necessary compilation and linking options. Information for the subdirectories and compilation and linking has to be extracted from the makefile. See the following section on the "Hello, World" program for options used for the examples.

To use WinDosIO, simply add the include file, WinDosIO.h, to your program. You may need to remove some existing include files, in particular: stdio.h, conio.h, graphics.h (graph.h). All functions in the DLL are far and all pointers must also be far, compiling with the large memory model. This shouldn't be a problem, but for other memory models the prototypes in windosio.h are necessary. Jeff Graubert-Cervone, the author, warns that "This only leaves the problem of arguments that cannot be prototyped such as the second and subsequent arguments in printf and scanf. MAKE SURE YOU EITHER DECLARE ANY POINTERS USED AS FAR OR CAST THEM AS FAR. There is no way the compiler can warn you about this problem." Another suggestion from Mr. Graubert-Cervone was that the large model should be used for development, followed by a switch to a more efficient model (if needed) later in the cycle.

A Familiar Example

A familiar example, the "Hello, World" program is included with WinDosIO, as exampl2.c. The code contrasts markedly with other versions for Windows. (The whello.cpp example Borland includes with their compiler runs 273 lines.) The program statements were

#include <WinDosIO.h>

main()
{
   printf("Hello, Windows\n");
   getch();
   return 0;
}
After some initial difficulties with the makefile, this program ran fine under Windows, creating a termI0 window, writing the string, and then waiting for a keystroke. The window could be moved, maximized, minimized, resized, and closed. To test the claim that MS-DOS programs could run without change, I removed the line

   #include <WinDosIO.h>
and replaced it with

   #include <stdio.h>
After the change, the program ran under both MS-DOS and Windows, depending on the compiler and link options selected. The options used for Windows were

 bcc -ml -Ihdr -nobj/ -c -w -y -v src/exampl2.c
and

 tlink /Tw /c /C /v /l @exampl2.mln
where exampl2.mln contained:

 c0wM obj\windosio.obj obj\exampl2.obj
 exampl2.exe,exampl2.map
 windosio cwM cM import
 exampl2.def
and exampl2.def contained:

 NAME  Example2
 DESCRIPTION  'Hello, World'
 EXETYPE  WINDOWS
 CODE  PRELOAD MOVEABLE DISCARDABLE
 DATA  PRELOAD MOVEABLE
 HEAPSIZE  2048
 STACKSIZE  16000
When stdio.h was included rather than WinDosIO.h, it was necessary to compile the program under the large memory model for it to work under Windows. The printf function is supplied by the WinDosIO DLL, and is always far (a four-byte address). WinDosIO.h includes appropriate prototypes, while stdio.h does not.

Some Additional Testing

Printing "Hello, World" doesn't constitute much of a test. The example files provided with WinDosIO ran, not surprisingly. But there was a quirk or two. When maximizing a termIO window, the black background remained at its original size, with a band of white background surrounding it. When I moved a simple example from a color monitor running Windows 3.1 to a monochrome VGA monitor with Windows 3.0 (without recompiling) one of the buttons disappeared, but otherwise the program continued to work.

In programs designed for MS-DOS, it isn't unusual for there to be command-line arguments (argc and argv). There is a provision built in to windosio.c to transfer such arguments to your main routine. Unfortunately, none of the example programs illustrated such a use — but virtually every MS_DOS program of mine that I looked at was using such arguments. When I tried to compile and link as did the example files, the following errors resulted:

Error: Undefined symbol __COargc in library file
cm.lib in module SETARGV

Error: Undefined symbol __COargv in library file
cm.lib in module SETARGV
I took a closer look at the libraries included in the response file (e.g., exampl1.mln), both cwm.lib and cm.lib were specified. cwm.lib is the runtime libary for executables under Windows, while cm.lib is the runtime library for MS-DOS. (Both are for the medium memory model.) While including both libraries worked with the examples, with my test program (which used argc and argv), I was unable to link without errors until I removed the cm.lib library.

For an additional test, I took a small graphics program, to see if it would run with minimal changes. I had to remove the include files as described above, and add the windosio.h file. After removing the other include files, but before adding windosio.h, I compiled the file — resulting in 21 errors from undefined functions. On compiling with windosio.h added, there was a single error — I'd declared main as type void, while WinDosIO prototypes it as type int. After changing that line of my program (and adding a return 0; statement to avoid a warning) the program compiled without errors. While linking, I again had to remove the cm.lib, and also add a mathm.lib. With these changes the program compiled, linked, and ran — almost. The MS-DOS version drew various colored lines, but WinDosIO produced only black and white, and using XOR to erase existing lines didn't seem to work in Windows.

Conclusions

There is one clear shortcoming to WinDosIO v2.0; the user documentation is inadequate. The file that should address use of the system largely consists of listings of the example programs along with limited discussion. The poor user documentation is exacerbated by the fact that potential WinDosIO users may be looking for an "easy" route to Windows programming — going from MS-DOS to Windows without changing their programs. The reference manual is better, with its alphabetical listing of functions, but it is long enough that an index or table of contents would be handy — and I'd almost prefer a topical organization of the functions to the alphabetical listing. With appropriate compilation and link commands, WinDosIO appears to produce working programs, but, as in the case of the graphics program above, I expect that it will seldom be a case of re-compile, re-link, and run. WinDosIO provides a programming interface. WinDosIO is much closer to MS-DOS than to Windows, but it will be best exploited by programmers who are willing to learn its details.

I'm less confident than when I began looking at WinDosIO that it makes a good intermediate step between Windows and MS-DOS programming. The potential is definitely there, and with the large library of functions, a great deal of effort has gone into functionality. With some corresponding effort on documentation, or even with just the accumulation of Frequently Asked Questions (FAQ) and responses into a file to accompany the package, WinDosIO could be a worthwhile tool for those who take the time to learn its use.