Fun with Compilers
I believe in my last post I claimed I would be working to create a simple window within GEM. Things did not go quite so smoothly, however. My first attempt involved transcribing a sample clock program on my Atari, but removing most of the “clock” portions for simplicity. My second attempt, as I will explain, involved simply compiling a GEM sample program as-is under DOS. I found most of my problems were related to the tools I was using.
Starting with the Atari example, I transcribed the code for a clock desk accessory, stripping out some of the complicated bits to leave me with a simple window. GEM is driven via an event-based loop, much like Microsoft Windows programs. On the face, the GEM model seems to be substantially more powerful than the Microsoft framework, but I’m starting to see the severe weaknesses in the GEM model. First, dialogs are a nightmare under GEM. While both GEM and Windows have to contain manual redraw code for windows, GEM requires this for dialogs as well Furthermore, GEM has a nasty issue where the mouse must be disabled by the program during redraw (what’s that about?) or an actual cursor might be left behind as the mouse moves away after the redraw. Second, GEM has a rather complicated redraw system involving passing “dirty” rectangles to any window involved in a redraw. The program itself is responsible for attempting to draw only within the rectangles. Third, GEM has very few builtin controls. Basically GEM supports some text boxes and buttons, which can be morphed into check boxes and radio buttons. The lack of controls is quite nasty, and dealing with them in a dialog is a bit of a nightmare, involving checking the memory where the dialog lives for values rather than function calls.
One great thing about GEM is that all dialogs are designed using the Resource Construction Set, or RCS. RCS actually differs considerably between Atari and PC platforms, and, again, multiple 3rd party alternatives are available on the Atari (Interface, Resource Master, etc.). A screenshot of Digital Research’s RCS on the PC appears below:
While being able (almost required, actually) to graphically design dialogs is a big plus, one can see from the screenshots that there are a severe lack of options available for dialog controls.
Now I’ll move on to compilers. I wrote a simple application on the Atari using some sample code and attempted to compile the package with AHCC, a relatively new compiler suite based on Sozobon/X C. I received piles of errors from the compiler, most focussing on some globals that had been declared as WORDs. Some searching of header files revealed that AHCC did not seem to be defining a WORD in the header files. I defined WORD as an unsigned int and moved on. However, now I was receiving cryptic errors involving some functions that were declared as returning BOOLEAN values. I normally avoid anything resembling booleans in C because their implementation seems quite inconsistent. In this case the example I was basing my program on used them, so I did as well. At this point I was quite frustrated, so I moved on to Pure C.
The Pure C compiler was the standard for years on the Atari, only recently being phased out by most surviving projects in favor of GCC. Pure C is an odd package, in my opinion. It is clearly based on Turbo C, as you can often find Borland copyrights sprinkled in the headers. The system also provides BGI headers, which, I believe, is the ol’ Borland graphics interface. It seems to have been developed at least partially by Gribnif Software, an old Atari company, but was marketed by ASH, another company. Because the Pure C package is based on Turbo C, the GEM headers are much closer to Turbo C GEM bindings on the PC.
Anyway, I attempted to compile my program again using Pure C and was met with more problems on the declarations using BOOLEAN return values. At this point I was convinced that the issue is the use of booleans and changed everything to integer return values, as I usually do in my programming. Suddenly the program compiled and linked successfully! I first needed to change the extension of the resulting .prg file (GEM apps on Ataris have .app or .prg extensions) to .acc to mark it as a desk accessory. Because I’m running MiNT, I can double click desk accessories to start them rather than require a reboot with the .acc file on the boot drive. Success! Well, sort of… A window of basically zero width and zero height was created, although some of the window decorations were drawn. This horrible example proves that I’m at least to the point of being able to compile GEM programs on the Atari.
Next came the task of compiling this program on the PC. Things became ugly very quickly. There is a severe lack of C bindings for GEM on the PC. My personal theory is that its a product of a closed environment from years previous. In other words, since GEM and its programmer’s toolkit cost money, they were not generally available. Microsoft’s nearly completely open (at this point, at least) availability of development tools is and was probably a major contributor to its popularity. A GEM SDK is “available” from Shaneland, but the archive contains bindings for DJGPP and Pacific C, neither of which I’m keen on using. For DOS development, I always prefer OpenWatcom, but I’ll deal with Turbo C as well (see my earlier challenges…).
I finally ran across a forum post that had links to the original GEM Programmer’s Toolkit from DRI, which contains language bindings for Turbo C, Microsoft C, and High C. However, more fun came along with this kit. The toolkit contains a GEM installer application that apparently assumes everything is on A: with no exceptions. I finally realized that I could force DosBox to use a directory as A: as well. I started GEM and selected Turbo C as my desired language.
The next step wasn’t quite so obvious. I next needed to compile the libraries using Turbo C itself. A handy batch file was provided, MAKELIB.BAT, that did produce a lib, but the lib contained nothing. Looking at the documentation, I needed to make a special makefile “include” called BUILTINS.MAK which contained directions for actually compiling. After creating the proper file and copying the file into every binding directory (AES, VDI, EMS for memory, XFM for file access, DOS for DOS interfacing, and MISC), the library successfully built.
Finally I compiled a simple hello world application. Much to my surprise, it worked:
My next step is to fix up the code I personally wrote to get a non-zero sized window, and attempt to compile it on both the Atari and the PC.
