|Home » Rants
Re: The Bloatware Debate
Week of 30 April 1999
First published in the RISKS Digest.
One of the chief hallmarks of early UNIX was how simple, compact programs worked well together. Brian W. Kernighan's definition of a good program was a program so good and so consistent that it could be used for an entirely different purpose and be expected to work well. UNIX, they said, was a way of thinking more than an operating system. And, with Brian's Software Tools series, it was surely so.
Microsoft Windows is also a way of thinking - or not thinking, to be more exact. In almost every possible sense it is the anathema of the programming community, if that community still abides by and adheres to the solid thinking delineated by Brian so many years ago.
MS Windows programming is considered too difficult to attempt head on. Where we come from most major corporations, financial institutions and the like promised a smooth transition from UNIX or DOS to Windows 3.1x within a matter of weeks. Management talking of course. When they found this would not work they decided to invest heavily in 16-bit Visual Basic applications. Operative word 'heavily'. These bloatware masters sunk almost any machine made. Clearly this was not the answer either.
People looked to Kahn. Borland, with its Turbo C, saw the opening and released Borland C, and shortly thereafter Scott Randell who a year earlier had toured with MSC 7.0 (which admittedly never worked) was out rocking again, this time with Visual C++. The environment was unbelievable; the executables were extremely bloated; but still and all it was Microsoft talking, and still and all they were smaller than the corresponding Borland images. COBOL programmers everywhere were suddenly encouraged to learn C++, develop code browsing skills, learn about preprocessors, assembly language, CodeView and subsequent debuggers, and the world entered into a tailspin.
What originally started as a rather feeble but lucky attempt to get on the OO bandwagon, the MFC soon became something you'd like to see Steve McQueen kill. Patches and work-arounds and bugs and more bugs, and bloat and more bloat. The current splash screen module is a case in point: Microsoft includes a 16-colour bitmap which weighs in at nearly 200KB for you. This bitmap can be compressed with RLE encoding to less than half that size. The idea of banging a 100KB splash bitmap in an application is still, however, sickening. Yet Microsoft gladly gives you the bitmap at 200KB, happy if you don't understand what you are doing by using it. Your application will be more sluggish than their own bloatware, and people will be less inclined to complain about what they themselves do.
Microsoft's RegClean, a popular product for fixing corruptions in the MS Windows Registry is another case in point. When this application was originally introduced I downloaded it and wondered about its size. It weighed in then at nearly a megabyte. Similar applications out there were 20KB and hardly more. What was inside this monster? I opened it and looked inside.
Remember all those stories about how surgeons in the old days just threw their rubber gloves inside the patient's stomach before sewing them back up again? Well here you had it. There were humungoid bitmaps never used. There were dozens of icons never referenced. There were tens of kilobytes of entries in the string table that had no meaning for the application whatsoever.
I honed the app down and came to the conclusion that the actual size of RegClean should be about 45KB. That as compared to its distribution size of nearly one megabyte. Clearly bloat is not only a question of adding features almost no one wants. Bloat is a condition of the mind, permeating software houses everywhere.
Clearly again the distribution of RegClean was highly irresponsible. But remember, MS Windows is not just an operating system - it is a way of thinking, or not thinking as you may have it. And it has permeated the entire industry today. Our hats off to Microsoft.
In conclusion: there are few application domains even today that require executables of over 100KB, and most ordinary tasks can be adequately managed by executables in the 20KB range. This is simply a fact.
There are no excuses. Either we think or we don't. There is no in between.