June 5, 2000
By Karen Kenworthy
IN THIS ISSUE
Found that Internet site with the sale on hip-waders! Bought a couple, and I'm wearing mine already. The pair I bought for you is over in the corner. I'll turn my head while you put them on ...
OK, ready? Time to head back into the "setup" swamp. We've got a lot of treacherous ground to cover and we're burning daylight. Don't want the sun to go down on us in *that* swamp. Those gators grow pretty big.
As you recall, our journey began last week, when my friend Busy Bob asked a couple of questions. Why, he asked, do some programs leave behind entries in Control Panel's Add/Remove Program list, even after they've been removed? And how can these "ghost" entries be deleted?
Bob's questions prompted a brief discussion of install and uninstall programs, how they work, and why they fail. They also prodded me to update the Registry Pruner program. Now that little program cleans up after uninstall programs that leave traces in the Windows Registry. It locates and deletes those traces that confuse Control Panel's Add/Remove Programs applet.
No, there isn't a problem with courtship of lovely Monica by her beau Bill. That budding romance is growing splendidly. The "Type Mismatch" I'm referring to occurred inside the new Registry Pruner program. The first word of it came in a message from reader John Thoden: "Just thought you may want to know about this. Downloaded version 2 of your great utility Registry Pruner. When I click the Add/Remove tab, I get the following error: [Error 13: Type Mismatch] on WinNT workstation with SP 5. The SharedDLLs tab ran fine. Just let me know if I can be of further assistance. Thanks!"
Darn, I thought, upon hearing the news, there's definitely a bug in the new feature I added to the Registry Pruner. Time to get back to work. Fortunately, the program's originally feature, finding and deleting "SharedDLLs" Registry entries, was still working. Half a working program is better than none.
That illusion was shattered a few minutes later when another message arrived. This time it was reader Dave Crum, who wrote: "Karen, I think I may have found a bug in your latest Registry Pruner. :) I have the latest Visual Basic runtimes installed, but I get a run time Error 13, Type Mismatch each time I click on the Shared DLLs tab of the program. I have rebooted and the error still persists."
<sigh> So -both- halves of the new Pruner are broken? Nice job, Karen. What do you have planned for an encore? A cruise on the Titanic? Maybe a fun dirigible ride, to Lakehurst, New Jersey?
Both Pruner features work perfectly on my computer. And one half, or the other, seem to work on most other people's computers. What could be wrong? The answer, it turned out, was a rotten, submerged log, drifting through the setup swamp.
When a program reads a disk drive, it must provide Windows with the location of the data it seeks. The location is known as a pathname, and consists of a drive letter, followed by the names of one or more disk directories. A common pathname is C:\Windows\System. As you know, this location refers to the System directory, found within the Windows directory, stored on the C: disk drive.
A program must provide one more bit of information before it can read a hard drive, a filename. Filenames look like README.TXT, "Fourth Quarter Sales.xls," PTPruner.exe, or Karen.bmp.
Within the file is the actual data the program wants. The type of data stored in the file varies. Some files contain plain text, others hold spreadsheet formulas and data, while still more files contain sequences of computer instructions known as programs.
In most cases, programs that open files know what type of data to expect. For example, paint programs normally open picture files, and expect to find data representing an image. But if a program opens the wrong type of file, for example, when you use Notepad to open a picture file, bad things can happen. The type data it reads won't match the type of data it expects. It's what's called a Type Mismatch.
What does this have to do with setup programs? Well, setup programs store information in the Windows Registry. And reading information from the Registry is a lot like reading a disk file. First, a program must specify a location within the Registry, called a subkey. Subkeys look like this: HKEY_LOCAL_MACHINE\Software\Microsoft. If that looks a lot like a pathname, it's no mistake. Like a pathname, it describes a hierarchy of location. In this case, the subkey refers to the subkey named Microsoft, found within the subkey named Software, located within the main key HKEY_LOCAL_MACHINE.
Next, a program reading the Registry must specify a "data name". Data names play the same role within the Registry, as filenames play on a hard disk -- they give names to the data stored within. Data names even look like filenames. For example, the data names read by the Registry Pruner include DisplayName, SystemComponent, and UninstallString.
Each data name refers to a particular bit of Registry data, called the "data value." And like the contents of files, data values come in several types. Some Registry data consists of text strings, others strings are arbitrary binary data (often representing an icon or other image). Many Registry data values are short binary numbers.
You've probably already guessed what happened to the Registry Pruner. When reading the Registry, it expected to see certain types of data. For example, when reading values stored in data names such as UninstallString, the Pruner expected to find text, what Windows calls data type REG_SZ (a text string terminated by an all-zero byte). When reading the portion of the Registry where Use Counts of Shared DLLs are stored, the program expected to find numbers. In particular, it expected to see numbers in Windows' REG_DWORD format (a double- word, or 32-bit binary number).
And usually, the Pruner saw exactly what it expected. But once in a while, it encounters the handiwork of installation programs that don't quite understand how Registry data is supposed to be stored. Some setup programs, for example, stored their Shared DLLs Use Count as text, rather than a binary number. Others stored the DisplayNames of their programs as a special type of text called REG_EXPAND_SZ, a type of data reserved for command strings with placeholders for parameters that will be inserted later.
Poor, naive Registry Pruner didn't know what to do with these unexpected types of data. Instead of dying gracefully, it displayed the default error message for these sorts of occasions, "Error 13: Type Mismatch", then stopped.
Fortunately, Windows doesn't just provide programs with Registry data. It also tells programs the type of data they've just received. A clever program, like the latest Registry Pruner, use this extra information to decide whether to accept the Registry data as is, convert it to the proper format, or disregard it. A text string, for example, such as "3" can be converted to the number 3.
Whatever action is taken, you'll no longer see the dreaded Type Mismatch error message when the Pruner runs. If this appeals to you, give Registry Pruner v2.4 a try. In addition to the Type Mismatch fix, it also has a couple of improvements that make it easier to use. You can download the newest Pruner from my Web site at https://www.karenware.com/powertools/ptpruner. As always, you can download the program's Visual Basic source code too. And they're both free.
We're not out of the setup swamp yet, but we're making good progress. Still, the light is getting low, and we don't want to spend the night here. Too many people disappear that way. So let's call it a day, and rest up for our next outing.
Oh, and a little bird has told me, by then I'll have a wedding date for Monica and Bill. Stay tuned.