I was all set to write a riveting article on the importance of application UI response times, but another great little project came up and I couldn’t resist.

Basically, my friend come up to me at work today and asked if I knew of any way to record and save a song she had heard on the internet. It should go without saying that the legalities of this should be investigated a bit before trying this yourself, but in this case, I felt comfortable that we were within the law.

Audacity can do this sort of thing nicely, but the problem is, Audacity doesn’t ship with an MP3 encoder (due to legal reasons, I suspect). I needed to find a simple way to copy lame_enc.dll to the user’s hard drive, and create a registry key in the right spot that points to that dll. There are a lot of ways to do this: a little .NET application, a variety of scripting languages, etc. But let’s think about this for a sec…really, what you’re doing is a lot like what an installer does. InstallShield, Wise Installer, the installation wizard that comes with Visual Studio, WiX…all these are great, albeit a bit expensive and/or confusing. Did you know there are two great, free alternatives? Inno Setup and NSIS are both quite robust, fully scriptable, free installation packages. As an aside, I’d encourage you to not underestimate the significance of having your installer be totally scriptable…just being able to follow the version of your installer via a source control system is immensely helpful. And if you’re stuck with Windows Installer, check out WiX…it’s great.

Out of the free options, I tend toward NSIS for several key reasons:

1. Helpful support community
2. Used by Google
3. Very small install files (smallest of all installers)

There are several IDEs to help you create and maintain NSIS installers. I choose HM NIS Edit simply because it was first one I saw years ago (before all the others were available). It has a nice little wizard that can help you build a simple installer script very quickly.

I walked through the wizard and chose lame_enc.dll as the only file that this installer will install. I decided to put it in Program Files, since I assume that most users know not to randomly delete files from there. Plus, it sort of fits there .

Now, all, we need to do is add the registry key that tells Audacity where to find lame_enc.dll. The NSIS documentation is very helpful, and I found the answer in no time:

WriteRegStr HKEY_CURRENT_USER "Software\Audacity\Audacity\MP3" "MP3LibPath" "$PROGRAMFILES\LAME MP3 Encoder\lame_enc.dll"

My NSIS script already had a block of code called “MainSection”. That block contains the operations that happen when the installer runs. I just added my new operation to the end of the main section, and added a corresponding DeleteRegKey operation in the Uninstall section, and voila! The installer was done. Well, done after I compiled it, of course. Now, all I need to do is point my friend to the Audacity installer, and the LAME MP3 Dll installer I just wrote in 3 minutes, and she’ll be making her own mp3s like a pro.

Oh, and remember when I said that NSIS makes small installers? Well, the dll we’re installing here is 296KB, and the installer? It’s 219KB. Isn’t that refreshing?

I hope every developer has a chance to spend some quality time learning how modern installers work. That knowledge comes in handy more times than you might think. Check out NSIS and Inno Setup for starters…they’re so simple to use, I bet you’ll find yourself thinking of ways to use them before you know it.

Helpful links for this article:

• Installer source file
• Installer compiled
• Article on how to save audio from the internet

There’s a good chance most .NET developers don’t have to deal with this much anymore, but for those stuck in VB6, you might know the pain of cleaning up after ActiveX executables and DLLS.

If everything goes as planned, it’s trivial. For ActiveX DLLs, you can just use regsvr32 with the /u switch, like so:

regsvr32 /u dllFile.dll

For ActiveX executables, you use the /unregserver argument for EXE itself, like so:

ActiveXFile.exe /unregserver

Each ActiveX file has a class ID (CLSID) that uniquely identifies that file in the registry. When you unregister the ActiveX library with one the previous commands, all references to the library are removed from the registry. This is important if you’d like to update an ActiveX library that has had it’s CLSID changed. Normally, you’d just unregister the old library (using the old file), remove the old file, then copy in the new file and register it.

Lil’ Orphan Annie

So what happens if the old library file has been deleted? You’re stuck with all those old keys in the registry, and often times that will prevent the new from registering properly!

It just so happens I was working with a company that had a problem like this. Their product had several ActiveX exes and DLLS, and more often than not, when trying to update a client’s files, someone would forget to unregister the old libraries before removing them, so we found ourselves stuck in this mess quite often.

To figure out how to fix this, I decided to figure out exactly what happened when an ActiveX library is registered, so I could undo the changes. I did some research and concluded that when an ActiveX library is registered, the only thing on the system that changes is that several keys are added to the registry. There are several programs (mostly for installers) that will help you discover exactly how an installation has affected your system, but I wanted to try a free way. This is where a simple but irreplaceable tool came into play: the diff tool.

Visual diff tools rock!

Diff tools compare two text-based files (or blocks of text) and visually show you how those files are different. It’s an absolute must-have for programmers…when combined with a revision control software product like SVN, git, or Source Save, you can easily compare how a text file has changed since it was last ‘checked-in’. There are plenty of good ones out there…I’d recommend checking out WinMerge. It’s fast, free, looks good, and integrates nicely with TortoiseSVN.

So how is WinMerge going to help us here? Well, fortunately the Windows Registry Editor (regedit) provides an option to export the entire registry into a text file! So, discovering how your registry has changed after an operation is as simple as:

1. Taking a snapshot of your registry (export to text file)
2. Applying the change (registering your ActiveX DLL)
3. Taking another snapshot of your registry (export to different text file)
4. Comparing the two text files to spot the differences (Use WinMerge or other diff tool)

On to the next adventure

It’s ridiculously simple, but it works great, and it’s free. You’ll learn a lot about how much your registry is being used constantly by the OS and your running programs.

Now that we know which registry entries have changed, we can look for patterns and figure how to remove all traces of an ActiveX library from the registry just by knowing it’s original path. I’ll cover that topic in a future post.

I hope this can help out some poor soul still using VB6 ActiveX libraries!