Larry

Week of February 14, 2005

Some things are too good to not be true.

Larry is a new XPT user. He had a few difficulties with his initial download. Using Firefox instead of the lethal Internet Explorer, something went wrong - he didn't get the entire package.

Things have since worked out - although all are still puzzled at why Firefox misbehaved - but this is not about Firefox and certainly not about Internet Explorer. It's about something else Larry wrote during the exchange.

'Kagi sent me a link to download from. I did so and downloaded a file which was only 2,662 KB (not MB).

Forgive me for being cynical, but with even compact engineering and programming I find it hard to believe that 146 programs can be located in that size.

Maybe if it was somehow super zipped or something...'

Most of the bulk of the XPT package is actually the documentation: the 146 applications average just over 7 KB in size. 146 apps at 7 KB per app is just under one megabyte. Three fifths of the download is the documentation - not the software itself.

The entire XPT - all 146 apps but sans documentation - will still fit on an old 1.44 MB bakelite diskette.

Larry's cynicism is not unwarranted, but again as has been stated so many times before, the surprise is not because Radsoft have done something to shrink modules but because others on the Microsoft platforms have done so much to bloat them.

Bloat isn't even an issue on other platforms - at least not the way it became on Windows.

And Microsoft have never been 'ace programmers' but things never got out of control as long as they were only trying to 'improve' code they borrowed bought or stole. It's when they made a first attempt to write something of their own - Windows - that things started in a tailspin.

Not that other vendors were completely innocent, but when Microsoft beats the drum lesser players are bound to follow. And once they wiped the field of competitive development tools, their own offering was there to spell disaster for everyone.

Things weren't too bad in the old 'coop multitasking' pre-MFC days. It did seem like a lot of code to do precious little, but programmers were quick to remember that it was, after all, 'Microsoft design'. A skeleton app of 4 or 5 KB was still possible.

Back in those days Microsoft couldn't sell a development system to save the farm. Borland won by default; Microsoft's own product had become so buggy over the years that they couldn't even use it to build Windows - they licensed the one they used from Zortech instead.

But Borland had become the big enemy with their database products wiping the field, and Microsoft had decided they needed to be driven from the market. And the first rule of monopoly is that to eliminate a product you have to be able to replace it with a similar product of your own - it doesn't have to be good; it need only be there.

The hitch with Microsoft C was that it didn't even work - to borrow the logic of TP Jackson, it doesn't have to be 'best of breed' but it certainly has to work. Microsoft C did not work - and their own monthly journals had for months been carrying inside cover ads from Borland testifying to this fact.

Borland were also first on the field with object orientation - their OWL (Object Windows Libraries) built in C++. The OWL were fairly comprehensive and as their own compiler was usable, a number of developers had tried their hand at OO (at the time it was estimated that about 10-15% of developers world-wide had at least tested the idea).

To eliminate Borland completely, Microsoft needed a usable product of their own. Scott Randell was called on to head the new 'Afx' team in Redmond.

'Scott, what does 'AFX' stand for?'

'Application Frameworks'.

'So that's A and F - what does the X stand for?'

'Anything you want, dude.'

The MFC (Microsoft Foundation Classes) were an extremely hastily written attempt to eclipse the Borland OWL. Far from being a comprehensive system, the MFC were a 'one on one' wrapper around the Windows API which afforded very few of the benefits of OO.

But they were there, and Microsoft naturally set about tweaking them to make a few applications look especially impressive. Their own Multipad, initially written in C with 1,500 lines of code, was reduced to a mere 86 lines with the new MFC. This was supposed to impress the grunts out in the field.

But a skeleton app, written as minimally as the C skeleton, would weigh in not at 4 - 5 KB but at a walloping 50 KB - ten times the size.

As the app - a window that can only close - isn't capable of doing anything, what the heck were Microsoft wasting for fifty kilobytes?

Microsoft also decided to go with the CLSID/Registry fiasco, an idea which predates Unix. As so many have seen, systems so designed easily get cumbersome and sluggish over time and use and eventually fall apart.

A good idea it isn't - but then again neither is the drive letter or the backslash - but Microsoft aren't interested now or then in quality (and might not recognise it if it smacked them in the head) - only in getting product 'out there'.

Microsoft had a source code licence to AT&T Unix since at least the early 1980s. They had every opportunity to improve the code base in MS-DOS. They bought the best compiler in the field (Lattice C) and restructured it for 'Unix compatibility'.

They could have at any time polished MS-DOS up to be something good (and others such as Radsoft did) but no: MS-DOS remained a poor and sloppy system. Microsoft were simply not interested in improving something which already controlled the market.

But bad coding, cynical marketing strategies, and above all the lack of experienced engineers leads sooner or later to a situation where things start to fall apart. And the recruitment strategy of Microsoft explicitly eschewed the hiring of anyone with substantial merit - new employees had to be completely inexperienced so their minds could be warped and controlled, their behaviour 'predicted'.

With the blind and the lame leading the blind and the lame, it's no wonder Microsoft code turns out the way it does. Microsoft have no experienced system designers or program coders; the only experience anyone has is within the confines of the Redmond campus. Microsoft work in a way radically different from other companies: where others cull skills from the entire industry, Microsoft 'wing it'.

A lady from the Seattle area who forgot to include her IT skills on her CV when applying for a job with the Encarta team was appalled at what she saw in those secret corridors and chambers. 'The buffoons don't even know how to draw a flow chart', she wrote, and tried to contact Billg himself to alert him to the situation. She never suspected Billg already knew - and in fact wanted it that way.

[The poor lady was seriously distressed over the matter, wrote again and again to Billg (who never once replied) and eventually the Microsoft legal team won a court injunction against her ever using Billg's email address again.]

Microsoft won the battle against Borland; Borland briefly tried a merger with WordPerfect (who Microsoft also decided must leave the market) and then both companies walked off into oblivion. Microsoft were left alone in the fields of word processing, database management - and Windows development tools.

And as before - and as ever since - once Microsoft have market control, all work on products in that market is effectively halted.

It doesn't matter Microsoft's development tools are sloppy, wasteful, create bloated programs - or even insecure: if they're alone, no one can buy anything else. Microsoft foist third-rate shit on everyone, and it's hardly a news flash.

And as long as Microsoft are leading the field, third party vendors don't have to worry about what Microsoft have effectively obfuscated: if Microsoft become the emperors of bloat, why should anyone else worry their pointy little heads over it?

Radsoft's XPT started as a project taken reluctantly. The target platform was MS-DOS. The PC was a toy and little more. MS-DOS wasn't an operating system; it was a hardware interface. Anarchy ruled.

The XPT tried to infuse a little Unix into PC work. As is often remarked, Unix is not so much an operating system as a way of thinking. Patterned on Brian W Kernighan's seminal 'Software Tools' series, it built up a succession of tools based on further tools, and so on.

The Unix idea was so good it was awarded the Technology Medal at the US White House in 1999.

Before Unix, operating system theory was chaotic. No one had ever considered files as mere 'streams of bytes'; no one had successfully ventured out into hierarchical file system territory; no one had seen the power of Doug McIlroy's pipes; none of this was known or prevalent at the time.

Even Microsoft's file system layout is to a certain extent based on Unix; Microsoft are today forced to use several integral parts of Unix, such as Berkeley Sockets; even Microsoft cannot evade its influence.

But with all those billions at their disposal, Microsoft could buy up and employ the best brains in the industry and let them do their work properly, and the first thing any such best brain would say would be 'why re-create the wheel - why destroy open standards - why not just use Unix?'

For even if the impossible were to happen - even if Windows were to someday become as stable and secure as Unix itself - Windows would never surpass Unix - the only way it would ever be as good is if it were in fact Unix.

The NeXT engineers were no dummies - they were in fact the best brains in the industry - and they grasped this obvious fact from the beginning: the brilliant NeXTSTEP is based and runs on Unix.

It's bloody obvious, and today everyone in the world runs Unix except Microsoft, who continue to cheat and trick their customers, gouge prices and strangle markets with third-rate copycat products bought borrowed or stolen.

Microsoft are not the Ferrari or the BMW or the Volvo or the Mercedes-Benz of the software industry; they're not trying to make good product; their only raison d'etre is, has always been, and will always be to maximise profits and make themselves richer and richer.

And as profits and quality in this context are close to being arch-enemies, quality will always suffer.