There are dark things lurking in source control. There are blocks of code so twisted and ill-conceived, so warped that any unlucky programmer that happens upon them is sent screaming and gibbering to the pages of a CodeSOD. There are also subtle horrors; evil squirming things that lurk beneath simple, normal facades. Or perhaps not so normal; beware what waits inside a VB6 front end and a DCOM back end.

Rick had once browsed through some application code to estimate some minor upgrade to the Contract Manager application. The code, of course, was a proxy for documentation that didn't exist. There wasn't much to it; a small server side DCOM library with a handful of classes and a VB6 client with a small army of pretty straight-forward looking screens. In production, the client and server would communicate across a moderately slow WAN. He made his assessment and forgot all about it. The customer decided the changes weren't worth the cost, and Rick didn't hear of the application for some time.

But Rick had looked at the application once. Which meant he knew infinitely more about the application than the nothing his coworkers knew. He owned it now.

The users requested a new field added to one of the screens. "Sure, should be no problem," Rick said. How hard could it be to add a field? In a reasonable DCOM application, there might be some problems with maintaining binary compatibility or any one of the fragile pain-points DCOM exposed developers to, but that was all something Rick knew his way around.

Unfortunately, this wasn't a reasonable application. Instead of taking advantage of the "distributed" part of DCOM, the application didn't pass any objects between the client and the server. Instead, it passed strings- strings of XML. The application had been written in an era when XML was all the rage, when everyone was excited about the idea of making two systems that didn't use the same technologies communicate with each other. The original developer, in his excitement, had neglected to notice that he was developing two systems that used the same technology.

Rick traced through the code and found that everything the server sent back to the client was XML stored in a string variable. The client parsed the XML document with a careful sequence of InStr and SubStr commands, and loaded the results into in-memory objects. The screens worked on the objects (and in some cases, the screen was the object- no need to separate concerns here!), and when they were finished, they bundled it back up into XML and sent the results back to the server. The server, of course, mirrored this process. It transformed the XML back into the same set of objects the client used.

(Server) -> Objects -> XML String -> DCOM Stack <- XML String <- Objects <- (Client)

Rick took one look at the fragile string-munging "XML parser" and dramatically revised his estimate for how long it would take to add a field. The customers got sticker shock, and decided they didn't really need that new field after all. Rick documented his findings and went back to actively not thinking about the Contract Manager application.

He kept right on not thinking about it until the server it lived on was due to be decommissioned. All of the components needed to move to a new box with a different network name. One of the nice things about COM is that relationships are largely self documenting. Rick identified what needed to be moved, pointed the client at the new server and fired it up.

It didn't work.

Rick went through the server with several different kinds of fine-toothed comb. He ran some VBScripts to confirm that he could remotely connect to the components. He ran the application through the debugger. Everything looked like it was talking and communicating, but there was only one problem: the server was crashing on certain calls. Rick compared the behavior in production with the behavior in test, and he noticed something else strange- in production, the server wasn't actually returning XML- it was returning short strings of meaningless binary data. And both the client and the server seemed okay with this.

A light went on, and Rick dug back through the code. This time, he spotted the answer stashed away in the inaptly named "basData.bas". A pair of WinAPI library imports that loaded "cmclib.dll". Static loading, of course, meant that there was no documented reference- unless one was looking specifically for that line of code, one would never know what was missing. He deployed that library to the server and everything worked. But what was the library?

Why, it was a copy of zlib renamed to look like it was part of the application. The XML format used by the contract manager was so large that the remote offices complained about performance. The original developer had taken that bulky XML file format and converted it into a svelte binary format by zipping it. If only he had been using a technology that permitted binary transmission in the first place…

(Server) -> Objects -> XML String -> Zipped String -> DCOM Stack <- Zipped String <- XML String <- Objects <- (Client)

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!