[RRE]software bloat [forwarded from Phil Agre] (fwd)

Christopher R. Hertel crh at nts.umn.edu
Fri May 14 19:10:07 GMT 1999

Those of you who have tried to understand the inner workings of MS code 
will find this all too familiar...

Forwarded message:
> From jladwig at mango.gofast.net  Fri May 14 13:49:55 1999
> From: John Ladwig <jladwig at mango.lioness.net>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Message-ID: <14140.28749.935426.740525 at mango.gofast.net>
> Date: Fri, 14 May 1999 13:49:49 -0500 (CDT)
> To: farmer at nts.umn.edu, crh at nts.umn.edu
> Subject: [RRE]software bloat [forwarded from Phil Agre]
> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
> ------- start of forwarded message -------
> From: Phil Agre <pagre at alpha.oac.ucla.edu>
> To: "Red Rock Eater News Service" <rre at lists.gseis.ucla.edu>
> Subject: [RRE]software bloat
> Date: Fri, 14 May 1999 09:59:47 -0700 (PDT)
> [I've taken the liberty of reformatting these messages to 70 columns.
> I've also deleted the author's e-mail address at his request.]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> This message was forwarded through the Red Rock Eater News Service (RRE).
> Send any replies to the original author, listed in the From: field below.
> You are welcome to send the message along to others but please do not use
> the "redirect" command.  For information on RRE, including instructions
> for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html
> or send a message to requests at lists.gseis.ucla.edu with Subject: info rre
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Date: Fri, 30 April 1999
> From: risks at csl.sri.com
> RISKS-LIST: Risks-Forum Digest  Tuesday 4 May 1999  Volume 20 : Issue 35
>    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
> ----------------------------------------------------------------------
> Date: Fri, 30 Apr 1999 16:22:48 +0000
> From: [address deleted] (RA Downes)   
> Subject: 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 <http://www.radsoft.net>
> ------------------------------
> End of RISKS-FORUM Digest 20.35
> ************************
> Date: Tue, 4 May 1999 09:06:59 -0700 (PDT)
> From: risks at csl.sri.com
> RISKS-LIST: Risks-Forum Digest  Tuesday 4 May 1999  Volume 20 : Issue 37
>    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
> ----------------------------------------------------------------------
> Date: Sun, 02 May 1999 16:12:13 +0000
> From: [address deleted] (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 at microsoft.com
> RA Downes, Radsoft Laboratories  http://www.radsoft.net
> ------------------------------
> End of RISKS-FORUM Digest 20.37 
> ************************
> ------- end of forwarded message -------

             -- I have a shoehorn, the kind with teeth. --
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

More information about the samba-technical mailing list