Single-image download and execution with no setup program has been a hallmark of almost all of the tools that Bryce and I write and distribute on Sysinternals. I think most visitors agree that it’s more convenient to download a 200 KB ZIP file, extract its contents and execute a utility than to download and execute a 2 MB installer, in the process adding more clutter to your Start menu, before you can gain access to the tool only by navigating through that cluttered start menu to find it. And in the unlikely event you don’t want to use a tool any longer uninstalling a Sysinternals tool usually means just deleting it. User-preferences in the user-profile portion of the Registry (HKCU) might get left behind, but a lot of uninstall programs leave behind more than a few hundred bytes of data.
Unfortunately, the requirements faced by many tools of supporting 3 major lines of Windows operating systems – Windows 9x (believe it or not, if I post a tool that breaks compatibility with Windows 95 by using an API introduced in a newer version of Windows I hear about it immediately), Windows NT and Windows 64-bit – and several minor variants of each line makes delivering a tool as a single universal executable a challenge. Besides finding backward-compatible ways to accomplish what newer Windows APIs might make trivial, the tools that require support from a device driver or that require a native 64-bit image in order to work on 64-bit Windows face the biggest single-image delivery hurdle.
When we released the original versions of tools like Filemon and Regmon back in 1996 there were two downloads: one for Windows 95 and one for Windows NT. Each download file included an executable and driver where the executable was identical to both, but the driver specific to the operating system since the driver architecture for most types of Sysinternals drivers is totally different for Windows 95 than Windows NT. I wasn’t totally pleased with this arrangement since the connection between the driver and executable files wasn’t obvious to most people and copying the tools between systems meant having to remember to copy both files.
Then in March 1998 I came across an interesting
article by James Finnegan in Microsoft Systems Journal (now MSDN Magazine) that describes how to embed a driver as a resource in a host executable. When it starts the host executable extracts and installs the driver. I immediately began using the technique to pull the drivers into the executables. With James’ trick I could post one Filemon download consisting of a single executable that contained within it both the Windows 9x and Windows NT drivers. At runtime the executable detects the Windows version and extracts and installs the appropriate driver.
Over the last several years I’ve refined James’ code to be even more efficient, not even creating a Windows service to host the driver, but rather loading drivers directly using the undocumented NtLoadDriver API. To handle cases where you run the executable from removable media or a network share the tools try to extract their drivers to \Windows\System32\Drivers. If that directory is inaccessible, which would be the case if you booted Windows Preinstallation Environment (WinPE) off a CD, they fall back on extracting to the same directory in which the executable resides. A further refinement is made possible by the fact that Windows reads driver images entirely into memory and so never needs to reference driver images after loading them. Sysinternals tools take advantage of this by deleting their drivers immediately after loading them.
Here’s a Filemon trace of Regmon’s startup on Windows XP that shows Regmon extracting the driver to \Windows\System32\Drivers and then deleting it after it has installed the driver in memory:
As the years progressed the download executables for several tools grew to include more than two drivers. For example, the Registry monitoring architecture is different on Windows Server 2003 than on previous versions of the Windows NT line. That means that after Server 2003 released Regmon’s executable had three drivers stored within it.
Then with 64-bit Windows (the AMD64 variety of course – you might have noticed that there’s little support for Itanium, which reflects my belief, and I think that of others, including
Microsoft and
Dell, that Itanium has a limited future, one only guaranteed so long as there are no 64-way Opteron systems) I faced a new challenge: how could I continue to deliver single-image downloads for utilities like Filemon, Regmon, Process Explorer, and LiveKd, that require a native 64-bit executable in order to run on 64-bit Windows? Most 32-bit applications run fine on 64-bit Windows, but because of the pointer size difference it takes a 64-bit process to query the virtual memory of a 64-bit process.
The solution I came up with is to store a utility’s 64-bit version within its 32-bit image. When you run the 32-bit executable it detects the Windows version, and if it’s running on 64-bit Windows, extracts and executes the 64-bit image, waits for the 64-bit process to exit, and then deletes the 64-bit image. Here’s a Filemon trace of the 32-bit Process Explorer extracting the 64-bit version:
And here’s Process Explorer showing the process tree that graphically shows the relationship between its own 32-bit and 64-bit images:
As a result of all the different Windows versions we support the Regmon executable now has the following images embedded within it:
- The 32-bit executable
- The 64-bit executable
- The 64-bit driver
- The Server 2003 driver
- The Windows NT, 2000, XP driver
- The Windows 9x driver
Even with all that Regmon weighs in at only 415 KB: the 32-bit image by itself is only about 150 KB in size and each driver version is under 50 KB in size.
I think most of you will agree that a 180 KB zipped download of Regmon that requires no installation and that can be simply copied from system to system is preferable to the “best practices” alternative: a 2 MB MSI download that takes up to a minute to install just to get a 150 KB executable and 50 KB driver onto a system.
