Little Helpers

by Eric Slaats

Last month I had some technical difficulties getting my article to OS/2 e-Zine! so I decided to write an extra column for this issue. Another programming article seemed like a little too much, so I decided to take a look at a number of small programs I use in my daily OS/2 programming practices.

All of these programs are free and in most cases developed for internal IBM use. The only problem I had was tracing were I originally found them! This proved to be a large problem. I have the tendency not to update programs to newer versions when I have a version that already works. So some of these programs date from 1992! (That's a very antique program in our business.)

While searching, I found that most of the helper programs I use came from the IBM Developer Connection CD (DevCon) package. I had a subscription to this package for some time. (By the way, it's a very worthwhile investment to buy at least one of these DevCon packages, although I don't know if it's possible to purchase just one set.) The DevCon CD is packed with little programs like the ones I will discuss here. But that's not its main content; it always contains the latest OS/2 developers' toolkit. This contains the latest header (.h) files as well as all the up-to-date API information for the various OS/2 versions. It also contains demo versions for many commercial developers' tools and products.

Well, time to get off the soapbox, simply give it a try.

Now for the little helpers I picked to help me develop Smalled and related tools for OS/2. I'll discuss three of them in this little article and another three of them somewhere along the line. For now here's a cool trio:

REPACK
Ever since OS/2 2.0 came out, developers had the opportunity to compress the resource information that is used by a program. The resource file used while building an application normally contains descriptions for dialogs, icons, bitmaps, accelerator tables, help tables, etc. In OS/2 2.0 you could create an executable that had the resources compressed onboard. This saves some disk space when using the program.

Now I hear a lot of you thinking, "what a difference does that make, since disk space doesn't cost that much any more?" Well, true enough, but the main memory and processor of a computer are still a lot faster than the hard disk. So a smaller program will load a lot faster, even if some CPU time has to be spent decompressing the loaded file.

When Warp (OS/2 3.0) was released, a new compression was introduced - EXEPACK:2. With this, developers could compress EXE files when they were compiled, thus creating smaller EXE files which would load faster. The compression for the Warp EXE files was a lot better than the OS/2 2.0 version. (With this compression, Smalled 1.45 gets compressed from 140 Kb to 99 Kb.) The downside is that you can't use it with OS/2 2.x. Another downside is that you must tell your linker to use EXEPACK:2 to get compressed files.

Then I found the REPACK utility on the DevCon CD. This small utility lets me compress EXE files into the EXEPACK:2 format without having to recompile them. This means I can even repack existing applications without having to have access to the actual code.

It's very simple to apply the REPACK utility. Simply start REPACK with the name of the EXE file you want to convert to EXEPACK:2. REPACK will copy the original to a .bak file and create a new .EXE file. I found that this is a necessary precaution because the utility doesn't always work! With my programs it has always functioned, though.

You can also use REPACK to create files with the OS/2 2.x compression scheme. If you can get your hands on this little helper, use it. I found it a simple way to boost the start-up time of small applications.

PMSPY 1.1
One of the first articles I wrote for OS/2 e-Zine! handled the message paradigm. Almost everything that happens in OS/2 is the result of an event. These events cause OS/2 to send messages to the control window procedures that handle these messages. In the old days you could simply trace the program flow and see what happens but this "message paradigm" means that programming isn't that straightforward any more.

It would be nice to see all the messages that flow to a certain application. I find this kind of information very handy while debugging programs. In fact, sometimes I find that messages simply don't occur in the sequence I expect them, meaning my program malfunctions. Getting a hold on how messages are sent can be done by using a debugger (I tried the Borland OS/2 C++ debugger) but I found that tracing messages this way is a very clumsy method. This is where PMSPY32 comes in.

PMSPY32 is also a program I got from the DevCon CD. It lets you monitor the queue of any Desktop window, any window in the system, or if you like, the system queue. The messages with pm1 and pm2 are displayed in a list box on the Desktop.

By default this program will display all the messages that are passed to the object you're monitoring. This is not normally the way you would want to use it, though. PMSPY32 has many options on-board to make life a lot easier. You can select which messages are shown in the PMSPY main window and which are filtered out. This can be done by message (look at every message in the system individually), or by group. This last option I find very useful. If you are working on just one control, you can simply tell PMSPY to only show the messages for that control. It's even possible to make a filter subset out of this rough selection.

This last option is very handy. I find it very annoying to let my view of the messages be disturbed by a constant showing of the WM_MOUSEMOVE or WM_TIMER messages.

PMSPY32 has a very large set of possibilities and is a very worthwhile helper. I used it very intensively when working on the Smalled Drag-n-Drop. I also find it a great help at optimizing my code by eliminating unnecessary calls. If you're going to use this applet, give it a little time to get comfortable. Once you know it, it's great! (Be careful with looking at the system queue though, this might virtually halt your system in some cases.)

PMTREE
PMTREE is another one of those little programs developed by IBM for internal use. This is also a program I use a lot in debugging, however, it did more for me when I was going through the process of understanding the OS/2 API and the structure of the PM. With PMTREE you can graphically display the hierarchy of windows in an application.

This isn't explained in detail in the How Do I? column, but it will surely be in the future. Every application is built out of a hierarchy of windows. The Frame window is a good example of this. It has a title bar, max and min buttons, etc. All these parts are windows. With PMTREE you can visualize these parts with a lot of extra info about each.

PMTREE has helped me a lot in understanding the anatomy of certain OS/2 PM controls, like the spin button. I was able to do some nice tricks with the controls once I figured out how they where constructed. Making a spin button that only accepts floats and is infinite is an example of this (see EDM/2 v3n2).

PMTREE has a number of extra tricks up its sleeve. It allows you to send messages to any of the windows in the system. Although I can see that there's a use for this, I've never actually used this feature. Just like PMSPY, it pays to take the time to get to know this applet. It can do you great services in understanding and debugging your applications' structure.

Well, that's it for now. I hope you enjoyed this little addition to my regular column. Stay tuned in the future for another like this one!