All programmers should be forced to do release builds!

So I'm still ploughing my way through this legacy application. I've finally got the thing to compile in release mode and now come the joys of getting it to actually work!

My predecessor, it seems, never did release builds. We only have a few copies of the app out there in the wild and they're all debug builds that 'work'. I have to say I was rather surprised at this and set myself the task of making the jump to always distributing release builds.

The first hurdle was to get the code to compile in release. Took a day or so of ensuring the right symbols were defined, the right compiler switches thrown and tracking down the odd ASSERT that was compiled away to nothing. (That in itself surprised me - I've never seen a code base so bare of ASSERTS - so bare in fact that it took a while to realise that what few there were were causing problems).

And now I have to track down why the damn thing doesn't actually work in release.

First problem is that my predecessor uses ints and shorts interchangeably. We have one function that retrieves a couple of numeric fields from a database as shorts and declares it's parameters as pointers to shorts. This is well and good except that the calling code is sprinkled with int declarations and to get the compiler to compile it he casts to (short *). Works ok in debug because the compiler obligingly sets his ints to zero before he uses em. In release you get garbage in the original int. The call to the database function gets what it believes is a pointer to a short and only sets the lower two bytes of the int. The upper two bytes are left as garbage and, as a result, the entire value is just plain wrong.

Aaarghhhhhhhh

Now before you ask, this is a VC6 app using MS STL. That makes it near impossible to use Warning Level 4. Once I get back to the US I'm going to move the app to VS.NET 2003 and invest the month it'll take to get clean compiles at Warning Level 4 with Warnings converted to Errors.

You wouldn't think it'd be so bloody hard

to write a proper masked edit control. In principle you intercept the stream of characters being typed at the keyboard, apply your filter criteria to them, discard the ones that your mask disallows and let the others through. And in fact, it really is that simple - if all you do is watch what the user types. Override the WM_CHAR message and filter away.

But that ain't enough. You also have to be careful that your user can't paste data into the edit control that violates your mask criteria. And that's much more difficult to prevent. I'm experimenting with a mixture of WM_CHAR filtering as aforesaid, plus WM_PASTE filtering where I pick the data off the clipboard, examine each character and post a WM_CHAR message to myself for each valid character. Of course I know this is going to bite me in the bum the first time someone tries to use the control on a non-US Windows system but I'll worry about that once I go home.

Doh!

I've just wasted an hour solving a small problem. The app uses a local path and a remote path - both these are stored in the registry and read on the fly as needed. I needed to activate the remote path (there's logic to test if the remote path exists - if not we use the local path). So I created the necessary key and set the path and... nothing! The app used the local path. So I fired up the debugger and traced the code. Sure enough, when the app tried to retrieve the remote path it came back with nothing and used the local path. Tracing into the Win32 call that reads the remote path it was returning PATH NOT FOUND for the remote path key but finding the local path key just fine. But they're both there! A careful check of the spelling of the keyname - they match. Delete the key and recreate it using cut and paste to copy the keyname from the source code to the registry. Still not found!

So then I tried a different approach. I could read the local path entry but not the remote path entry. Ok, so I changed the local path entry to a different value and traced again. It didn't change. By this time I'm scratching my head. So it's off to the MSDN Knowledge base for anything about registry value caching. Nothing useful popped up. And then....

My eye wandered a branch or two above the branch I had been looking at, in regedit. And there were TWO registry branches for my apps key.

It turns out that the guy who wrote this code (I've inherited it) had made a copy of our products registry tree, appending a dot to the name. And you guessed it, I'd been making all my changes in the copy.

Doh!!!!

Acronyms

I'm on site at Texas Instruments (Philippines) Incorporated. TI refer to the location as TIPI and pronounce it 'tippy'. I discover that they also have a site in Taiwan called Texas Instruments (Taiwan) Incorporated. You can imagine my disappointment when I learned they don't use the obvious acronym :-)

More memory leaks

Toward the end of 1996 I was seconded to a team of developers writing a database management system. The project was to run on Windows NT 4, was written in C++ and used an object oriented database (remember those?). Anyway, the majority of the other developers (all 5 of em) had a strong UNIX/C++ background whilst I had a strong Windows background, which is why I was seconded.

The database leaked memory like a sieve. I'm not kidding when I say that after running a single query and terminating the program the debugger took between 15 and 20 minutes to print out all the memory leaks. Most of the developers simply pressed the 'Stop' button on the debugger to terminate the program immediately rather than let the memory allocator print out it's diagnostics.

I asked them why they didn't fix the leaks. The first answer was that it wasn't their code, it was Windows! If it had been running on UNIX the operating system would handle it so it was obviously Windows fault. Hmm, I never did manage to convince em they were wrong on that one. The second answer was that they were only small leaks, only a few bytes per leak and any decent VM system should be able to handle that. Yes, they were only small leaks, millions of the buggers!

We had the source code to the database but it was 'too hard' to go in and fix the leaks. Now remember, this is 1996 when 128 Megs of memory in your machine put you into the power user category, and NT took about 90 of those megs. With nothing else but our app running it took about 25 queries to leak enough memory that swapping kicked in.

Their solution? They wrapped all the database code into a seperate executable and launched it for every single query. That way the database could leak all the memory it wanted; Windows would clean up after it. Of course, performance suffered but we developers were running on the latest and greatest Pentium systems so it wouldn't hurt us! Only the poor customer who still nursed hopes of getting reasonable performance on a 66 MHz 486. (I hope the sarcasm is coming through).

Mercifully the project was canned after a month or so and the other developers were free to pursue other contracts whilst I returned to normal duties. Oh, and the lead programmer on the team? It turns out he had the Australian dealership for the object database involved. What a surprise!

Ignorance is bliss

I was on the phone to my wife the other day and happened to mention the Jakarta bombing of the Australian Embassy. She hadn't heard of it. So I (mischevious bastard that I am) asked if she'd heard of the Beslan Massacre. She hadn't. She had noticed some flags at half mast and wondered if perhaps a president (maybe Ford) had died but that was the extent of it.

I shouldn't have been surprised. I've noticed quite a few people who've stopped following any kind of news over the last few years.

*shrug*

Wow

that was fast! I suppose it helps to be in a similar timezone to one of the Admins :-)

Er what am I talking about I hear you ask? Elapsed time from requesting blog to receiving blog was about 2 minutes.

Dammit, now that I've started a blog I suppose I'm going to have to update it occasionally. So here's the first entry. I'm standing at the keyboard typing this in Baguio City, Philippines. Standing? Uh huh. There are no chairs! That would be an unwarranted expense. It's getting tough on these old feet to be standing at the keyboard for upwards of 12 hours a day, 7 days a week. With any luck I'll be back in the US sometime in the next month though and able to write code the way any self respecting coder writes - sitting down! :-) I really must investigate my employers obligations with regard to sending me to client sites.

Well, that's my first rant. Not very exciting was it!