Flangy > Software Development > DOS GUI

DOS GUI

Many years ago I wrote part of a mode 13, real-mode DOS GUI and Application Framework in C++. It was influenced heavily by my use of and the documentation to Borland's TurboVision framework (PASCAL version.) The code is my own (though at a later job I found out that Borland started shipping the full C++ source to TurboVision with it's compiler, since it decided to stop doing in-house development on it. I actually fixed a couple of glaring bugs in it for work.)

The code includes key & mouse event handling, simple polled timers (used to detect double-clicks), a bunch of GUI widgets: buttons, input lines, (non-moveable) dialog boxes, grid areas.

I was particularly happy about the grid area and derived classes, as they are really useful for writing game tools. There are built-in classes for palette selectors and painting, and you can use a regular grid area to show tiles or whatever.

View the source to the font editor.

Compiling

Surprisingly most of this code still compiles with Borland C++ 2.0, which runs fine in a terminal under Windows 2000. However, since the code was developed two machines ago, I don't have the environment set up to actually get my apps to link. Fortunately I saved the .EXEs, and they all more-or-less run.

If you have some version of Borland's DOS C++ installed, you can compile most of the library with a "make", but some stuff still fails.

Downloads

• Dos GUI Source: C++ sources to most of the library. There are probably some missing support files; I had some code in separate directories used across several folders. If there is actually any interest I can try to dig up some more source.
  
• Apps: Includes a program to let me create bitmap fonts for use with the framework. They should be run from the command line. If you double-click them from Explorer the working directory probably won't be set correctly. Read more.

Notes

If I was going to implement something like this today I really wouldn't want to use #define + switch/case style event handling. An MFC style message map for event handling might be a bit better.

It turns out that I really don't care for writing UI code in C++; I think it's a lot easier in languages that have more dynamic message passing, like Python or Objective-C. It's a lot easier to hook up event handlers through generic sockets vs. having to do static function calls.

Also, I listened to a lot of Led Zeppelin while working on this thing.