[II2II]

By the sounds of it, this bloat is minor. (Keep in mind, the author is pointing out the two most extreme examples.)

Bloat arises from a lot of different places, a lot of which cannot realistically be controlled without drastically affecting user expectations, system performance, and how software is developed.

Consider graphics. If you are quadrupling the color depth, you are quadrupling the amount of memory required for graphics resources. Even more fun, if you are doubling the resolution you are quadrupling the amount of memory required for graphics resources. Going back to the olden days would only be an option if they are willing to compromise on the quality of the graphics.

At the other end of the spectrum are developers. Should they really be choosing things like the type of an integer to reduce the size of code and data? Old software was often limited due to such considerations. In some cases software used bizarre tricks to reduce bloat, such as cramming data into the unused bits of an address. (Apparently that was common on 68000 based personal computers.)

Don't get me wrong, there is a lot of unnecessarily bloated software. Yet I suspect that the vast majority of that bloat exists for very good reasons.

[userbinator]

Consider graphics. If you are quadrupling the color depth, you are quadrupling the amount of memory required for graphics resources. Even more fun, if you are doubling the resolution you are quadrupling the amount of memory required for graphics resources. Going back to the olden days would only be an option if they are willing to compromise on the quality of the graphics.

I suspect a lot of this bloat is due to the current and IMHO horrible trend of "every UI element is a separate bitmap image", even if the image is trivial to generate procedurally; consider gradients, for example --- they're easily described by an equation that may take no more than a few dozen bytes of code, yet developers seem to think it requires storing a multi-MB PNG image, maybe even in multiple resolutions (smartphone apps are a particularly notable example of this).

The irony is that this wasteful technique is often combined with the "flat" UI trend, which would be even easier to generate procedurally, so we've arrived at UIs which are less featureful and yet more bloated.

[lefty2]

It doesn't sound too minor to me. It was 20% of windows explorer. But the worrying thing is that it's indicative of sloppy software development. If this basic stuff slips through, what else slips through as well?

[II2II]

The analysis was done on \Windows\explorer.exe, and it was noted as being an extreme case. The distinction is important for a couple of reasons. First, it is an extremely small part of Windows as a whole, weighing in at about 4.5 MB on disk (Windows 10 AE). Second, chances are that it is also a very small part of what people think of as Windows Explorer since it also depends upon external libraries.

While Windows may suffer from unnecessary bloat, this article is not a very good evidence in that direction. Windows itself is much (much) more than a 4.5 MB binary and the growth of Windows over the years likely has more to do with changes in technology and the market than anything else.

I also doubt that this is an indicator of sloppy software development, nor is this basic stuff. It simply indicates that the resources were added to the executable file more-or-less as is. Developers are unlikely to be concerned with the structure of the resources as long as those resources are in a format that is well understood by the software. Graphics designers are unlikely to be concerned with how the embedded data bloats the size of the executable. While stripping the excess data may seem like a basic good practice in retrospect, it is not basic nor is it sloppy in the sense that it doesn't strictly fall in the domain of the two groups responsible for handling the data.

[jessermeyer]

>the vast majority of that bloat exists for very good reasons.

"We didn't have time to do it right."

And yet they always have time to do it over.

[vidarh]

> (Apparently that was common on 68000 based personal computers.)

I wouldn't say it was very common, but there are some notable examples, such as Amiga BASIC which was incidentally written by Microsoft. As a result it needed a patch to run on machines with the bigger M68k CPUs (which had 32 address lines vs. 24 address lines on the 68000), but it was so awful it died a swift death in any case.

[AstralStorm]

Not quite because it was awful, but because Amiga REXX was so much better.

[vidarh]

AREXX ports were fantastic, but the language is awful. But Amiga BASIC was no longer shipped wit the OS as of 2.x anyway, so unless you got a copy elsewhere there was no choice. But Amiga BASIC had falled out of favour long before that.

[LocalH]

AmigaBASIC was horrible. It didn't really make use of the OS facilities that well, and it was slow and cumbersome. Almost identical to Microsoft's BASIC for the Mac from what I've seen, and that was universally hated compared to MacBasic