Friday, June 15, 2007

64-bit!

Does that number excite you as much as it excites me? I have finally taken hold of a 64-bit machine at work, giving me a nice test machine for FolderSize. First I had to understand the new file mapping scheme (64-bit DLL's are in the system32 directory, and 32-bit DLL's are in the SysWow64 directory - thanks guys), and the registry remapping scheme (same thing, but with optional reflection enabled by another key...). I knew the Explorer column handler DLL would have to be 64-bit, so it could be loaded into a 64-bit process. That also meant it had the 64-bit "view" of the file system, which is also the real view.

For Internet Explorer in 64-bit, there are actually two Internet Explorer items on the Start menu, right beside each other, but one with a 64-bit suffix. It is not the default browser. For Windows Explorer, there is only the 64-bit version.

The service executable, on the other hand, one might think could be left as a 32-bit exe. This might be advantageous, especially for memory usage. But that doesn't work because it only has the 32-bit view of the file system, which causes some confusion when receiving paths from the 64-bit Explorer. The file mapping system is retarded.

Even the Control Panel, a lowly Property Page dialog, most of which's file size is consumed by my picture, could not avoid the lure of 64-bit. If it stayed behind in 32-bit land, XP would whisk it aside into a "32-bit Control Panels" control panel, safely hidden from the discerning eyes of a 64-bit control panel user. Compiled as 64-bit, it takes its place among a Control Panel of equals.

So now I have 3 32-bit files, and 3 64-bit files to install. What would be great, is if I could package them all into one downloadable file, which then automatically installs the right versions for your system. Basically, the same deal as the "Universal Binary" on the Mac, which packages all executables in one item, and the system knows which one to run. This can make Mac programs twice as large as separate versions, but it makes it so much easier.... things "just work".

But even the latest version of Windows Installer, the official system in Windows to install and register programs correctly, doesn't support one installer for 32-bit and 64-bit platforms. I would have thought you could just mark which bitness each component is, and it would automatically figure things out. Not so. You have to mark your installer as 32-bit or 64-bit, and the 32-bit installer once again hallucinates its own version of the file system. I can't think of any way I can just make one MSI that will install correctly on 32-bit and 64-bit Windows. A workaround would be to make a 32-bit exe, that can ask if it's on a 64-bit machine, and then extract a particular MSI from within itself, and launch that. That should work, but then I have to distribute a suspicious-looking exe instead of a native installer. And it has to do messy things like clean up its own temporary files. Ugh.

Or, I can have 32-bit and 64-bit separate downloads. I'm sure most users wouldn't have a problem with this, but if things can be screwed up, they will eventually be, so why even allow that possibility?

Unfortunately, I still don't have a Vista version of FolderSize yet. Hopefully it will work, but you have to do annoying things like register a schema.