Where is COMCTL32.OCX?

Yesterday and today, I spent a lot of my time convincing someone that it wasn't my fault that Windows XP doesn't have Comctl32.ocx installed.

Comctl32.ocx is an ActiveX library that contains Microsoft Common Controls - in other words, the objects that lets programs display controls like treeviews, listviews, etc. It was included with versions of Visual Basic prior to version 6. Version 6 and later use a different file, and in Windows XP the functioanlity of this file is included in Comctl.dll, which is installed in the system.

Anyway, this person (a nice person, by the way) is an engineer that creates application packages for a particular business unit for one of my clients. They got a complaint that one of their installation packages didn't work on the latest image because Comctrl32.ocx was missing. The conversation, in email, went like this:

• She: Your latest image doesn't have Comctl32.ocx.
• Me (after checking): The old one didn't, either. I think you need to add it to your package.
  
• She: Well, how did it get on the image, then? I didn't install anything on the image before I captured the installation.
• Me (after a lot of investigation): I don't know. I tested every standard program we install, and none of them install that file. The only thing I found that installed it is this package management utility.
  
• She: Oh, well, I did install that.

Honestly, I wasn't upset. I was glad that I was able to convey the idea "this isn't my problem" without ticking off anyone, since the engineer doesn't even work for the same company I do. It's always a little dicey trying to tell the client that they need to fix their problem.

Someday, I'll post my rant on why I dislike application captures, but this is a good example why.

Desktop engineering, part three

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

A couple of other things I wanted to say about this definition before moving on to other topics:

Consistent: One of the goals of desktop engineering is consistency. Consistency may be boring when it comes to suburban crackerbox houses or mainstream pop music, but it is great for computers. In IT support, boring is your friend, because boring means that your support costs go way down. This is because your process makes new machine set up a practical no-brainer, and every machine is a known, familiar quantity. When faced with a problem, your technicians don't have to worry about whether the tech who set up the machine remembered to add this software or tweak that registry setting. You know that it was done, because it is part of your documented, enforced setup procedure. Your support technicians consequently spend so much less time checking that the basics have been covered, and can move directly to solving the real problem.

There are levels of consistency. There is apparent consistency, and there is true consistency, and you should strive for the latter and avoid the former. True consistency is having machines that have the same software installed the same way, with the same configurations. Apparent consistency enforces things like a common screensaver, desktop arrangement, etc. Forcing desktop conformity can backfire. I think that if you enforce conformity in the desktop customizations, some people will feel a need to express their individuality and will lobby for Administrator rights just in order to be different. I say, let the users have their unusual wallpaper, and focus on making sure that all of the DLLs match.

Consistency does have its downside. When all of your desktop computers are the same, a problem seen on one computer is more likely to be seen on all of your computers. This means that a larger percentage of your problems will be enterprise wide, and so they will be the responsibility of the engineers to fix. This is where verification comes in.

A bigger issue (to my engineer's mind) is the perception that all problems are the responsibility of the engineers to fix. This can mean inappropriate escalation of problems to your most experienced (and expensive) staff. Procedures must be implemented to ensure that only problems that are related to the engineering of the desktop "make it" to the desktop engineers.