September 11, 2000
By Karen Kenworthy
IN THIS ISSUE
If you downloaded the 'Net Monitor setup program (ptnetmon-setup.exe) from my Web site on Monday or Tuesday of last week, September 4 or 5, 2000, DO NOT RUN IT. The setup program contains an error that may make your system unbootable. You can identify this defective setup program by its size, approximated 5.5MB.
This setup program was removed from my Web site as soon I realized there was a problem on Tuesday evening. It was replaced with a new ptnetmon-setup.exe program which does not contain the original setup program's error. You can identify this new, safe setup program by its size -- approximately 1.33MB -- several megabytes smaller than the defective setup program.
If you've already downloaded and installed any version of 'Net Monitor, and your system is working, there's no need to uninstall the version you have. The error in the defective setup program only affects systems with certain combinations of Windows and Internet Explorer. If your system does boot successfully, no harm was done. If your system *is* affected, it won't boot; Windows Explorer will crash at the end of the boot sequence.
If you've already downloaded and installed the defective 'Net Monitor setup program, and your system is now unbootable, you can recover by re-installing Windows from your original CD. Install Windows into the same directory as before. All your settings and applications will be preserved. And the damage caused by the defective setup program will be repaired.
I am very, very sorry for the inconvenience and problems this has caused.
In a word, shdocvw.dll. This file is a peculiar part of Windows. Different versions ship with Windows 9x, Window NT and Windows 2000. Other versions of the file are included with each new release of Microsoft's Internet Explorer. As a result, the exact version you have depends not only on the version of Windows you're using, but also on the version of Internet Explorer installed on your computer.
Shdocvw.dll, found in your \Windows\System or \Windows\System32 directory, is known as the "Shell Document Object and Control Library." It's used by several programs, including Windows Explorer. As you know, Windows Explorer is the program that displays your Windows desktop, and the on-screen contents of folders. Shdocvw.dll is also used by my 'Net Monitor Power Tool.
Now normally, when a program needs a certain Windows component, it includes the latest version of that component in its setup program. For example, the 'Net Monitor setup program includes the latest version of the file msinet.ocx, a file that simplifies a program's access to the Internet. If your computer doesn't have a copy of a needed component, the setup program will add it. If you have an out-of-date version of the file, the setup program will replace it with the latest version.
This works well when all versions of Windows, and all applications, can use the latest version of a component. And a lot of work goes into making this possible. Most replaceable components are "backward compatible" with their older versions, meaning they add new features in a way that doesn't affect programs that only know about an older version.
Windows components that can and should be included in an application setup program are called "re-distributable," because its latest version can be re- distributed to end-users by folks who create Windows applications. Not only should including one of these files in a setup program do no harm, they may actually improve a system's reliability.
But sometimes, in the course of its evolution, a Windows component changes in ways that prevents backward compatibility. When that happens, special care must be taken to ensure the correct version is installed on each machine. Normally, application setup programs don't deal with this issue.
Instead of including several versions of the troublesome file, and trying to decide which is appropriate for each computer, application setup programs ignore the problem. They rely on Windows itself to manage the various versions and ensure that the correct one is always installed. These files, which include shdocvw.dll, are naturally called "not re-distributable."
By now you've probably guessed what happened. The 'Net Monitor setup program that was available for download last Monday and Tuesday included a copy of shdocvw.dll. In fact, it included the copy found on my personal development computer, which runs Windows 2000 Professional and Microsoft Internet Explorer v5.5.
Copying this version, the latest available, to some computers does no harm. But copying it to others, especially those that aren't running Internet Explorer 5.5, can cause a big problem. Specifically, during the boot process, Windows Explorer will crash immediately after starting.
How It Happened
For several years I've used the setup program generator that Microsoft ships with its Visual Basic development system. Called the "Package and Deployment Wizard," it automatically scans a Visual Basic program, determining which re- distributable files the program uses. It then creates a single, compressed .cab file that contains those re-distributable files, plus the Visual Basic program's .exe file.
The generator also provides a small program, called setup.exe, that performs the actual installation. When run, setup.exe determines which files are needed by a particular computer, extracts those files from the installation's .cab file, and copies them to the appropriate places on a user's computer.
In my experience, the Package and Deployment Wizard has always done its job well. It accurately identifies the files that should, and may, be re- distributed. And the setup files it creates are relatively small and reliable. But it does have a few shortcomings.
First, it has a bug that causes its setup.exe program to fail when it encounters computers with non-U.S. date and time formats. Second, it silently fails when it encounters a read-only file named setup1.exe in a person's TEMP directory (often \Windows\Temp). That's because it creates a program names setup1.exe during an early stage of the installation process, and launches that program to do most of its work. If a program by that name already exists, it is launched instead. The result can be a completely different program (the one that created the read-only setup1.exe file) installed in place of the intended program.
The Package and Deployment Wizard also has trouble telling the difference between a brand new installation, and an upgrade or repair installation. The result can be multiple entries in Control Panel's Add/Remove Programs list, or none at all. Also, setup programs generated by the wizard use an old method of keeping track of shared files, often resulting in old files being left on a person's hard disk after they're no longer needed.
For these and other reasons, Microsoft has for some time been designing a new standard for setup programs to follow. In the future, all setup programs will come with an .msi (Microsoft Windows Installer) file. This file is a database, listing all components needed by a particular program, and where it expects to find them. This database is consulted a new Windows feature called Windows Installer during every installation. A copy of the .msi file is also saved by Windows, for future use during upgrades, re-installs, uninstalls.
Building .msi files is not for the faint of heart. Even Microsoft doesn't expect mere mortals, or even experienced developers, to create one. Instead, Microsoft has encouraged other companies to create .msi file generators. These tools provide a nice, graphical picture of the setup program being created, showing its dialog boxes, file locations, the text it displays, and more. Once a developer is satisfied with the new setup program, a corresponding .msi file is automatically created.
To help Visual Basic programmers, and to compete with Microsoft's older Package and Deployment Wizard, most of these programs can automatically scan a Visual Basic program, and build the .msi file need to complete its installation. In theory, the creation of a Visual Basic program's .msi file needs no manual intervention. The .msi generator identifies the re-distributable files, adds them to the .msi file it is creating, and adds all other necessary .msi file entries.
To get ready for the brave new world of Windows Installers, I've recently been experimenting with two new .msi file generators, each written by a large, independent software company that specializes in developing installation tools. Both work closely with Microsoft. In fact, Microsoft itself uses the tools created by each company.
Until last week, my experiences with them had been completely satisfactory. But when reports of programs with 'Net Monitor installations began to arrive in my e-mail Monday night and Tuesday morning, I knew something was amiss. That's when I removed the 'Net Monitor installer from my Web site, replaced it with one created by the old Package and Deployment Wizard, and began trying to discover what had happened.
As we know now, the .msi-based installation package incorrectly included a copy of shdocvw.dll. It turns out that both of the third-party .msi generators I was testing had the same bug. Both incorrectly identified shdocvw.dll as a re- distributable file. So both incorrectly included it in the setup program they created.
I have since talked to both companies involved, and they have assured me they have found and fixed the error. New versions of their products should be available to developers sometime this week. I also discussed with them ways to make their detection of not re-distributable files more reliable in the future. Microsoft stores of such files in a special file called VB6DEP.INI. But neither company's product consulted this file. Instead, both tools maintained their own (as it turned out, incomplete) list of not re-distributable files.
What Will Happen
For the time being, I'm going to stick with the tried and trusted Package and Deployment Wizard for creating my installation programs. The installer for 'Net Monitor, and all my other Power Tools, available on my Web site were created by this tool.
But I'm still investigating the new Windows Installer format, and the third- party software necessary to use it. I'm particularly excited about a feature being developed by one company that would automate the download of components, ensuring that only the components actually needed by a particular computer are sent over the Internet. This should save a lot of download time and disk space, and reduce errors.
When I'm ready to try the .msi format again, I'll let you know. And I'll include a warning that this format is new and might not work as well as the older format. I'll still make the older installer available too, for those not ready to make the switch.
And I'll pray that nothing like this problem ever occurs again. It's the kind of thing that keeps programmers awake at night, wondering if there's something they've overlooked, something that works fine on the machine's they've tested, but will fail on others yet untried.
As I said at the beginning, I'm very, very sorry this happened. Not to make light of it, but this is the sort of thing that happens when we venture into the "Setup Swamp." It's full of alligators, and sometimes we get bit by one. I guess that's the reason I've been humming a song by country and western singer and songwriter Jerry Reed for the last few days. It goes like this ...
"Well, the folks around south Louisiana said Amos was a heck of a man. He could trap the biggest, the meanest alligator and just use one hand. That's all he's got left cause an alligator bit him. Left arm gone clean up to the elbow." -- "Amos Moses" by Jerry Reed
So if you see me this week, do still wave and say "Hi" but don't be surprised if I wave back with just my right hand.