Lifehacker Redefining 'Tiny'

When the cat's away the lusers go stupid.

Get It Try It

'Top 10 Tiny & Awesome Windows Utilities' reads the headline at Lifehacker. Obviously 'tiny' has been redefined. Following modern Lifehacker principles for Microsoft Windows the word 'tiny' would apply to any of the following.

• The Graf Zeppelin;
• A moderately sized Brachiosaurus; or
• The 'tiny' lifehacker depicted below.
  

Clearly some of these 'slim utilities' have 'utility' but undeniably the art of programming on Windows is lost. First a look at the ten 'tiny apps' and then the explanation of what happened - still and all - to turn Microsoft applications into bloat monsters.

Golden Quotes from Lifehacker

The term 'lifehacker' for the crowd hanging out at Lifehacker is a bit of a misnomer anyway: most of these people wouldn't know how to hack their way out of an MS-DOS batch file. But anyway.

'It's the little things that make a Windows system great.'

One again: it's the definition of 'little things' and the wondrous implication a 'Windows system' can ever be 'great'. With an estimated 20,000 files per installation - which can nevertheless take a walloping 32 GB on disk - Windows is truly in a class of its own when it comes to bloat. Calling Windows great or even potentially great is tantamount to claiming a Happy Meal can be considered as great as Frank Slade's $24 sandwich at the Oak Room or the Caneton a l'Orange at Tour d'Argent. If you've never seen better or experienced better you won't know there is better. Kind of like going to K-Mart for your latest fashions: if you shop there then fine - just don't claim you're wearing Dior.

'Most of these apps do, indeed, use less than 10MB of hard drive space when installed, or use that much when they're running in the background.'

Whoa. Someone here isn't so keen on the subtle difference between HDD space and use of real/virtual memory. Whatever - we're talking life hackers here. But worse: 10 MB disk space constitutes a bloat monster. The applications in the XPT vary in size but their average size is still 7.19 KB on disk. Not megabytes or gigabytes but kilobytes. 7.19 KB is 7362 bytes. That's the average size. For close to 150 applications. That's the average size for file managers, disk editors, hex editors, disk scanners, file scanners, file system tracking applications, and so on and so forth - the functionality of which most third party authors - and even Microsoft - have never come close to.

7.19 KB. 7362 bytes.

Anyway: here's the 'top 10' countdown.

10. Taskbar Shuffle

It's not eminently straightforward to examine this gem as its website (http://www.freewebs.com/nerdcave/taskbarshuffle.htm) no longer exists. But good old CNET still has a link. It's freeware too and that's never a minus.

The download is 630 KB. It comes as file 'ts2.5_setup.exe'. It's that 'setup' you have to be scared of: this means you can't just run the sucker - it has to be installed. And as shall be explained later, that is almost always bad.

The download is a self-extracting executable (enough EXE code to unpack a ZIP) meaning you need tools of your own to inspect what's inside. Given you're using an administrators account it also means the executable can wreak havoc on your system and basically get at any sensitive system nook or cranny it wants to. Good vendor? OK, you might be alright. Given your definition of 'good' is the same as theirs. But bad vendor? First to leave Windows please turn out the lights. Leave the rest of the lusers in the dark. They won't mind - they're already in the dark.

The download is also compressed - meaning it's probably going to take more space than it already does. And let's remember what this tool supposedly does: rearranges tabs on your task bar and icons in your system tray. Wow!!1! So let's disregard the fact that startup routines can determine the order of system tray icons, essentially making this part of the program irrelevant. And let's instead ask ourselves if a program module on disk weighing in somewhere between 630 KB and a megabloat is really needed to effect what in principle is an illegal system hook. And the answer has to be 'no f-ing way'.

9. Everything

'It's probably smaller than your desktop wallpaper', say the Lifehackers. And that part can be true. Unless you're using a vector-based graphics system. Which Windows is not. But it's the next statement that jars the senses.

'But Everything is more useful and efficient than applications 25x its size.'

Now whilst it may be true there are applications twenty-five times the size of Everything that are abysmally useless (and we're talking Windows applications here) it is certainly absolutely positively not true Everything is a compact powerhouse.

Here are some of the 'features' touted at the voidtools.com website.

• Small installation file
• Clean and simple user interface
• Quick file indexing
• Quick searching
• Minimal resource usage
• Share files with others easily
• Realtime updating

'Small installation file'. Again: the Lifehackerz are redefining basic application topology. The self-extracting executable is 334 KB (341,811 bytes); the ZIP archive is 272 KB (277,614 bytes). Unzipping the ZIP archive reveals a final executable of 602,624 bytes. So it's smaller than a blimp but still takes three quarters of a megabloat of your precious HDD space.

What does Everything do? In this respect it's quite tidy. It works a bit like Google Desktop or Apple's Spotlight (or various earlier Redmond technologies with nearly ten year whiskers). It 'indexes' your hard drive and then whenever you want to find something can generally find it pretty fast.

This of course with an OS install estimated to have 20,000 files. (By way of comparison Mac OS X has three times that in directories alone.)

But there are caveats, the most annoying of which is the program only runs on NTFS file systems. And although it's a really good idea to abandon FAT on that platform for all possible reasons, it's hardly a help when you want to find something. And so Everything suddenly morphs into Nothing.

The most staggering caveat is of course the whole idea of 'indexing': this involves running asynchronous threads to keep track of all disk activity - something that competes with your own work much like your typical trojan army. At the end of the day the question becomes: does one really have to index a hard drive to get yesterday's news when well written search utilities will find things faster without the indexes?

And the final caveat: Everything doesn't look inside files. Google Desktop does (Google looks inside everything) and Apple's Spotlight does but Everything doesn't. So it's not really Everything anyway, is it?

Radsoft's X-scan finds things too. It also uses regular expressions. It can also delimit searches to specific file types. It weighs 10.5 KB on disk. And when you want to look inside files you simply drop what you want on X-find which takes 9.5 KB on disk. Together these two utilities do more than Everything and do it faster and with absolutely no intrusion whatsoever but together take only 20 KB on disk.

X-frame sniffs Ethernet frames and parses upwards through ARP, ICMP, IGMP, IP, TCP, and UDP. 13 KB on disk. That's 'tiny'.

So this is a sales pitch? No. If you feel inclined to purchase the XPT then by all means do so. But the Radsoft website has always been about more than vending software. And the comparison is given for a very palatable reason: namely that all sense of proportion, once on the rise in the world of Windows, seems today more in danger of being lost than ever.

An also-ran for Number Nine is Locate32. You have to love the name - as if 32-bit computing is a novelty and '32' is a buzzword, a catchphrase. Oh well. Locate32 is open source, meaning one can look at what's taking up all that space on disk.

Locate32 is - strangely enough - available in 64-bit versions as well. But it's still called Locate32 even there. Whatever: the self-extracting (as always) executable for the 32-bit Locate32 is 1.3 MB (1,327,104 bytes). That's a lot of bytes for something that's compressed and going to get even bigger and essentially do the same thing as Unix find.

The source code for the identical version of Locate32 is a staggering 6 MB (6,253,003 bytes) to download. This download can yield further clues as to what's going on inside this benign/mutant monster. Here's a listing with Rixstep's Xfind made possible by interaction with their Xscan which reveals some rather shocking secrets.

423 items, 23130099 bytes, 47112 blocks, 0 bytes in extended attributes.

locate-sources/3rdparty
locate-sources/3rdparty/bin
locate-sources/3rdparty/include
locate-sources/3rdparty/include/bzlib.h
locate-sources/3rdparty/include/md5.h
locate-sources/3rdparty/include/pcre.h
locate-sources/3rdparty/include/pcreposix.h
locate-sources/3rdparty/lib
locate-sources/3rdparty/lib/libbz2.lib
locate-sources/3rdparty/lib/libbz2d.lib
locate-sources/3rdparty/lib/libmd5.lib
locate-sources/3rdparty/lib/libmd5d.lib
locate-sources/3rdparty/lib/libpcre.lib
locate-sources/3rdparty/lib/libpcred.lib
locate-sources/3rdparty/lib64
locate-sources/3rdparty/lib64/libbz2.lib
locate-sources/3rdparty/lib64/libbz2d.lib
locate-sources/3rdparty/lib64/libmd5.lib
locate-sources/3rdparty/lib64/libmd5d.lib
locate-sources/3rdparty/lib64/libpcre.lib
locate-sources/3rdparty/lib64/libpcred.lib
locate-sources/3rdparty/LICENCE-PCRE
locate-sources/3rdparty/LICENSE-BZIP2
locate-sources/3rdparty/md5 copyright.txt
locate-sources/bin
locate-sources/bin/lrestool.exe
locate-sources/HFClib sources
locate-sources/HFClib sources/HFCCon32
locate-sources/HFClib sources/HFCCon32/HFCCon32.vcproj
locate-sources/HFClib sources/HFCLib32
locate-sources/HFClib sources/HFCLib32/HFCLib32.vcproj
locate-sources/HFClib sources/Src
locate-sources/HFClib sources/Src/AppClasses.cpp
locate-sources/HFClib sources/Src/BaseClasses.cpp
locate-sources/HFClib sources/Src/BaseWindowFunctions.cpp
locate-sources/HFClib sources/Src/com.cpp
locate-sources/HFClib sources/Src/CommonControls.cpp
locate-sources/HFClib sources/Src/CommonControls.inl
locate-sources/HFClib sources/Src/CommonControlsEx.cpp
locate-sources/HFClib sources/Src/CommonControlsEx.inl
locate-sources/HFClib sources/Src/Controls.cpp
locate-sources/HFClib sources/Src/Controls.inl
locate-sources/HFClib sources/Src/Converting.cpp
locate-sources/HFClib sources/Src/Crypting.cpp
locate-sources/HFClib sources/Src/Debugging.cpp
locate-sources/HFClib sources/Src/Dialogs.cpp
locate-sources/HFClib sources/Src/Error.cpp
locate-sources/HFClib sources/Src/Exceptions.cpp
locate-sources/HFClib sources/Src/File.cpp
locate-sources/HFClib sources/Src/File.inl
locate-sources/HFClib sources/Src/GdiObject.inl
locate-sources/HFClib sources/Src/General.inl
locate-sources/HFClib sources/Src/GeneralClasses.cpp
locate-sources/HFClib sources/Src/HFCApp.h
locate-sources/HFClib sources/Src/HFCArray.h
locate-sources/HFClib sources/Src/HFCCmn.h
locate-sources/HFClib sources/Src/HFCCmnEx.h
locate-sources/HFClib sources/Src/HFCCom.h
locate-sources/HFClib sources/Src/HFCCtrl.h
locate-sources/HFClib sources/Src/HFCDebug.h
locate-sources/HFClib sources/Src/HFCDef.h
locate-sources/HFClib sources/Src/HFCDlgs.h
locate-sources/HFClib sources/Src/HFCExcp.h
locate-sources/HFClib sources/Src/HFCFunc.h
locate-sources/HFClib sources/Src/HFCGen.h
locate-sources/HFClib sources/Src/HFCLib.h
locate-sources/HFClib sources/Src/HFCList.h
locate-sources/HFClib sources/Src/HFCMath.h
locate-sources/HFClib sources/Src/HFCMem.h
locate-sources/HFClib sources/Src/HFCNmsp.h
locate-sources/HFClib sources/Src/HFCRc.h
locate-sources/HFClib sources/Src/HFCStr.h
locate-sources/HFClib sources/Src/HFCWin.h
locate-sources/HFClib sources/Src/MainFunctions.cpp
locate-sources/HFClib sources/Src/Math.inl
locate-sources/HFClib sources/Src/MathClasses.cpp
locate-sources/HFClib sources/Src/MathFunctions.cpp
locate-sources/HFClib sources/Src/Memory.cpp
locate-sources/HFClib sources/Src/Memory.inl
locate-sources/HFClib sources/Src/ShellExtension.cpp
locate-sources/HFClib sources/Src/StdHFCLibrary.cpp
locate-sources/HFClib sources/Src/StringClass.cpp
locate-sources/HFClib sources/Src/Strings.cpp
locate-sources/HFClib sources/Src/Strings.inl
locate-sources/HFClib sources/Src/System.cpp
locate-sources/HFClib sources/Src/vb.cpp
locate-sources/HFClib sources/Src/WindowClasses.cpp
locate-sources/HFClib sources/Src/WindowControls.cpp
locate-sources/HFClib sources/Src/Windows.inl
locate-sources/HFClib sources/Src/WindowsFunctions.cpp
locate-sources/include
locate-sources/include/CommonControls.inl
locate-sources/include/CommonControlsEx.inl
locate-sources/include/Controls.inl
locate-sources/include/ExecutableCompressor.h
locate-sources/include/File.inl
locate-sources/include/GdiObject.inl
locate-sources/include/General.inl
locate-sources/include/HFCApp.h
locate-sources/include/HFCArray.h
locate-sources/include/HFCCmn.h
locate-sources/include/HFCCmnEx.h
locate-sources/include/HFCCom.h
locate-sources/include/HFCCtrl.h
locate-sources/include/HFCDebug.h
locate-sources/include/HFCDef.h
locate-sources/include/HFCDlgs.h
locate-sources/include/HFCExcp.h
locate-sources/include/HFCFunc.h
locate-sources/include/HFCGen.h
locate-sources/include/HFCLib.h
locate-sources/include/HFCList.h
locate-sources/include/HFCMath.h
locate-sources/include/hfcmem.h
locate-sources/include/HFCNmsp.h
locate-sources/include/HFCRc.h
locate-sources/include/HFCStr.h
locate-sources/include/HFCWin.h
locate-sources/include/Math.inl
locate-sources/include/Memory.inl
locate-sources/include/Parsers.h
locate-sources/include/ScreenEffects.h
locate-sources/include/Strings.inl
locate-sources/include/Windows.inl
locate-sources/lib
locate-sources/lib/HFCCon.lib
locate-sources/lib/HFCCond.lib
locate-sources/lib/HFCLib.lib
locate-sources/lib/HFCLibd.lib
locate-sources/lib/parsers.lib
locate-sources/lib/parsersd.lib
locate-sources/lib64
locate-sources/lib64/HFCCon.lib
locate-sources/lib64/HFCCond.lib
locate-sources/lib64/HFCLib.lib
locate-sources/lib64/HFCLibd.lib
locate-sources/lib64/parsers.lib
locate-sources/lib64/parsersd.lib
locate-sources/LICENCE
locate-sources/Locate
locate-sources/Locate/common
locate-sources/Locate/common/common.cpp
locate-sources/Locate/common/common.h
locate-sources/Locate/common/common.vcproj
locate-sources/Locate/hlp
locate-sources/Locate/hlp/dialog_locate.src
locate-sources/Locate/hlp/hid_edit_copy.src
locate-sources/Locate/hlp/hid_edit_cut.src
locate-sources/Locate/hlp/hid_edit_invertselection.src
locate-sources/Locate/hlp/hid_edit_selectall.src
locate-sources/Locate/hlp/hid_file_close.src
locate-sources/Locate/hlp/hid_file_copy.src
locate-sources/Locate/hlp/hid_file_createshortcut.src
locate-sources/Locate/hlp/hid_file_cut.src
locate-sources/Locate/hlp/hid_file_databaseinfo.src
locate-sources/Locate/hlp/hid_file_delete.src
locate-sources/Locate/hlp/hid_file_exit.src
locate-sources/Locate/hlp/hid_file_findusingdatabases.src
locate-sources/Locate/hlp/hid_file_open.src
locate-sources/Locate/hlp/hid_file_opencontainingfolder.src
locate-sources/Locate/hlp/hid_file_properties.src
locate-sources/Locate/hlp/hid_file_removefromlist.src
locate-sources/Locate/hlp/hid_file_rename.src
locate-sources/Locate/hlp/hid_file_saveresults.src
locate-sources/Locate/hlp/hid_file_sendto.src
locate-sources/Locate/hlp/hid_file_stopupdating.src
locate-sources/Locate/hlp/hid_file_updatedatabase.src
locate-sources/Locate/hlp/hid_file_updatedatabases.src
locate-sources/Locate/hlp/hid_file_updateselected.src
locate-sources/Locate/hlp/hid_help_about.src
locate-sources/Locate/hlp/hid_help_index.src
locate-sources/Locate/hlp/hid_options_settings.src
locate-sources/Locate/hlp/hid_options_settingstool.src
locate-sources/Locate/hlp/hid_special_changecaseforfilename.src
locate-sources/Locate/hlp/hid_special_changefilename.src
locate-sources/Locate/hlp/hid_special_computeMD5sums.src
locate-sources/Locate/hlp/hid_special_computeMD5sumsforequalsizefiles.src
locate-sources/Locate/hlp/hid_special_copypathtoclipboard.src
locate-sources/Locate/hlp/hid_special_copyshortpathtoclipboard.src
locate-sources/Locate/hlp/hid_special_removedeletedfiles.src
locate-sources/Locate/hlp/hid_special_showtotalsize.src
locate-sources/Locate/hlp/hid_special_updatefileinformation.src
locate-sources/Locate/hlp/hid_systemtray_openlocate.src
locate-sources/Locate/hlp/hid_view_arrange_aligntogrid.src
locate-sources/Locate/hlp/hid_view_arrange_autoarrange.src
locate-sources/Locate/hlp/hid_view_arrange_bydate.src
locate-sources/Locate/hlp/hid_view_arrange_byextension.src
locate-sources/Locate/hlp/hid_view_arrange_byfolder.src
locate-sources/Locate/hlp/hid_view_arrange_byname.src
locate-sources/Locate/hlp/hid_view_arrange_bysize.src
locate-sources/Locate/hlp/hid_view_arrange_bytype.src
locate-sources/Locate/hlp/hid_view_arrangeicons.src
locate-sources/Locate/hlp/hid_view_details.src
locate-sources/Locate/hlp/hid_view_largeicons.src
locate-sources/Locate/hlp/hid_view_lineupicons.src
locate-sources/Locate/hlp/hid_view_list.src
locate-sources/Locate/hlp/hid_view_refresh.src
locate-sources/Locate/hlp/hid_view_selectdetails.src
locate-sources/Locate/hlp/hid_view_smallicons.src
locate-sources/Locate/hlp/howto_externaldrives.src
locate-sources/Locate/hlp/HTMLDefines.h
locate-sources/Locate/hlp/Images
locate-sources/Locate/hlp/Images/.svn
locate-sources/Locate/hlp/Images/.svn/entries
locate-sources/Locate/hlp/Images/.svn/format
locate-sources/Locate/hlp/Images/.svn/prop-base
locate-sources/Locate/hlp/Images/.svn/prop-base/Bullet.gif.svn-base
locate-sources/Locate/hlp/Images/.svn/props
locate-sources/Locate/hlp/Images/.svn/text-base
locate-sources/Locate/hlp/Images/.svn/text-base/Bullet.gif.svn-base
locate-sources/Locate/hlp/Images/.svn/tmp
locate-sources/Locate/hlp/Images/.svn/tmp/prop-base
locate-sources/Locate/hlp/Images/.svn/tmp/props
locate-sources/Locate/hlp/Images/.svn/tmp/text-base
locate-sources/Locate/hlp/Images/Bullet.gif
locate-sources/Locate/hlp/issue_commandlinearguments.src
locate-sources/Locate/hlp/issue_datasearch.src
locate-sources/Locate/hlp/issue_searchterms.src
locate-sources/Locate/hlp/Locate32.chm
locate-sources/Locate/hlp/Locate32.chw
locate-sources/Locate/hlp/Locate32.hhc
locate-sources/Locate/hlp/Locate32.hhk
locate-sources/Locate/hlp/Locate32.hhp
locate-sources/Locate/hlp/main_index.src
locate-sources/Locate/hlp/menu_contextmenu.src
locate-sources/Locate/hlp/menu_edit.src
locate-sources/Locate/hlp/menu_file.src
locate-sources/Locate/hlp/menu_help.src
locate-sources/Locate/hlp/menu_options.src
locate-sources/Locate/hlp/menu_special.src
locate-sources/Locate/hlp/menu_systemtray.src
locate-sources/Locate/hlp/menu_view.src
locate-sources/Locate/hlp/page_raw.htm
locate-sources/Locate/hlp/settings_advanced.src
locate-sources/Locate/hlp/settings_autoupdate.src
locate-sources/Locate/hlp/settings_autoupdatedlg.src
locate-sources/Locate/hlp/settings_databasedlg.src
locate-sources/Locate/hlp/settings_databases.src
locate-sources/Locate/hlp/settings_general.src
locate-sources/Locate/hlp/settings_languages.src
locate-sources/Locate/hlp/settings_shortcuts.src
locate-sources/Locate/hlp/settings_shortcutsadvanced.src
locate-sources/Locate/hlp/src.rules
locate-sources/Locate/hlp/styles.css
locate-sources/Locate/hlp/tab_advanced.src
locate-sources/Locate/hlp/tab_name.src
locate-sources/Locate/hlp/tab_sizedate.src
locate-sources/Locate/ImageHandler
locate-sources/Locate/ImageHandler/ImageHandler.cpp
locate-sources/Locate/ImageHandler/ImageHandler.h
locate-sources/Locate/ImageHandler/ImageHandler.rc
locate-sources/Locate/ImageHandler/ImageHandler.vcproj
locate-sources/Locate/ImageHandler/ImageHandler.vcproj.JMJ.jmhuttun.user
locate-sources/Locate/ImageHandler/resource.h
locate-sources/Locate/keyhook
locate-sources/Locate/keyhook/keyhelper.h
locate-sources/Locate/keyhook/keyhook.cpp
locate-sources/Locate/keyhook/keyhook.rc
locate-sources/Locate/keyhook/keyhook.vcproj
locate-sources/Locate/keyhook/resource.h
locate-sources/Locate/lan_resources.h
locate-sources/Locate/languages
locate-sources/Locate/languages/lan_base
locate-sources/Locate/languages/lan_base/helptext.txt
locate-sources/Locate/languages/lan_base/lan_base.cpp
locate-sources/Locate/languages/lan_base/lan_base.vcproj
locate-sources/Locate/languages/lan_base/lan_base_mod.cpp
locate-sources/Locate/languages/lan_base/lan_base_mod.lrf
locate-sources/Locate/languages/lan_base/lan_base_mod.rc
locate-sources/Locate/languages/lan_base/resource.h
locate-sources/Locate/languages/lan_en
locate-sources/Locate/languages/lan_en/english.lrf
locate-sources/Locate/languages/lan_en/englishrc.rc
locate-sources/Locate/languages/lan_en/helptext.txt
locate-sources/Locate/languages/lan_en/helptext2.txt
locate-sources/Locate/languages/lan_en/lan_en.vcproj
locate-sources/Locate/languages/lan_en/Makefile
locate-sources/Locate/languages/lan_en/usage_loc.txt
locate-sources/Locate/languages/lan_en/usage_updt.txt
locate-sources/Locate/locate
locate-sources/Locate/locate.sln
locate-sources/Locate/locate.suo
locate-sources/Locate/locate/Locate.cpp
locate-sources/Locate/locate/locate.ico
locate-sources/Locate/locate/locate.rc
locate-sources/Locate/locate/locate.vcproj
locate-sources/Locate/locate/rsc.h
locate-sources/Locate/Locate32
locate-sources/Locate/Locate32/3rdparty
locate-sources/Locate/Locate32/3rdparty/CpuUsage.cpp
locate-sources/Locate/Locate32/3rdparty/CpuUsage.h
locate-sources/Locate/Locate32/AboutDlg.cpp
locate-sources/Locate/Locate32/AboutDlg.h
locate-sources/Locate/Locate32/Background.cpp
locate-sources/Locate/Locate32/Background.h
locate-sources/Locate/Locate32/commonres
locate-sources/Locate/Locate32/commonres.h
locate-sources/Locate/Locate32/commonres.rc
locate-sources/Locate/Locate32/commonres/aboutbanner.bmp
locate-sources/Locate/Locate32/commonres/advancedsettingsbitmap.bmp
locate-sources/Locate/Locate32/commonres/circle.bmp
locate-sources/Locate/Locate32/commonres/dbfile.ico
locate-sources/Locate/Locate32/commonres/defaultshortcuts.dat
locate-sources/Locate/Locate32/commonres/deftypei.bmp
locate-sources/Locate/Locate32/commonres/deletedf.ico
locate-sources/Locate/Locate32/commonres/file.ico
locate-sources/Locate/Locate32/commonres/files.ico
locate-sources/Locate/Locate32/commonres/icon5.ico
locate-sources/Locate/Locate32/commonres/icon6.ico
locate-sources/Locate/Locate32/commonres/idb_lani.ico
locate-sources/Locate/Locate32/commonres/invalidf.ico
locate-sources/Locate/Locate32/commonres/keybitd.bmp
locate-sources/Locate/Locate32/commonres/keybith.bmp
locate-sources/Locate/Locate32/commonres/keybitn.bmp
locate-sources/Locate/Locate32/commonres/lanim1.ico
locate-sources/Locate/Locate32/commonres/lanim2.ico
locate-sources/Locate/Locate32/commonres/lanim3.ico
locate-sources/Locate/Locate32/commonres/lanim4.ico
locate-sources/Locate/Locate32/commonres/lanim5.ico
locate-sources/Locate/Locate32/commonres/lanim6.ico
locate-sources/Locate/Locate32/commonres/lens.ico
locate-sources/Locate/Locate32/commonres/locate32.ico
locate-sources/Locate/Locate32/commonres/manifest
locate-sources/Locate/Locate32/commonres/no.ico
locate-sources/Locate/Locate32/commonres/sresbitd.bmp
locate-sources/Locate/Locate32/commonres/sresbith.bmp
locate-sources/Locate/Locate32/commonres/sresbitn.bmp
locate-sources/Locate/Locate32/commonres/Thumbs.db
locate-sources/Locate/Locate32/commonres/toolbitd.bmp
locate-sources/Locate/Locate32/commonres/toolbith.bmp
locate-sources/Locate/Locate32/commonres/toolbitn.bmp
locate-sources/Locate/Locate32/commonres/uanim1.ico
locate-sources/Locate/Locate32/commonres/uanim10.ico
locate-sources/Locate/Locate32/commonres/uanim11.ico
locate-sources/Locate/Locate32/commonres/uanim12.ico
locate-sources/Locate/Locate32/commonres/uanim13.ico
locate-sources/Locate/Locate32/commonres/uanim2.ico
locate-sources/Locate/Locate32/commonres/uanim3.ico
locate-sources/Locate/Locate32/commonres/uanim4.ico
locate-sources/Locate/Locate32/commonres/uanim5.ico
locate-sources/Locate/Locate32/commonres/uanim6.ico
locate-sources/Locate/Locate32/commonres/uanim7.ico
locate-sources/Locate/Locate32/commonres/uanim8.ico
locate-sources/Locate/Locate32/commonres/uanim9.ico
locate-sources/Locate/Locate32/commonres/updtdb32-new.ico
locate-sources/Locate/Locate32/commonres/updtdb32.ico
locate-sources/Locate/Locate32/commonres/yes.ico
locate-sources/Locate/Locate32/Data.cpp
locate-sources/Locate/Locate32/Data.h
locate-sources/Locate/Locate32/DatabaseInfos.cpp
locate-sources/Locate/Locate32/DatabaseInfos.h
locate-sources/Locate/Locate32/Debugging.h
locate-sources/Locate/Locate32/FileObject.cpp
locate-sources/Locate/Locate32/FileObject.h
locate-sources/Locate/Locate32/icons
locate-sources/Locate/Locate32/icons/256color-large.psd
locate-sources/Locate/Locate32/icons/256color-medium.psd
locate-sources/Locate/Locate32/icons/256color-small.psd
locate-sources/Locate/Locate32/icons/hicolor-large.psd
locate-sources/Locate/Locate32/icons/hicolor-medium.psd
locate-sources/Locate/Locate32/icons/hicolor-small.psd
locate-sources/Locate/Locate32/Locate32.dev
locate-sources/Locate/Locate32/Locate32.h
locate-sources/Locate/Locate32/Locate32.vcproj
locate-sources/Locate/Locate32/LocateApp.cpp
locate-sources/Locate/Locate32/LocateApp.h
locate-sources/Locate/Locate32/LocatedItem.cpp
locate-sources/Locate/Locate32/LocatedItem.h
locate-sources/Locate/Locate32/LocatedItem.inl
locate-sources/Locate/Locate32/LocateDlg.cpp
locate-sources/Locate/Locate32/LocateDlg.h
locate-sources/Locate/Locate32/LocateDlg.inl
locate-sources/Locate/Locate32/lres_base.rc
locate-sources/Locate/Locate32/messages.h
locate-sources/Locate/Locate32/misc.cpp
locate-sources/Locate/Locate32/misc.h
locate-sources/Locate/Locate32/ResultsDialogs.cpp
locate-sources/Locate/Locate32/ResultsDialogs.h
locate-sources/Locate/Locate32/SettingsDlg.cpp
locate-sources/Locate/Locate32/SettingsDlg.h
locate-sources/Locate/Locate32/SettingsDlg.inl
locate-sources/Locate/Locate32/shortcut.cpp
locate-sources/Locate/Locate32/shortcut.h
locate-sources/Locate/Locate32/shortcuts.inl
locate-sources/Locate/Locate32/SmallDialogs.cpp
locate-sources/Locate/Locate32/SmallDialogs.h
locate-sources/Locate/Locate32/SmallDialogs.inl
locate-sources/Locate/Locate32/Std.cpp
locate-sources/Locate/LocateDB
locate-sources/Locate/LocateDB/Database.cpp
locate-sources/Locate/LocateDB/Database.h
locate-sources/Locate/LocateDB/DatabaseInfo.cpp
locate-sources/Locate/LocateDB/DatabaseInfo.h
locate-sources/Locate/LocateDB/DatabaseModifier.cpp
locate-sources/Locate/LocateDB/DatabaseModifier.h
locate-sources/Locate/LocateDB/DatabaseUpdater.cpp
locate-sources/Locate/LocateDB/DatabaseUpdater.h
locate-sources/Locate/LocateDB/DBReference.txt
locate-sources/Locate/LocateDB/Definitions.h
locate-sources/Locate/LocateDB/dtype.h
locate-sources/Locate/LocateDB/dtype.s
locate-sources/Locate/LocateDB/LocateDB.h
locate-sources/Locate/LocateDB/locatedb.vcproj
locate-sources/Locate/LocateDB/Std.cpp
locate-sources/Locate/Locater
locate-sources/Locate/Locater/Locater.cpp
locate-sources/Locate/Locater/Locater.h
locate-sources/Locate/Locater/Locater.inl
locate-sources/Locate/Locater/locater.vcproj
locate-sources/Locate/Locater/Std.cpp
locate-sources/Locate/SettingsTool
locate-sources/Locate/SettingsTool/Resource.h
locate-sources/Locate/SettingsTool/SettingsTool.cpp
locate-sources/Locate/SettingsTool/SettingsTool.ico
locate-sources/Locate/SettingsTool/SettingsTool.rc
locate-sources/Locate/SettingsTool/SettingsTool.vcproj
locate-sources/Locate/updatedb
locate-sources/Locate/updatedb/resource.h
locate-sources/Locate/updatedb/UpdateDB.cpp
locate-sources/Locate/updatedb/updatedb.vcproj
locate-sources/Locate/updatedb/updtdb32.ico
locate-sources/Locate/updatedb/Updtdb32.rc
locate-sources/readme.txt

• There are 423 items in this monster.
• Together these 423 items suck up 23,130,099 bytes in direct disk storage.
• Together these 423 items suck up over 23 megabloats in actual disk storage.

Suck it up.

The HFC library - whatever that is - seems to be written by one Janne Huttunen originally from the University of Kuopio, a beautiful town in eastern Finland. Huttunen is now working at UC Berkeley but most importantly he's a physicist and not a computer engineer. This isn't to say his code is incorrect - only that it might just might not be the most efficiently written program code ever. The HFC library is further written in C++, a sure sign of bloat.

One of the first things one notices is how resources are duplicated: there are five virtually identical application icons in different places where (obviously) one would have done nicely, thank you.

Locate - with its HFC library - can obviously search inside compressed archives. Which is admittedly cool. And which places Locate32 in a different class from Everything (Something) right away.

The source also contains an inordinate number of 'inline libraries' - C++ inline functions meant to speed up the kludge known as 'Bjarne's greatest effort'. There's even an egregious file called 'Windows.inl'. It's got 1739 lines of code. Each of these clumsy C++ inline functions might give Bjarne a swift kick and speed him up but it's going to make things bulky bulky bulky.

The application is a straightforward 'MFC' build - which is about as far as laypersons ever get on Windows anyway. MFC application development has been consistently shunned inside the confinements of the Redmond campus because of the concomitant bloat and memory leaks. It was only used in two standard Microsoft applications. It's rather pathetic.

The source code also shows Huttunen's understanding of his programming languages is a bit wobbly at best. He's not a programming engineer, doesn't pretend to be one, yet has produced an application that ostensibly (hopefully) works and he's been generous enough to donate the source code. And that must be worth something.

The application does a lot of stuff that would be illegal on other more secure systems. Things like SetWindowsHookEx() are just downright scary. Huttunen is namely installing a keystroke logger - a benign logger but still and all a logger. (And this can be a lesson to all lusers out there: writing and installing a keystroke logger on Windows isn't exactly rocket science requiring Olympic-level system privileges either.)

One sees by looking through several files that Locate32's latest version - 3.0 build 7.7010 - was last updated two years ago.

/* Copyright (c) 1997-2007 Janne Huttunen
   locate.exe v3.0.7.7010                 */

The main source file for the background logic is a paltry 1019 lines of code. But by proper formatting would lose quite a lot of that. There's a lot of good code in here - it's just not written particularly well.

Going into the directory for the code for the graphical part of the source one finally encounters the monster. This directory alone contains 47,417 lines of code for 1,306,423 bytes. Again one wonders: what kind of federal budget can turn a simple application domain into something Steven McQueen will have to freeze to neutralise?

The four programs of the XPT X-file Suite file management system take 40.5 KB on disk. That's 'tiny'.

The biggest file is 'LocateDlg.cpp'. A lot of the bulk here is pure sloppiness however - and sloppiness in source code doesn't result in bloat in executables. There are 13,121 lines of code - a significant chunk when you consider Microsoft's original File Manager for Windows 3.0 was only 13,500 lines of code and the first released version of the entire Unix operating system was only 13,500 lines of code. But again: the engineers who created Winfile were rather clever and the gents and ladies at Bell Labs are the best in the business.

Yet removing all the 'white space fetish' in the file reduces the number of lines to 12759 - meaning there were 362 empty lines that weren't needed.

And the actual number of lines needed in the file would be far fewer if kindergarten constructs such as the following were cleaned up.

    }
    else
    {

That's three lines of code. For a manager who counts KLOCs that can be impressive. But it's grossly unreadable and should only be one line.

    } else {

• There are 325 instances of wasting a line of code in conditional statements.
• There are 44 instances of wasting three lines of code for a single-line 'else' token.
• There are 18 further instances of wasting two lines of code for a single-line 'else' token.

And so forth. But this again does not explain the bloat on disk for the application. Even the 'icons' directory with Photoshop files basically reproducing the application icon we already have in quintuplicate doesn't explain it.

At the end of the day the explanation is a lay person - a hardworking academic but still and all a layperson - used an environment shunned even by the vendor and built a combat helicopter where a frisbee would have been sufficient and most likely more powerful. It's not the abundance of code that hallmarks good programming - it's the scarcity of it. Small is beautiful. Overworked, overly busy is not.

8. DisplayFusion or UltraMon

Forget this functionality is all over the supposedly inferior open source world where it's been available for years. Forget as well you get it for free and already installed when you purchase a computer from Apple. Let's just focus on the glee Windows lusers must feel when they too can do some of the same things their brighter brethren on other platforms have accomplished without blinking for years.

'These apps have a relatively small system footprint', writes the exuberant Lifehacker. You'll see shortly how relative that word 'relatively' can become.

UltraMon comes as a 2.9 MB (3,033,600 bytes) MSI installer - and if you know what MSI is then you've got goose bumps already. And all this for virtual screens?

DisplayFusion (which also subs as a desktop wallpaper woo-hoo) is a bit leaner. It's also $20 if you want it to really run. The self-extracting ZIP is 505 KB (516,840 bytes) and the ordinary ZIP is 455 KB (465,567 bytes). The unarchived package results in 108 KB of language files for English, French, German and Spanish as well as the main T-Rex at 806,064 bytes - and all you're doing is making virtual screens and maybe doubling as a desktop wallpaper?

Fantastic.

7. Texter

Written by Lifehacker author Adam Pash himself. Adam Pash describes himself as follows.

'Adam Pash is a freelance writer, programmer, and web developer based in Los Angeles, California. While his interests are varied, Adam spends the majority of his time working as Editor for Lifehacker, a weblog with a focus on software, the internet, and productivity.'

Uh OK... Hey - Pash's got other applications too.

• Rocker. 'Rocker is a mouse navigation tool that lets you 'rock' your mouse buttons to move forward and backward in a variety of applications - like Firefox, Internet Explorer, Windows Explorer, etc.'
• Swept Away. 'Swept Away is a simple system tray utility that automatically minimizes applications that you aren't using.'
• ClickWhen. 'ClickWhen lets you set up an automated mouse click to run on a window after a user-defined period of time.'
• Dropcloth. 'Instantly blank out your desktop and focus on your currently active app with Dropcloth.'

Wow.

The entire article may be a ruse for promoting one's own 'software'! 'Texter Installer 0.6.exe' is a shy 604,537 bytes - for a dumb simple keystroke logger. The kind malware writers fit into 2 KB with room to spare.

Texter doesn't send information to a mother ship. Hopefully not. But what it wants to do is give you the chance to type abbreviations of things instead of typing the things themselves.

Let's say you find yourself again and again typing 'talk to you soon'. And you type this not in any one application but all over the place. Thanks to the endemic insecurity of Windows (see above) you're able to quite easily hook into any running application and intercept (and perhaps store and sell) all types of user input including input from the keyboard.

If you're still interested in this app (and not frightened enough to abandon the platform it runs on by yesterday) then here's good news (sort of). The author's released the app under the GNU licence - meaning the source code is available. For perusal. As in someone can inspect it and figure out how a simple keystroke hook and substitution scheme can take a megabloat on your HDD.

But looking through the 'GIT' for Texter shows it's hardly original. Instead it's evidently based on AHK - the 'auto hot key' facility (for Windows only natch).

Nevertheless, the ZIP download of the Texter GIT is a walloping 6.1 MB (6,441,997) just to download. If this is such a great idea (and it's not - it's more scary than great) then why not get a good engineer to write it?

The leanest network utility bundle available on Windows before Spike weighed in at 350 KB - then a professional engineer looked at it and got the same application down to 13 KB.

'Tiny'? Did someone at Lifehacker say 'tiny'?

Texter comes with the file 'autocorrect.txt' which has an anarchistic key-value structure - no XML tags, just alternating lines - for common spelling errors. Of course it would be easier if the operating system itself had such functionality - and systems like Apple's Mac OS X come with this functionality built-in - but that's just pipe-dreaming on Windows.

It also comes with two sound files: 'oldreplace.wav' and 'replace.wav'. They're audio genius to say the least. Nothing like getting special effects like this when you're typing abbreviations at your Windows keyboard!

Texter also comes with an 'AHK' module called 'autocorrect.ahk' which weighs in at 106,634 bytes. And it's all text - it's interpretive code. So unless there's an AHK compiler out there then this thing is going to be about as fast as a snail sprinting on prosthetics. And about as efficient too.

6,419,967 bytes on disk. For an application that can't compile. Yeah that's 'tiny' alright.

6. Revo Uninstaller

'In a magical world without computer stress, we're all running virtual machines to try out software we might not want, and we simply uninstall it there, keeping one system nearly pristine. For the real world, Revo Uninstaller scrubs an application and all its traces off your Windows system. It can also turn off programs that are starting up with Windows.'

Wow. Sounds great. Of course half (or all of) the complete problem is the fact today's Windows bloatware is so poorly written it has to be 'installed' in the first place. When was the last time you just double-clicked a download and it ran? So wander over to keir.net and you will find nothing but. The author Robin Keir even got puzzled queries from users who couldn't understand what do to - they had to be told they're supposed to just double-click the things.

But more about this later on.

One would normally assume uninstalls can be handled by that most agile of Windows functions known as 'Add/Remove Programs'. But heck - here's a 'tiny' app that takes only 5 MB of disk space!!1! (Are these vendors paying for being listed at Lifehacker? One starts to wonder.)

Although perhaps beginning its existence as yet another uninstaller Revo's gem has now gone further.

• It manages your autostart apps. (Gee whiz but you can do this already.)
• Easy access to tools already on your Windows system. (Hello?)
• Junk files cleaner. (A script can't do this? Or something like this for perhaps 1/100th the disk space?
• Browsers history cleaner. Oh please. Otherwise: see directly above. This is ridiculous.
• Office history cleaner. Adding injury to insult to injury. See above again. The nerve moreover to list all these as separate 'tools' is otherwise unparalleled.
• Windows history cleaner. Ditto.
• Unrecoverable delete tool. In other words - and only in the best of all possible cases - the same as this which takes only 7.5 KB on disk.
  
• Evidence remover. In other words a new 'Evidence Eliminator'. One shudders.

There's not much mention of what the program does above and beyond 'Add/Remove Programs' other than that it can sometimes succeed where the latter fails. As regards all these supposed 'features': they're mostly part and parcel of the same thing: removing junk files, browser history, Office history, and Windows history is all a matter of a simple script such as used by this powerhouse which can go a lot further, be customised any way you want, and takes something like 80 KB on disk all told. And again: this isn't a sales pitch: it's again a comparison, a statement that 'tiny' is not as defined by the amateur tech tinkerers at Lifehacker.

Revo Uninstaller does have one great advantage however: it's free. So are batch files for that matter. But to paraphrase Linus Torvalds: free isn't really important but good engineering is.

5. NirSoft's password recovery tools

'My name is Nir Sofer, and I'm experienced developer with extensive knowledge in C++, .NET Framework, Windows API...'

Yeah C++ is good to know. Too right. Hey and so is .NET. Unless you've already figured out only lusers stay on the platform. As for proficiency in the 'Windows API' - no. Curiously the NirSoft website came into being after principal work at Radsoft was completed. Not that much has happened since then. Only that programs got bigger and bigger to do less and less.

Nir Sofer seems to write a lot of software as the Lifehacker article points out, most of which seems to copy the pattern (and programs) of Radsoft, Keir Software, and System Internals ten years ago. But inspecting a few downloads it's obvious the author can't reach the same class. The stuff isn't bad - it's just not 'top of the line' either. And most crucially: it's all been done before. A long time ago. And better.

Sofer's HeapMemView looks at process memory. Great. But so does Memview. But despite it being written by a more professional engineer than yet seen on Lifehacker's 'Top 10' HeapMemView still wants 34 KB on disk (compressed with UPX) where Memview weighs in at 7.5 KB - or less than 1/4 the size - and looks better and does more. And Memview integrates with both X-perf and X-tool so there's communication going on all over the place. And X-perf takes 9 KB on disk; X-tool takes 9.5 KB. All three together are still less than the size of a single 'Sofer'.

But NirSoft conveys the idea at least (at last). There are programs that do hardly anything and take megabloats of disk space and get kudos from the 'tech tinkerers' at Lifehacker and then there are programs that do a lot and take hardly any disk space at all. Getting a clue? Could that clinking sound be coins falling down into dusty rusty slots?

Sofer's got other stuff such as DLL Export Viewer. 37376 bytes on disk and it has a big window. But this app looks at DLL exports too - and image sizes, file alignments, bindings, data directories, debug info, dependencies, incremental linking, runtime rebasing conflicts, sections, strings, uninitialised data, and unoptimised code. And coolest of all: it lets you double-click your way through the dependencies and backtrack again so you can follow full DLL chains.

And it takes 10.5 KB on disk. For all that. And it's only one of several apps that do it. In fact the whole Radsoft effort to publicise the XPT came about as response to a particularly shoddy rip-off app that did something just like DLL Export Viewer.

Sofer has some password cracking tools too. So does open source. In abundance. But Sofer gets a 'C++' for effort.

4. CCleaner

How do people find all this junk? 'This tiny, powerful little app' begins the Lifehacker author again. We've just seen entire process managers for (at the most) 34 KB. Can they match that?

Uh no. Ouch. This piece of blubber will set you back 3.2 MB - and that's just the download.

Take a step back. To Nir Sofer. Nir Sofer was offering, as Radsoft have offered for fourteen years, extremely powerful apps in the 'kilobyte' size range. Then suddenly we're back to Lifehacker reality again and this time describe the app as 'tiny, powerful little' app. Note the use of two synonyms to describe the nonexistent size of this innocent babe. Soon enough you'll believe just as the author that anything that fits on a DVD or in the mouth of Moby Dick is 'tiny'.

What's it do? Oh so much. Cleans up after your browser. Gets into your Recycle Bin. Removes temporary files. Cleans your Registry. Gets at 'unnecessary application left-behinds' (dontcha love the US version of English). And talk about hyperbole: 'cleaning them out and in some cases freeing up at least a DivX movie's worth of space'. One should in such a circumstance remind oneself that the author is either shilling for this product or speaking from personal experience. And anyone on any platform that can sloppily leave junk files for 'a DivX movie's worth of space' on a computer no matter platform has got to count as one of the biggest lusers ever.

3. Process Explorer

A tool by Sysinternal's Mark R. Once again we visit the realm of the professional. Mark is no longer independent of course: he sold out to Microsoft a few years ago after championing the critical user's cause for so many years. But the app should still be good - and yes it will be in the kilobyte range. Curious how this strange type of software should again creep into an otherwise consistent list!

But there's something painful even here: the Lifehacker promises too much when he claims the app is good for 'freeing up system memory' - and even links through to another article he's also written that takes a dangerous turn on an issue that was resolved long ago.

2. Replacements for built-in Windows utilities

A reference to another Lifehacker article (by another author - Gina Trapani). Here are a few of the 'tiny' gems in this category - runners-up evidently to the greatest and tiniest of them all.

• Notepad++. A real anorexic. The Bloatbusters™ covered this years ago. People might like it but it's not 'tiny' - it's a bloat monster.
• Xplorer2. To replace Windows Explorer. 6.0 megabloats tiny. As compared to this app which still wipes its nose in the gravel and weighs in at only 13.5 KB on disk (and yes you read that right).

And so forth. The complete list is too painful to go through. But now it's time for the king of them all.

1. Rainlendar

This is so ridiculous as to leave software engineers and conscionable users speechless. But there you have it. It's a calendar. And it's 4.4 MB.

Causes

So what causes such a lack of proportions? Good question. Things haven't always been like this.

'One of the chief hallmarks of early UNIX was how simple, compact programs worked well together', wrote an author from this site over ten years ago at the RISKS Digest, citing a particularly obscene example from Microsoft themselves known as 'RegClean'.

The response was enormous at the time and a few links remain online. One of the responses came from the Borg itself, prompting the author to follow up the claim with a blow-by-blow dissection of the app in question. The article was later cited by Phrack magazine as 'the ultimate hack'.

This was followed up in October 1999 with an article about Explorer - and ways to get around it. At the same time and in the same article X-file was announced for the Windows platform.

Daily Telegraph reporter Mark Ward who'd grown increasingly tired of the whinging of the bloat advocates contacted Radsoft and spread the news they'd soon have an 'Explorer killer' not at a quarter of a megabloat but at 26 KB or smaller. Others such as Charles Mann of the MIT Technology Review soon followed suit. Bloatware was on the run.

Then came the infamous Bloatbusters™ - and for those who had a clue it meant tears of joy whilst for the clueless it was but bewilderment. Still it could be said bloatware was finally on the run. Ordinary users wrote and told stories of how they'd figured out the same things themselves - and shared the obscure theory that the smaller the download the greater the likelihood there could be quality under the bonnet.

But by the following year bloat took a back seat and was ultimately forgotten. For Windows was all of a sudden exposed as the defenceless naked standalone system it had always been. The 'ILOVEYOU' Love Bug hit on 5 May 2000 and forever changed the topology of online computing. Nine years later and the Windows lusers still don't get it - nine years later and Microsoft are still promising the 'next system' will finally be virus-free. As if anyone cares anymore.

Bloat According to Wikipedia

Wikipedia, that beacon of light in the dark wilderness of illiteracy, covers bloat. But in the apologist way they go about things they've more or less reduced the irksome phenomenon to something out of a time warp and completely exonerated the sloppy or unqualified programmer. 'It was all because there were OMG!!1! constraints once upon a time', the moron writing the piece seems to be saying. 'Programmers had to go out of their way to fit all the code in.' But it's never been about that at all.

All the Wikipedia article does - quite typically - is misinform a public interested in knowing the truth.

Windows might never have been the best of breed system Windows lusers somehow think it is but as long as it was still unconnected it was 'almost good'. Windows architecture was however notoriously complex and many were the software houses that simply gave up at the prospect of writing 'hot wired' applications, reverting to higher level (and extraordinarily bloated) environments such a Visual Basic and Delphi. Just as a matter of comparison:

• A skeleton application for Windows 3.1, if coded correctly, was about 2.5 KB on disk.
• A skeleton application for 32-bit Windows NT, if coded correctly, was about 4-5 KB on disk.
• A skeleton application written in C++ with Microsoft's MFC for Windows 3.1, if coded correctly, was 50 KB on disk or twenty times the size of the same program written in C.
• A skeleton Delphi application for Windows - and who cares how it was coded - was about 350 KB. That obscene 350 KB did nothing - the application simply launched and exited and still it took 350 KB of who-knows-what to do it. This was 160 times the size of the same program written in C. And yet it did no more.

By 1992 Microsoft had the success of Windows 3.1 but precious little else. Their two main clouds were they were getting pushed out of the developer space and the database space and in both cases it was the same company giving them misery: Borland.

Borland had crept into the developer space by walkover. Microsoft's own developer tools had over the years eroded so drastically that the Redmond corporation had to licence someone else's compiler to build Windows 3.1 - and yet they still marketed their own compiler, generally esteemed to be completely worthless. Borland, the company with 'layperson' 'Turbo' tools for $99 a pop, moved into the professional space with Borland C.

And quite the environment it was. Borland's compiler wasn't the most efficient going - but the environment was very easy to work with (and was mostly 'visual'). Had Borland just stuck to the same product model then Microsoft would have never caught up. But someone at Borland had a bad idea and got everyone else behind it and down Borland went.

The six windows of the XPT process management system returned to default alignment. The application takes 9.5 KB on disk. That's 'tiny'.

The next version of Borland C was to wait a long time - much too long, and past several postponed release dates. And when the product finally arrived it was a total bomb: the class system was completely reorganised so nothing that was already built worked anymore. Developers had to start from scratch and rewrite their code. This was not very popular to say the least.

And now it was Microsoft who crept in the slot emptied by default by the clumsy Borland. Using bits and pieces from other applications (some of which were purchased in typical Microsoft fashion) Microsoft suddenly introduced a rather ramshackle 'visual' development environment of their own dubbed 'Visual C'. It wasn't much to look at; it was definitely inferior to the old Borland IDE in that department; and the 'class system' was thrown together with the greatest of haste - and not surprisingly shunned by Microsoft developers ever since.

But it did do one thing right: it produced more compact executables. And this alone - together with the 'hard sell' of the 'Scott Randell Traveling Road Show' - meant droves of Borland users migrated back to Mamma Microsoft again.

A common modus operandi was to keep the old Borland on board and use it for development; then when ready for release build the whole thing again with Microsoft's tools and save a few kilobloats.

Borland were so taken back - and shocked - by this subtle victory by Microsoft that they produced what must be rated as one of the most ridiculous white papers ever published: a 70 page document that tried to argue Borland's executables were smaller than Microsoft's even though they weren't. The desperation was so tangible one could sense the cold sweat on the Borlanders.

This and the abortion of their new version of their IDE - originally touted as 'capable of doing things people haven't even dreamt of yet' - signaled their downfall. And yet again Microsoft won. And the default IDE for Windows became Visual Studio.

Olé!

Microsoft had clipboard tricks early on. They even copied Apple's Ctrl-X, Ctrl-C, and Ctrl-V keyboard shortcuts. From there they moved towards automating the clipboard process - something that gained the moniker Dynamic Data Exchange (DDE). They built up an API for this facility which developers unfortunately felt was too difficult to use; their response was to then build the Dynamic Data Exchange Management Library (DDEML). But the irony was this new API proved even more difficult.

And by the time Windows 3.1 was ready they had a new thing: Object Linking and Embedding (OLE). OLE ran atop DDE for Windows 3.1. It made it possible to paste a spreadsheet grid into a word processing document or the other way around. It made it possible to embed graphics in both word processing and spreadsheet documents. And so forth. It also enabled 'linking' in things from other files - either entire files (of possibly an alien type) or a portion thereof. So if the external file changed the container document would notice it.

Great stuff. Not all that relevant anymore in the era of the web but still and all.

Then Microsoft's OLE team went one step further. 'If we can embed MS Paint pics in Excel and Word documents then why can't we offer client applications any type of service at all?' Why not indeed? Microsoft programming veteran Kraig Brockschmidt (the Windows calculator) was called in to captain the effort despite his inability to program in C++ (and ostensibly his aversion to it as well). Kraig wrote the seminal tome on the new effort, Inside OLE 2, which begins with the now-famous nonsense sentence:

This is a book about fish.

What were Microsoft's OLE team after?

Behind/underneath OLE and all the rest of that gunk there was supposed to be something called 'COM' - Component Object Model. COM is based loosely on CORBA - Common Object Request Broker Architecture. CORBA is, as its name suggests, a standard program modules can use to communicate with one another at runtime. So is Microsoft's COM. The trick is Microsoft's COM is based on an old architecture predating Unix and is desperately dependent on the Windows Registry.

Back before the days of Unix there really was no widespread concept of 'small programs working well together', command line 'pipes', and the like. Modules would 'register' their services and potential 'clients' would query the system for available services. And the system would hopefully be able to connect the one with the other.

OLE 2 really took off with the release of Windows 95 (originally Windows 94 but as many pundits predicted Microsoft ended up being a year late and so the name had to be changeds).

Within a short time one began seeing 'installers' for what used to be simple straight forward 'just double-click the muthah' applications. Applications suddenly had to be 'installed' because they were - no matter their abysmal simplicity - always divided up into myriad (unnecessary) components, each of which had to be 'registered' with the Registry for the whole thing to work.

Robin Keir's WotWeb port scanner. The application takes 22.5 KB on disk. That's 'tiny'.

One of the all-time gems from this era was FuelCDP. It's perfectly alright to tinker at programming, even if one will always remain a 'tinkerer' and no more; but donning delusions of grandeur when one is fortunate to even get a working app out the door that ostensibly does nothing new - no it's definitely not time for a release party. FuelCDP is no more. And that's probably good. But it remains a perfect textbook example of 'COM gone wrong'.

The catastrophe of 'COM bloat' isn't only the crappy way people use crappier and crappier IDEs to write crappier and crappier software - it's also the fact that this best forgotten architecture places an inordinate strain on a system.

Keeping all the Registry keys connected and coordinated is actually a gargantuan effort. Remember seeing an alert message that removal of a key or file might 'impact' one or more programs? How can the system know that? Yes you might remember such a relationship - but how can the system actually know it?

The system can know it because the system takes various parts of the Registry at boot time, loads them into memory, then creates vectors that lead backwards from the destinations to the sources. It's possible, for example, to query the Registry point blank what icon is used for files with the extension 'TXT'. And find out the application to open them as well.

The system navigates down from the HKCR key until it finds '.txt'. That's the extension; now it needs the file type. The file type is listed as the default value for the .txt key. It's usually 'txtfile'. So now the system starts at the top again, this time looking for a key under HKCR called 'txtfile' instead. Whoa, there it is. Descending a bit further at this branch one finds both the app to open 'txtfiles' and the icon to use for their display.

But how about the other way around? Supposing the system has to be able to reverse this process at a moment's notice (which the system in fact does). How is that done? One thing's for sure - it takes a lot of crunching.

Nobody cares about 'bare metal programming' on Windows anymore. Few have ever mastered it. Even in Redmond there are few adepts remaining. It's a lost art in a way and it's a crying shame in another. For achieving bare metal on Windows is a feat to be proud of. It's just that nobody gives a shit anymore now that Windows is connected to the Internet.

So who wrote that Lifehacker article anyway? An engineer who regularly writes for RISKS? For Dr Dobbs? For the CACM?

Kevin Purdy is that most typical of techie journalists online - a journalist. Despite the fact programming is increasingly a commonplace wannabe art your 'Purdman' isn't even a wannabe - unless he's hiding his software portfolio. No, Purdy is an associate editor at Lifehacker, writes as well for the Buffalo News and other publications, and himself calls himself 'an amateur tech tinkerer'.

And despite his almost obscenely exaggerated (and definitely whored) adulation for Windows Purdy claims he has a serious crush on Linux.

But Purdy's a user. And he certainly has a right to tell people what he finds to be useful. And if your tastes in software run parallel with his then fine. But if you're looking for a qualified definition of 'tiny' software then you're definitely not looking in the right place.

OTOH if you want to know what sunblock to use this summer then Kevin Purdy's definitely your man.

Kevin Purdy, associate editor at Lifehacker, likes his Windows like he likes his kitchen - fast-moving and simple.