Friday, November 16, 2007

Thanks for the support

Oh yeah, thanks for all the nice mails I've received from people who love the program! I started this program mainly for myself (couldn't understand why no one else had done it this way), and I'm glad so many other people feel the same way.
It was great to see my question answered on Raymond Chen's legendary blog, The Old New Thing:
http://blogs.msdn.com/oldnewthing/archive/2007/10/29/5750353.aspx
The answer ("because it creates too much network traffic") is overly simplistic, but makes sense from a Microsoft point of view. They'd rather be safe than sorry. Still, the Mac has a built-in folder size option, off by default, but easy to turn on. In the comments, I notice that many people who don't use the program claim they wouldn't want to lose resources to the feature, because they don't use it anyway.... not noticing their own circular logic.
Also, I put a new Donate button at the bottom of the main page. Feel free to use it if you like. If you want to use the program for free, go ahead - I don't see why you shouldn't get to use a program that already exists just because you don't want to pay for it. This is my return for the years of amazing things I've enjoyed for free online. When copying and distribution is free and infinite, property rights are meaningless.

Version 2.4 Released

Finally, 2.4 is ready for download. Check the changelog or the source code for new features and fixes. One much requested new feature is disabling drive types. Now you can disable folder size for your network drives. Or disable it for your USB drive if it's not unmounting properly. But you might as well leave them all on, because it uses less memory now. If you could look what is in all the memory it's using, it would be mostly strings of paths. These are now all relative paths instead of absolute paths. It's still storing every relative path twice, so it could be cut down quite a bit more.
Finally you can download a 64-bit version! I've had it working for a while, but wanted to finish other changes before making install packages. It's kind of a pain to manually make installers, and make sure I haven't screwed up anything in the code. After I posted the 64-bit version, the next day I noticed that I posted the wrong file, that had a bug with logging into network drives. I updated the file without changing it in any other way, which is not a nice thing to do according to the MSI rules, but I didn't want to update all those files too. Hopefully no one will notice. It will be interesting to see which package is more popular!
I don't know if there will be a Vista version. An Ubuntu version is looking more likely.

Tuesday, November 13, 2007

New Release Imminent

Hey, thought I'd finally post something here about the status of the new version. I'm doing some final testing now on version 2.4! There are some new features (64-bit support, disabling drive types, new translations), some bug fixes (fixed size updating with moving folders), and some optimizations (should use less memory), so hopefully there's something for everyone. However, I haven't fixed some of the bigger issues - Vista support, and the scanner performance problem with too many files in one folder. But I should get this nice collection of fixes out. So I'll probably do a few more days testing before calling it done. There's nothing worse than posting a new version, then finding a critical bug immediately, and then fixing it requires updating all the version numbers again. So, check back for updates in a few days...

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.