Slop

Bloat is bad. Bloat means bugs, and bugs means vulnerabilities, and vulnerabilities lead to exploits.

Slop is a manufacturing process that results in bloat, bugs, and exploits: it's mediocrity rushed to market. Unix and the Mac have never had to deal with slop and bloat much - mostly they've been seen on the Microsoft side.

The Microsoft side is intensely commercial, driven by a hysteria to get to market before anyone else does. At the pinnacle of this carnivorous food chain is none other than Bill Gates, a person who has never had any respect for the art of programming. And Bill chooses his employees not for their talent but for their malleability - he wants 'wet behind the ears' new recruits so they can be controlled, indoctrinated, and used.

The results are obvious.

MS-DOS was supposed to be more than Tim Paterson had made it. Tim himself wanted to devote serious time to its completion. But Bill wasn't interested in any of that - he simply wanted a product he could get to market. OEMs by the thousands wrote to Bill, begging him to let his programmers beef up MS-DOS. They were ignored. Only when these same OEMs banded together and found a programmer in England who was prepared to do the job did Bill react - and with the infamous 'AARD code' that would literally assault the user with scare screens about using the new product. Bill was only interested in market share - he never has and never will give a damn about quality.

The king of slop.

Microsoft once waged a war against Borland - and they won. Somehow WordPerfect got involved in this war and Microsoft destroyed them too. WordPerfect had to be destroyed to achieve the 'lock-in' of the Microsoft Office product line; Borland had to be destroyed because their Quattro Pro was the industry leading database utility and because their development environment was the only one that could be used on the PC.

Microsoft's own development environment was so pathetic that Microsoft had to contract Zortech for their development environment to build Windows - all the while Microsoft continued to market their own development environment of course.

The Microsoft product was so bad that Borland had a recurring double page spread inside the front cover of the monthly Microsoft Systems Journal with customer testimonials about just how bad it was.

As the ads repeatedly related, sometimes it would crash immediately on launch, other times it wouldn't start at all, and even though it was a Windows development environment, it didn't use a GUI.

But Bill Gates didn't care about this - he made money off the ads. It only became an issue when Borland started being a threat - not because Bill's products lacked quality.

The war against Borland was waged on several fronts. Destroy Quattro Pro. With Access and other utilities. Destroy WordPerfect. As they had merged with Borland. Destroy Borland's development environment.

Destroyed by slop.

The Borland development environment wasn't the leanest ever, but it was complete and it was cool. Microsoft's own counter-weapon was, as so many other Microsoft products, 'borrowed in' - in this case from Net Systemes in Canada. It became the basis of Microsoft's 'Visual' product series.

The cornerstone of this 'Visual' series was something called the MFC - Microsoft Foundation Classes. The MFC was a hastily mixed and baked hodgepodge of supposed 'object orientation' using the dubious C++ programming language.

Not too 'up' on how all this 'object orientation' stuff worked, Scott Randell and his MFC team in Redmond constructed - using a 'colour by numbers' approach - a 'one on one' relationship with the published Windows API. Although this results in a product of limited usability, the real issue was somewhere else.

These modern day development environments are supposed to 'set the table' for developers when said developers want to begin a new project. The developers enter a few configurations choices and voíla the development environment whips up an 'application template' with all the rudimentary parts already in place.

Running Mickey Mouse Microsoft certification courses in Windows programming shows how bad this really is. The work done on this 'Visual' line of products was never considered finished when the product attained a certain level of respectability; it was considered done as soon as it 'sort of' started to work.

The 'slop' in Windows applications comes nine times out of ten from this dirty environment.

Just how bad Microsoft developer tools are has been documented elsewhere - and repeatedly. Suffice it to say that they're worse than outsiders can ever imagine.

• Do you want a splash screen for your app? Microsoft embed a 200 KB image in your application for you. But Windows admits of two formats for BMP files, both non-lossy, and simply compressing the image Microsoft provide gets you 120 KB in savings.

• The so-called 'string tables' in Windows applications were created by members of the 'Visual' team at Microsoft who had no clue how they really worked. A programmer blindly using an MFC application template will add up to 25 KB to the executable that are only accounted by plain stupidity.

• MFC string tables have hundreds of embedded diagnostic strings that are never used. Most Windows programmers don't even realise they are there - and consequently do not remove them. Add another 50 KB or so.

• Application templates contain resources that are no longer even used, such as shift lock toggles and the 'Ctl3d' library which since the introduction of Windows 95 does absolutely nothing (it's programmed to turn off as soon as Windows 95 or later is run).
  
  Even though these resources only add slop to an application, they're left in - because, simply put, neither Bill Gates nor Microsoft could give a damn.

The list goes on and on, but the idea is clear: working in the world of Microsoft the road is opened wide to slop - and in it rushes like a flash flood.

Things are different on the Apple side. Apple use the open source GNU compiler collection. While this might not be the fastest or leanest compiler ever, it is a standard and will work on almost all platforms.

Apple also use the PowerPC processor which by its very nature will generate more code than a CISC-based x86.

Still, comparing programs written for Apple and programs written for Microsoft is useless: on the one side bloat and slop have a hard time creeping in; on the other they have a hard time ever getting out.

Mac users should still be alert. There are any number of things to watch for.

Bigger is 'badder'. Big means bloat - and bugs and potentially exploits. REALbasic is a big culprit here as is AppleScript. Ask yourself this: if the programmer is not smart or professional enough to use the 'real' development tools, what are the chances the code is bug-free? And you don't really want to use unprofessional products on your fine computer, do you?

Even real developers can screw up. Apple's development environment admits of two build styles: 'development' and 'deployment'. The development build contains reams of debugging information for use with the GNU debugger (you know, that tool Unsanity use for their system hooks) and you certainly do not want that in your products, do you?

Developers are instead supposed to switch to the 'deployment' build when they're confident their product is bug-free, but some forget (and some most likely don't care) and the difference is dramatic. Not only is the deployment build leaner, but if correctly optimised for size (which in this context also equates to speed) you will get the best possible executable image.

And you can inspect your own downloads to see if they're 'development' or 'deployment': development builds will contain megatonnes of references to 'header files' - full paths ending with '.h' - all you have to do is run a 'strings' utility or tool such as Xstrings on them to see what you find - and the actual executable is always found in the 'MacOS' subdirectory of your application package.

PkgInfo. This eight-byte file consumes four kilobytes on disk. The Finder supposedly likes it because it makes it easier to understand what's going on with your applications. Note that it's not necessary - the same information is already found in Info.plist - but it's just a 'convenience' - a convenience that nevertheless costs you 4 KB for every application on disk.

So consider removing these files. They're always found in the 'Contents' subdirectory of your application packages.

classes.nib, info.nib. These two files are often found in 'NIB packages' - directories that actually contain the logic of your on-screen application resources. Neither of these files are needed to run applications - only 'objects.nib' which you should never remove.

Some time in 2001 developer forums started speculating if info.nib could be removed; someone discovered that it could; a short time later Rixstep discovered classes.nib could also be removed; coincidentally or not, Apple began shipping product around 2002 with both removed.

You don't need them, and even if you did you could re-create them easily, so prune these out of your ISV products where you find them.