Some extracts from comp.risks regarding BLOATED software
From: risko@csl.sri.com (RISKS List Owner)
Subject: Risks Digest 20.35
Newsgroups: comp.risks
Date: 30 Apr 99 19:38:00 GMT
Organization: The Internet Gateway Service
Message-ID:
Sender: usenet
Distribution: world
Approved: risks@csl.sri.com
Lines: 606
Xref: news.rmit.EDU.AU comp.risks:1339
RISKS-LIST: Risks-Forum Digest Friday 30 April 1999 Volume 20 : Issue 35
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at
and at ftp.sri.com/risks/ .
------------------------------
Date: Fri, 30 Apr 1999 16:22:48 +0000
From: main@radsoft.net
Subject: Re: The Bloatware Debate
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-color 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.
RA Downes Radsoft Laboratories
From: risko@csl.sri.com (RISKS List Owner)
Subject: Risks Digest 20.36
Newsgroups: comp.risks
Date: 2 May 99 01:42:55 GMT
Organization: The Internet Gateway Service
Message-ID:
Sender: usenet
Distribution: world
Approved: risks@csl.sri.com
Lines: 614
Xref: news.rmit.EDU.AU comp.risks:1340
RISKS-LIST: Risks-Forum Digest Saturday 1 May 1999 Volume 20 : Issue 36
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at
and at ftp.sri.com/risks/ .
------------------------------
Date: Sat, 01 May 1999 15:19:23 +0300
From: Diomidis Spinellis
Subject: Bloatware and the Windows API
A number of contributors to previous digests have stressed the risks
associated with increasingly bloated software applications. I believe that
a part to the complexity and unreliability of many modern software
applications can be attributed to their use of the Windows Application
Programming Interface (API).
I recently wanted to read - using C code - the name of the file pointed by a
Windows shortcut: a shell-level equivalent of the Unix symbolic link. Unix
symbolic links can be read by using readlink(2) - a simple three argument
system call. The code I had to write to examine the Windows shortcut
spanned over 100 lines of C and included initialisation of the COM
(component-object model) library, checking for Unicode filenames, getting
pointers to two COM interfaces, and releasing all the associated handles at
the end. Seven of the API functions could return with an error which had to
be checked. I am sure other readers can point to other similar examples.
The architecture, interface, and functionality of the Windows API make it
difficult to master and use effectively, and contribute negatively to the
safety, robustness, and portability of the applications developed under it.
The API is structured around a large and constantly evolving set of
functions and is based on a problematic shared library implementation (the
infamous Dynamic Link Libraries - DDLs). The provided interfaces are
complicated, non-orthogonal, abuse the type system, cause name-space
pollution, and use inconsistent naming conventions. In addition, the
functionality of the interface suffers from inconsistency, incompleteness,
and inadequate documentation [1].
I foresee that problems associated with the use or misuse of the Windows
API will provide material for many future RISKS digests.
[1] Diomidis Spinellis. A critique of the Windows application programming
interface. Computer Standards & Interfaces, 20:1-8, November 1998.
http://kerkis.math.aegean.gr/~dspin/pubs/jrnl/1997-CSI-WinApi/html/win.html
Diomidis Spinellis, University of the Aegean
------------------------------
Date: Sat, 01 May 1999 06:51:36 -0700
From: Henry Baker
Subject: Re: The Bloatware Debate (Downes, RISKS-20.35)
> One of the chief hallmarks of early UNIX was how simple, compact programs
> worked well together....
The biggest productivity losses due to bloatware are IMHO the enormous
intellectual effort of the compiler people to 'optimize' bad code into good
code, and of the CPU hardware architects to make 'legacy' bad code run fast.
I would estimate that 50-70% of the size of compilers and 50-70% of the size
of CPU chips is devoted to protecting the investment in code that never
should have seen the light of day.
On another note, though, Unix itself inspired a generation of programmers to
write bad, buggy code that never bothered to check error codes, and assumed
that all input was error-free. There was a wonderful paper in the
Communications of the ACM a number of years ago about feeding 'line noise'
into various standard (and presumably well-debugged) Unix utilities and
seeing the spectacular crashes that ensued.
------------------------------
Date: Sat, 01 May 1999 07:58:09 +0000
From: main@radsoft.net
Subject: Bloatware and Nightlight Saving
While we're on the bloatware debate, let's look at some wonderful features
that have come our way via that Mecca of intellectual happiness, Redmond
Washington.
The incident below takes place soon after the Premium Release of Windows 95
and about one week before my corporation scrapped it altogether. I had 95
installed in my home and it was Saturday night and time for bed. I kicked
in the screen saver and joined my wife under the covers.
Some hours later I was wakened from a sound sleep by a commotion in the next
room. The wife did not wake, but I did, and I was curious what had cause the
noise and went in to check.
It was the computer. The monitor screen had a big message box planted on
it. The wording was something to the effect:
"Microsoft Window 95 has detected that you have now gone over to standard
time from daylight savings time and has adjusted your computer's clock
accordingly. Thank you for choosing Microsoft Windows 95."
I was impressed! When I returned to bed the wife was stirring and protesting
my being up and about. I told her "you'll never believe what that Bill Gates
did now!" and as she drifted off again to sleep I gave her the whole story.
But my sleep and mirth with Microsoft did not last long. It was exactly one
hour later that I was awakened again - and for the same reason! The
computer's clock, put back from 3 AM to 2 AM by Wonderful Windows, had again
hit 3 AM, and - you guessed it - Wonderful Windows again put it back to
standard time. At this rate Sunday would never occur!
Even though I knew better I passed it off as a fluke and went back to
bed. And both one hour later and two hours later (my time, not Microsoft's)
I was rudely disturbed by the collective alternative intelligence of
Redmond. At that point I turned the machine off, had a few moments of black
insight into how things are done and tested in that cauldron of cerebral
superiority, and decided then and there that Microsoft Windows 95 could
never be taken seriously.
RA Downes Radsoft Laboratories http://www.radsoft.net
From: risko@csl.sri.com (RISKS List Owner)
Subject: Risks Digest 20.37
Newsgroups: comp.risks
Date: 4 May 99 16:07:03 GMT
Organization: The Internet Gateway Service
Message-ID:
Sender: usenet
Distribution: world
Approved: risks@csl.sri.com
Lines: 633
Xref: news.rmit.EDU.AU comp.risks:1341
RISKS-LIST: Risks-Forum Digest Tuesday 4 May 1999 Volume 20 : Issue 37
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at
and at ftp.sri.com/risks/ .
------------------------------
Date: Sun, 02 May 1999 16:12:13 +0000
From: main@radsoft.net (RA Downes)
Subject: Re: Bloatware Debate (Downes, RISKS-20.35)
A certain "Johnny" has written to me from Microsoft because of my posting in
RISKS-20.35 about MS bloat. The tone was a thinly disguised threat. In his
opening, "Johnny" stated that the "bloat" of MS RegClean was due no doubt to
having static links. Discussing the sweeping ramifications of such a
statement is unnecessary here. The mind boggles, it is sufficient to
state. The MSVC runtime is a mere 250,000 bytes and in fact is not
statically linked anyway to MS RegClean, AFAIK [as far as I know]. MS
RegClean is an MFC app and will by default use the dynamically linked MFC
libraries. And even if its static code links were an overhead here they
would add but a small fraction of the total bloat, say 40KB at most.
For whatever reason, I decided to download the latest version of MS RegClean
from BHS again and pluck it apart. This is what I found. I have tried - and
it has been difficult - to keep subjective comments out of this report.
Current Status of RegClean Version 4.1a Build 7364.1
====================================================
Image Size (Unzipped and ready to run): 837,632 bytes (818KB)
=============================================================
(Subjective comment removed.)
Import Tables
=============
The import section in the PE header. This gives an indication of just
how (in)effective the use of Bjarne's C++ has been. In this case, the
verdict is: "pretty horrible". A walloping 7,680 bytes are used for the
names of the relocatable Win32 imports. These are the actual names of
the functions (supposedly) called. MS RegClean does not call most of
these functions - they remain because an MFC template was originally
used, most likely borrowed from another application, and it was never
"cleaned". This is corroborated by what is found among the "Windows
resources": over half a dozen standard menus, assorted graphic images,
print preview resources, etc. that have nothing to do with the
application at hand.
Resources
=========
Please understand that resources not only bloat an executable with their
own size, but with additional reference data, in other words the bloat
factor of an unused or bad resource is always somewhat larger than the
size of the bloating resource itself.
Accelerators
============
Sixteen (16) unused accelerators from an MFC template were found: Copy,
New, Open, Print, Save, Paste, "Old Undo", "Old Cut", Help, Context
Help, "Old Copy", "Old Insert", Cut, Undo, Page Up, Page Down. MS
RegClean uses only one accelerator itself, not listed here.
Bitmaps
=======
This was a particularly sorry lot. The main bloat here was a splash
screen bitmap weighing in (no RLE compression of course) at over 150KB.
Further, Ctl32 static library bitmaps were found, meaning MS RegClean is
still linking with the old Ctl32v2 static library which was obsolete
five years ago and which automatically adds another 41KB to the image
size.
Cursors
=======
Six (6) cursors were found, none of which have anything to do with this
application.
Dialogs
=======
A very messy chapter indeed. MS RegClean walks around with eighteen (18)
hidden dialogs, of which only one or at the most two are ever used. The
others are just - you took the words out of my mouth - junk. The
findings (read it and weep):
*) Eleven (11) empty dialogs with the caption "My Page" and the static
text "Todo", all identical, all empty, and of course all unused. This is
a wonder in and of itself.
*) The main "wizard" dialog actually used by the application is left
with comment fields to help the programmers reference the right controls
in their code (subjective comment removed).
*) A "RegClean Options" dialog which AFAIK is never used.
*) A "New (Resource)" dialog, probably a part of the development
process, just stuffed in the stomach at sew-up time and left there for
posterity.
*) A "Printing in Progress" dialog.
*) A "Print Preview" control bar dialog.
Icons
=====
MS RegClean has three icons, all with images of 48x48 in 256 colors (of
course). The funniest thing here is that the authors of MS RegClean have
extracted the default desktop icon from shell32.dll, which is available
at runtime as a resident resource anyway and at no image bloat overhead
at all, and included it in toto in their executable.
Menus
=====
MS RegClean has eight (8) menus, at least half of these are simply junk
left around by the MFC template. Another menu indicates that the authors
of RegClean have in fact worked from an internal Microsoft Registry tool
- rather bloated in itself it seems.
String Table(s)
===============
Actually it need only be one string table, but Microsoft itself has
never learned this. The findings here were atrocious. And you must
remember that strings stored in a string table are stored in Unicode,
which means that their bloat automatically doubles. Further, MS's way of
indexing strings in a string table means a 512 byte header block must be
created for every string grouping, and strings are grouped according to
the high 12 bits of their numerical identifiers (yes they are 16-bit
WORD identifiers). Meaning indiscriminate or random numbering of string
table entries will make an otherwise innocent application literally
explode.
347 (three hundred forty seven, yep, your video driver is not playing
tricks on you) string table entries were found in MS RegClean, including
16 identical string entries with the MS classic "Open this document" as
well as archaic MFC template toggle keys texts which are not used here
(or almost anywhere else today). Most of these strings have - of course
- nothing to do with the application at hand.
Toolbars
========
Toolbars are a funny MS way of looking at glyph bitmaps for use in
toolbar controls. MS RegClean has two - one which may be used by the
application, and one which was part of the original MFC template and
never removed.
Total Accountable Resource Bloat
================================
The total accountable (i.e. what can be directly calculated at this
stage) resource bloat of MS RegClean 4.1a Build 7364.1 is over 360,000
bytes (350KB).
Total Accountable Code Bloat
============================
Harder to estimate, but considering that most of the code is never used,
only part of an MFC template that the authors of MS RegClean lack the
wherewithal to remove, the original estimate of a total necessary image
size of 45KB for the entire application must still stand.
In Conclusion
=============
Bloat is not a technical issue, but verily a way of thinking, a "state
of mind". Its cure is a simple refusal to accept, and a well directed,
resounding "clean up your act and clean up your code!"
PS. Send feedback on RegClean to regclean@microsoft.com
RA Downes, Radsoft Laboratories http://www.radsoft.net
------------------------------
Date: Mon, 3 May 1999 16:47:29 -0500
From: Jonathan_Goldberg@mastercard.com
Subject: Re: The Bloatware Debate
People seem to be talking about this as the result of mental aberrations
common in Redmond. I think that this misses the point. Bloated software is
the predictable result of the incentives operating in the software industry.
In part, this is a perfectly rational use of resources. Code compactness,
like any other desirable engineering outcome, must be traded off against
things such as cost and time to market. As hardware gets cheaper relative
to programmer time, it is reasonable to use more hardware and less
programming effort. Microsoft's monopoly exacerbates this tendency. As
long as they can annoy people into buying their software because there is no
viable alternative (taking into account factors such as training costs,
interoperability, and the Company approved software list), Microsoft faces
the tradeoff of spending their money on compact code or your money on
hardware. It's not a hard choice.
------------------------------
Date: Mon, 03 May 1999 01:46:36 +0000
From: main@radsoft.net (RA Downes)
Subject: Re: Bloatware Debate
Bloatware is something we are very sensitized to here. The way we see it,
there is no excuse, because there is no reason.
I personally accepted Brian W. Kernighan's calculations back in the old days
about a 10% bloat with C versus assembler because the rewards were tangible
and far outweighed the bloat: you got largely (according to Steve Johnson
94%) platform independent code, saving countless man-hours of work.
But ever since the popular inception of MS Windows and furthermore MS's MFC
things have been way out of control. This is partly due to C++ and partly,
if not largely, due to MS and their MFC itself. A typical Win16 application
was 5KB, yet the same skeleton if built with the MFC back then was ten times
that size. And Bjarne's words echoed in your ear: "C++ produces no
noticeable overhead versus C." It simply was not so, and never will be so.
With time the MFC overhead has been reduced somewhat, but programmers of
today, raised on OO and C++ as opposed to what others have gone through,
are simply not taught to be conservative and minimalistic.
I received a letter yesterday from someone who had been reading the Risks
Digest, and reported on a party he had attended some years earlier. The
conversation turned inevitably toward software, and he mentioned that he
often must really tweak code to get it compact and fast. Another person at
the party, from you guessed it Redmond Washington, said that was *not* the
way things were done there; she said that if they ever ran into performance
problems, they just "threw more hardware at it."
So there are several issues involved all at once, and AFAIK the only way to
fight this, for stop it we must, is to expose it and make even ordinary end
users understand what it's all about, and perhaps by a concerted effort we
can turn back the tide.
Rick Downes, Radsoft Laboratories http://www.radsoft.net