A Diary of a Programmer's Vacation in Florida

From EDM2
Jump to: navigation, search

by Randell S. Flint

Correction: The statement "... __MULTI__ must be defined so that the correct parts of the header files are visible" is not true for the OS/2 for the PowerPC SDK (Beta) shipped on The Developer Connection for OS/2. Instead, you use the option "-Hthread" to specify multithreading.

Relish, Sundial System's award-winning time and information manager, has always lead the way in exploiting the features OS/2 has to offer. So when we were invited to be one of the first applications to run on OS/2 for the Power PC, we jumped at the chance.

Day 1 - Getting set up

Between touring the IBM site, getting my badge, understanding the hardware setup, and finding out the current state of OS/2 for the Power PC (no Workplace Shell yet!), Day 1 was pretty much lost.

Day 2 - Coming up with a build strategy

The first issue was how to "recompile" the PowerPC version of Relish using several hundred source files spread across a tree of different directories with the MetaWare compiler, linker, and so forth. I decided to start with something small, but non-trivial - a Relish library containing some thread procedures. Since we were blazing new ground, updating the makefile and getting the compiler environment set up took time.

The first compile generated a bizarre set of errors (concerning illegal global variable initialization), a torrent of warnings (including failed trigraph substitutions even though there are no trigraphs), and an error on the first opening brace! It seemed I was in deep trouble!

Most of the problems traced to something innocent: a space between a backslash and a new line on the continuation of a macro definition in a header file. C Set++ ignores the space; MetaWare doesn't! The warnings about trigraphs were another story - try putting (???) in a comment, and see what happens.

Day 3 - Getting clean compiles and links

Each of the ISVs at IBM went through a different process to determine the correct makefile options - and each had different answers! Day 3 was spent resolving these inconsistencies.

For instance, when compiling multithreaded code, __MULTI__ must be defined so that the correct parts of the header files are visible. Likewise, several other compiler and linker switches are necessary.

Also, the MetaWare linker examines each library you link with only once. So, unless you carefully order the libraries, you can end up with (bogus) unresolved externals. And if two libraries reference each other, creative solutions are required.

Day 4 - The first program runs to completion

By Friday, all I wanted to do was get something running. Most of the code was compiled, but no executables were built yet.

Ordinarily, Relish runs as four distinct processes. Three work in the background doing things like database management. Only one appears on the desktop, but it relies on the others.

There were known to be problems in the APIs for starting processes. I decided to concentrate on getting one stand-alone program, NOWBUILD, to do its thing. It just builds an empty database and exits.

It took some digging to find out how to build the object module libraries correctly. Unlike C Set++, the filenames in the library are case sensitive, and it's not an error to have multiple definitions of a symbol. At link time, the first definition is used. I also had to creatively resolve some linkage order problems.

Then it was on to the PowerPC. I copied NOWBUILD onto the disk, modified the OS/2 startup sequence, and booted.

What I saw wasn't very much... but it was significant. OS/2 booted, my program ran, and the system shut itself down. I never saw anything on the screen other than an empty desktop. (OS/2 was running without the Workplace Shell and NOWBUILD had no user interface.) Using the serial-monitoring link, I could tell NOWBUILD had started and hadn't trapped.

I checked what NOWBUILD had done. Unfortunately, our log files pointed to an error - the Relish header files weren't being compiled correctly because we hadn't identified the MetaWare compiler as 32-bit. With that fixed, I tried it again, and this time it worked! There was an empty Relish database!

Day 5 - A window on the screen!

Saturday, November 5th, 12:51 p.m. I had just gotten a complete build of the Relish foreground process and decided to try it.

I rebooted the PowerPC. Up came the empty desktop... then the Relish window frame... the note palette... the calendar (with the wrong month in it). And then, after a pause, the iconbar, and a message box about not being able to find the help information. I was stunned (and I let everyone around know it)! There it was - Relish, the first application ever up and running on OS/2 for the Power PC.

As soon as you OK'ed the message box, however, up came another one that said the Relish background processes weren't running and couldn't be started. (In fact, they weren't even on the PowerPC yet.)

I wasn't ready to try to get multiple processes running yet. I made some quick modifications, so it could continue without the background processes.

After loading that build, I was amazed how much was working!

Day 6 - Sunday - A day of rest (not really)

As noted on Saturday, the calendar wasn't displaying November 1994. The problem was that OS/2 wasn't getting the date from the hardware correctly. But once I used Relish to set the system date and time, the calendar displayed correctly.

But then the current time still wasn't being updated. There was a problem in the thread that handles the update due to a (known) problem with the timeout parameter of DosWaitEventSem. So, a couple of lines of code were added to (temporarily) replace the call.

Another problem was that the 8 a.m. to 5 p.m. timebar wasn't being displayed in the various dialogs. It turned out that in making the quick-and-dirty changes on Saturday, I had forgotten to initialize one of the key Relish data structures.

Day 7 - Getting multiple processes running

While it's too complicated to explain here, starting any Relish process triggers a series of events that gets the four standard Relish processes running. The APIs involved are DosExecPgm and DosStartSession. Both of these had been problematic in various builds of the system.

Thus, I modified our start-up routine to not try to bring up the last background process. I also had to hardcode the directory where the files were, since the method we ordinarily use wasn't working.

With those changes, and an empty Relish database generated by NOWBUILD, all three processes were up and communicating.

So, in about a week, we moved well over 200,000 lines of code to a new hardware platform, changing only 12 lines:

  • 2 lines in macro definitions to avoid a compiler error
  • 1 line in a header file to detect the compiler correctly
  • 2 lines to force use of DosExecPgm, rather than DosStartSession
  • 2 lines to prevent trying to start the last background process
  • 3 lines to avoid a timeout parameter bug in DosWaitEventSem
  • 2 lines to hardcode the directory where the files were

Day 8 - The demo to the team

On the Tuesday before Comdex, I went to the daily status meeting of the OS/2 for the PowerPC team. There we showed, side-by-side, Relish running on Intel and Relish running on the Power PC - and, except for some window painting problems (fixed by the team later that day), the two products looked and felt exactly the same!

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation