Apple Year in Review

From a programmer's perspective.

Get It Try It

It's been a wild and wacky twelve months. People are hanging on by their fingernails. The glory that was NeXTSTEP and OpenStep is hard to find.

There were a few promising developments of course.

Leopard. Version 10.5 of Apple's OS X meant more things moving to 64-bit and the ability to make Cocoa applications that way as well. Rixstep are currently testing the entire ACP as 64-bit.

The iPhone. The new Cocoa classes for the iPhone along with the device itself proved beyond any doubt the superiority of the NeXTSTEP idea. That the security design of the device wasn't as impressive is another unrelated matter. Objective-C and Cocoa have been demonstrated to be unapproachable.

ADC tools. They're still free - as opposed to the high priced MSDN tools - and they're getting better and better. The move to IB3 implies a new way of interacting with Xcode and the new 'XIB' format which 'compiles' into single NIB files yields something better suited to SCC systems and without the otherwise obsequious junk files that have littered people's hard drives.

The compilers are starting to nag about silly things which are perfectly legal syntax and recurrently found in programming books from Bell Labs, leading one to fear for the future of the planet as the mainstream mediocre gain the upper hand. But despite this and several other relatively minor flaws the tools are eminently usable.

Yet with all this - being first in the 64-bit market; having a graphical interface and a visual appearance envied by Mark Shuttleworth and copied sloppily and shamelessly by the FOSS developers; having a system with impressive usability; having superior development tools for a superior development and end user platform - things haven't panned out as they should have, as so many hoped they would.

The market share for this product is as miniscule as before; sales have actually dropped whilst Microsoft are experiencing growth for the first time in a long time; forces within the company obstinately insist on keeping the system tied to a hardware 'dongle' even as renegade clone OEMs appear to threaten the monopoly - and all this makes third party investment increasingly difficult to justify. Apple may soon find themselves the only software house writing for their system - perhaps a Steve Jobs wet dream but surely a Steve Wozniak nightmare.

Here are a few of the other things that happened this year. They're not all bad.

Code signing. After the introduction of the abortive iPhone security model with everything running as Windows Apple decide not to beef things back up to the level of the native OS but to try something else instead? Surely it's an easy way out?

No matter. And faster than you could say 'drink the goddam Kool-Aid™' they'd ported the technology to their coming issue of The World's Most Advanced Operating System™.

Code signing works on certificates and is a bitch to crack. Things get worse when you realise they're signing not only the binaries themselves but also the junk files they obstinately insist on packaging with them.

[Yes Leopard had its own new junk files that broke all records in obscenity. See below. Ed.]

Even some of the third party Kool-Aid™ drinkers are getting into the act. A site visitor wrote to the author of Pacifist to ask why the subterfuge and why junk files like classes.nib, data.dependency, designable.nib, and info.nib are included in the bulky downloads.

The first reply was expected - sort of. 'There might be someone who wants to translate the app from Albanian into Korean.'

No matter that this can be done without those files (we're talking really dumb people here).

The followup question was also inevitable.

'Including those files is one thing. But they do absolutely nothing at runtime. So why the F include them in code signing?'

No reply.

Cocoa services. Apple's style of code signing also includes Info.plist. And Info.plist includes the more and more hated Cocoa services. Why are Cocoa services hated? Because Apple screwed them up. Starting back in April 2005 - over three years ago with the introduction of 10.4 Tiger. And they still haven't fixed them.

And with 10.5 Leopard they've compounded the issues and made them worse than ever.

More and more people's services menus are starting to look like the ridiculous Windows Start menus. Seriously: who wants a Chinese text converter? And why does there have to be one on everyone's computer?

Things are starting to look like Steve Jobs' old contract with Best Buy: they'd order one thing; Steve wouldn't like what they ordered and how they ordered; so he'd just ship them something different. You get what Steve wants you to have no matter you asked for something else. That's a novel way to do business.

And in the good old days you could deal with this. Utilities such as Rixstep's ACP Service Manager Pro could whisk away what you didn't want. And your system actually worked pretty good again.

But that's all gone now. When queried about these matters certain unnamed Apple engineers cited total ignorance about users desiring to clean their Cocoa services menus - and even clean out junk files Apple were smart enough to weed out themselves only a few years ago. Quality control at Apple.

Breaking the code signing on most apps won't affect use of them but breaking it on 'web apps' will. Apple have of course an extreme issue with their web apps that's never been properly fixed and that even binge Kool-Aid™ drinking won't wash away: they're principally insecure. And it's all because of their ridiculous 'file manager'. So call the cavalry and bring code signing to the rescue.

You can't weed out NSServices entries from Mail.app, iChat.app, and Safari.app if you need your keychain. If they detect their precious Chinese text converter or their megabloat designable.nib files have been removed they'll refuse to get your keychain passwords for you.

Security the Cupertino way. The standard setter in 'user friendly'.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>files</key>
    <dict>
        <key>Resources/Calculator.icns</key>
        <data>
        uZ9Ut+wW4YERkJ3JBwIH3PvErh8=
        </data>
        <key>Resources/ConversionsFromBase.plist</key>
        <data>
        kkEO4We1m70O3RSuIDtrM12Fa34=
        </data>
        <key>Resources/ConversionsToBase.plist</key>
        <data>
        A96B9mXXBZLG3tHGg9CH3F6u93E=
        </data>
        <key>Resources/English.lproj/Calculator.nib/classes.nib</key>
        <dict>
            <key>hash</key>
            <data>
            a8n2iiLb2aN7HJUTGgqAM89/yYk=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/Calculator.nib/info.nib</key>
        <dict>
            <key>hash</key>
            <data>
            R5ljn/Gkd0s2sSW37C8p70eglOU=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/Calculator.nib/keyedobjects.nib</key>
        <dict>
            <key>hash</key>
            <data>
            UeVGVGhvNe9n1y9RnOX0DHH+sBg=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/ConversionLocalizedNames.plist</key>
        <dict>
            <key>hash</key>
            <data>
            Q0FoHfzN9SxpLGGcyPtw8ZXGu9s=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/ExchangeRates.nib/classes.nib</key>
        <dict>
            <key>hash</key>
            <data>
            deN4IlZUMK69enc4qJ+yqJ3qouc=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/ExchangeRates.nib/info.nib</key>
        <dict>
            <key>hash</key>
            <data>
            MR/dF5SxaOaI7snImZ24g6zCgM0=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/ExchangeRates.nib/keyedobjects.nib</key>
        <dict>
            <key>hash</key>
            <data>
            rdf9lzcbEX6bgoY3lH1IvdKtpGk=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/InfoPlist.strings</key>
        <dict>
            <key>hash</key>
            <data>
            EpOHlyHPMo87i9vb0oOQTh49QDA=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/English.lproj/Localizable.strings</key>
        <dict>
            <key>hash</key>
            <data>
            t9yslaMvMSkirNbQOWHnrUumeps=
            </data>
            <key>optional</key>
            <true/>
        </dict>
        <key>Resources/OldFinancialRates.xml</key>
        <data>
        w3agcuyjdbYO2sUizLWoVLf5mlQ=
        </data>
        <key>Resources/ck.png</key>
        <data>
        YUNE3DzKme6vfphp7S6Mg3q+NZc=
        </data>
        <key>Resources/lcd-bottomleft.tif</key>
        <data>
        xIsHSmTEdvPuO85cLIBWhbk7Wr4=
        </data>
        <key>Resources/lcd-bottommid.tif</key>
        <data>
        JJ0XKuTEAAwBdtM7oBGJuTcDswk=
        </data>
        <key>Resources/lcd-bottomright.tif</key>
        <data>
        /5GJdYpklqm9CZJscz6dmNRz0aw=
        </data>
        <key>Resources/lcd-leftmid.tif</key>
        <data>
        OzdUUV0zyCSTb4ph4/y14EtqDTs=
        </data>
        <key>Resources/lcd-mid.tif</key>
        <data>
        ywHuqmL5Or6IFabAwXUEsCs8pFw=
        </data>
        <key>Resources/lcd-rightmid.tif</key>
        <data>
        auojOqwjA0iZuk2VtyDKdvxoW04=
        </data>
        <key>Resources/lcd-topleft.tif</key>
        <data>
        76in3Nn+lAGx05gou9rXTB177qA=
        </data>
        <key>Resources/lcd-topmid.tif</key>
        <data>
        zT1Th3YO01Gw/XRXEEx85K6gjg4=
        </data>
        <key>Resources/lcd-topright.tif</key>
        <data>
        K2tGoCaBII6wV4xhHahl/4eAAPs=
        </data>
        <key>Resources/tapeButton.tif</key>
        <data>
        96tA9po4e+ekA8ONY3Hq2ZEOIU8=
        </data>
        <key>Resources/tapeButton_Pressed.tif</key>
        <data>
        Rzryeq7IzaygXMsn7TvxWidmJEc=
        </data>
        <key>Resources/tapeButton_Rollover.tif</key>
        <data>
        MLJTGi1cSrggG6MT2VdIPwtC/vQ=
        </data>
        <key>Resources/tapeButton_Selected.tif</key>
        <data>
        BqHT1BWKp6XDa3AZ2kyExUK8OBg=
        </data>
        <key>Resources/tapeButton_Selected_Pressed.tif</key>
        <data>
        HLLeF1MqlZP2pQSJJw1hKlEXihE=
        </data>
        <key>version.plist</key>
        <data>
        3nUI7U6CWQnFlhTmsyb2JMMUTn4=
        </data>
    </dict>
    <key>rules</key>
    <dict>
        <key>^Resources/</key>
        <true/>
        <key>^Resources/.*\.lproj/</key>
        <dict>
            <key>omit</key>
            <true/>
            <key>weight</key>
            <real>10</real>
        </dict>
        <key>^Resources/.*\.lproj/CalculatorHelp/</key>
        <dict>
            <key>omit</key>
            <true/>
            <key>weight</key>
            <real>50</real>
        </dict>
        <key>^Resources/.*\.lproj/locversion.plist$</key>
        <dict>
            <key>omit</key>
            <true/>
            <key>weight</key>
            <real>30</real>
        </dict>
        <key>^Resources/.*\.nib/classes\.nib$</key>
        <dict>
            <key>optional</key>
            <true/>
            <key>weight</key>
            <real>20</real>
        </dict>
        <key>^Resources/.*\.nib/data\.dependency$</key>
        <dict>
            <key>optional</key>
            <true/>
            <key>weight</key>
            <real>20</real>
        </dict>
        <key>^Resources/.*\.nib/info\.nib$</key>
        <dict>
            <key>optional</key>
            <true/>
            <key>weight</key>
            <real>20</real>
        </dict>
        <key>^Resources/English\.lproj/</key>
        <dict>
            <key>optional</key>
            <true/>
            <key>weight</key>
            <real>20</real>
        </dict>
        <key>^version.plist$</key>
        <true/>
    </dict>
</dict>
</plist>

Above: Apple's code signing on their Calculator.app. You can't be too careful.

But the Cocoa services situation is worse still. For they've borked the code as well. They started doing this with Tiger in April 2005 and not only did they not fix this over eleven updates - they set a new industry high by making it even worse for Tiger's successor.

[Apple have so much borked NeXT code today that no longer works it must be some kind of Guinness record. Ed.]

What happened with the Tiger code can be seen documented at any number of sites online. The actual services code was still OK - it was how Mail and Safari suddenly started handling it. By borking their code - by making their code behave incorrectly - Apple effectively ruined use of Cocoa services for a great many consumers.

So what did they do?

Cocoa services use a pasteboard. 'Pasteboard' is just another word for 'clipboard' except Apple don't want you to tell people that's the 'real' word - they're afraid the word will scare people away. But of course 'clipboard' won't.

NeXT created several pasteboards, each with several data formats. Here's what they have if you select a 'k' character, hit ⌘E, then hit ⌘C, then try to drag it.

Apple CFPasteboard drag (10)
(
    public.utf8-plain-text: {
        <6b>        
        k
    }
    NSStringPboardType: {
        <6b>        
        k
    }
    dyn.agu8y63n2nuuha5dbrf1ca2pxqry0wkduqf31k3pcr7u1e3basv61a3k: {
        <6b>        
        k
    }
    NeXT plain ascii pasteboard type: {
        <6b>        
        k
    }
)

Apple CFPasteboard find (18)
(
    public.utf8-plain-text: {
        <6b>        
        k
    }
    NSStringPboardType: {
        <6b>        
        k
    }
    dyn.agu8y63n2nuuha5dbrf1ca2pxqry0wkduqf31k3pcr7u1e3basv61a3k: {
        <6b>        
        k
    }
    NeXT plain ascii pasteboard type: {
        <6b>        
        k
    }
)

Apple CFPasteboard font (0)
(
)

Apple CFPasteboard general (27)
(
    public.utf8-plain-text: {
        <6b>        
        k
    }
    NSStringPboardType: {
        <6b>        
        k
    }
    dyn.agu8y63n2nuuha5dbrf1ca2pxqry0wkduqf31k3pcr7u1e3basv61a3k: {
        <6b>        
        k
    }
    NeXT plain ascii pasteboard type: {
        <6b>        
        k
    }
)

Apple CFPasteboard ruler (0)
(
)

Above: the system's reaction to a single character 'k' being put on the drag, find, and general pasteboards.

But there's another pasteboard not listed here. Because it's proprietary: used only for the Cocoa services. When a 'client' accesses a Cocoa service it tells the AppKit what to take; the AppKit gets the data and puts it on the special pasteboard and then calls the 'service provider' and sends along a pointer to this super secret special pasteboard.

The provider then gets the data off the special pasteboard, does what it's supposed to do with the data, then puts the modified data back on the same pasteboard.

-(void)port:(NSPasteboard *)pb userData:(NSString *)data error:(NSString **)error {
    // Do something then send the data back
    [pb declareTypes:[NSArray arrayWithObject:type] owner:0]; [pb setString:s forType:type];
}

Above: the simple yet elegant method of processing NeXT services. Somehow this has baffled Apple for over three years.

Most of this is set up automatically by the brilliant code classes NeXT created. Apple's Mail for Jaguar and Panther handled this seamlessly as there was nothing to add to the code - the code was already there. All they had to do was leave it alone.

Then something happened. Suddenly Mail diverted attention from the special services pasteboard to the general pasteboard - the one used for ordinary copy and paste operations. It was still sending data out correctly - but someone in Cupertino put in a blooper of a line of code and so when getting data back again took it off the wrong pasteboard.

This has been in effect since April 2005. Even longer if you consider all the 'beta testers' who had their chance to alert the company but failed to do so. Or at least get a response. That's over three years. For a really dumb and really simple error.

[There are workarounds of course. But honestly: what other OS vendor would force people to go to such lengths when all they have to do themselves is reverse a single line of code? And can't do this for such an integral part of their system in over three years? Ed.]

But now as of Leopard things get even worse. Something most hardy developers would have thought impossible.

Suddenly someone's now gone into this NeXT code and even borked how it handles services control flow. Meaning the facility and user friendliness of the Cocoa services is seriously damaged.

Suddenly you get Microsoft type 'LUA'; service replies meant to indicate 'no changes made' are suddenly 'flagged'; users get 'scare screens' telling them there's something wrong with their system when there's really nothing wrong at all; services data gets 'cached', forcing users to reboot to see changes; the AppKit's services module starts crashing all over the place.

You just don't go ruining perfectly good code with advertised APIs. No other OS vendor would dare do such a thing.

The inode feeding frenzy. Pop quiz: since when is it a Good Thing™ to 'move' files instead of copying them especially when there's ample documentation your 'move' algorithms have often resulted in 'massive data loss'?

The year started with a number of sysadmins noticing they were losing gigabytes of data when transferring files over a network. The upshot was that new Apple code was caching files in memory and then blindly counting on everything 'just working' - from the network connections to whatever you want.

File 'moves' over volume or network boundaries aren't 'moves' at all. 'Moves' are only possible when both source and destination reside on the same volume. A 'move' doesn't move files - it moves the directory references. This is possible because all files on the volume are listed by what is known as an inode - a number (index) in a volume control block.

The inode contains all data on the file - including where to find the file contents - save the name itself. All the directory has is the file name and the inode number.

Thus 'moving' a file with source and destination on the same volume is merely a matter of yanking out the old directory listing and putting it in the new location instead. 'Fast'.

But not so with 'moves' over volume or network boundaries. The source and destination won't be using the same volume control block. The file has to be literally copied. And for safety's sake the file is first copied, then checked for integrity at its destination - and then and only then is the source removed.

This is pretty much a necessity on all systems. The kind that make the world go round. Everywhere that is except Apple where no fallback is available for crashing processes, broken connections, hardware errors, nothing. You try to 'move' a file and you're taking your life in your hands.

And into this confusing melee you now suddenly introduce a few rather strange 'call support drivers' - nagging requests for changes to ('improvements' in) the 'operating system'. It seems some of the user base found themselves increasingly perturbed by alerts from the Cocoa document controller that they didn't have sufficient permissions to save their own files. Now it's rather surprising to say the least, considering the only way the files could have become read-only is if the same user made them so.

But no matter: let's try all we can to please here. And what with the way Unix file systems work it's going to be possible. Sort of anyway.

Here's the trick: Unix files and directories have separate permissions. Files can be marked as readable and/or writable; so can directories. Directories are just files treated in a different way. They have two things of essence: file names and inode indexes. That's it.

Renaming a file means you're going to write to the file's directory to change the name. Adding a file to a directory means you are going to write to the file's directory to add the new name (and inode). Removing a file means you are going to write to the file's directory to remove the name (and unlink the inode). If you can't write to the directory you can't add, remove, or rename files. Period.

You can still write to the files that are there - as long as you have write permissions. But you can't do things associated with their directories - you can't add files, remove files, or rename files. You don't have permission.

Now Mr Caution Klutz from Idaho writes to his friends in the HI group in Cupertino, complaining about how he can never remember what files he's write-protected. He's sick and tired of having his own shortcomings pointed out to him by that tyrant of a document controller hovering over every 'save as' dialog box. Can't Apple do something for 'the rest of us'?

Sure they can. But it's a band-aid fix at best and a Pandora's Box at worst. To understand what's afoot you first have to understand how Apple's document controller's been working all these years.

When working through the 'GUI' and when users decide they want to save their files the document controller behind the scenes sends a message to the application, telling it that it's time to store the data. But the document controller isn't going to save the data directly to the user's file - instead the document controller directs the application to a temporary location.

It's here the application saves the user's data instead. Once the data is saved to this temporary location the document controller copies the data to the user's actual file and the operation can be considered complete.

Is there any reason for choosing this circuitous algorithm? There might have been once upon a time. Perhaps the idea was to keep a backup of user data in case something went wrong. But it's been lost today. Cocoa applications have no facility to get at recovery data from crashed processes. Whatever.

But the 'copy' involved - that from the temporary location provided by the document controller to the final destination which is the user's actual file - was a good move. And in two ways.

1. As it's a copy - one file's opened for reading and another for writing - normal permissions scenarios will apply. Conformance with the underlying security model of the file system and the operating system isn't compromised.

2. Copying implies the source remains until the operation is complete. There's no risk you will lose your precious data as can happen - and as has happened - with Apple's notorious 'move' operations.

Now all that is about to change with Leopard. Someone gets flustered and makes enough phone calls to friends inside Infinitely Blooped and a fait accompli is upon everyone. This is how it will work.

1. File saves will proceed as before, the document controller directing applications to a temporary location where they will store the user's data.

2. The document controller will no longer copy the data to the final destination - it will 'move' it in. And it will do this by first removing the current user file.

For a few nanoseconds there your file doesn't exist.

There are of course a number of incredibly complex and confusing caveats with the above 'idea'.

1. Now that the system is going to 'override' user permissions (by essentially writing to files that are protected against writing) some type of alert is going to be necessary. Otherwise the vendor's programmers will get shit for it sooner or later.

2. So we tell the user their file is 'locked'. That's a good non-Unix term. Then we ask the user if we should override the permissions and write to the file anyway - write to a file that's protected against writing.

3. We don't need the user to 'authenticate' - no need for a password. We don't have to escalate the current process or any child process thereof. We're not attempting to write to a protected file. No need for superuser privileges here.

4. We're going to botch the directory instead.

Then along comes someone who innocently asks 'but what if the directory is write-protected?'

Ah. Ouch. That is really a problem. For to 'move' a file into a directory we have to be able to change the inode for that file in its directory. And to do that we have to be able to write to the directory itself.

So bottom line? The geniuses in Cupertino have now created a file storage scenario that fails on writable files!

Only Apple could do this. Only an Apple engineer would have ever dreamt up something as stupid. Only Apple would have let a dumb idea like this out the door. Apple may have put their faces in it before but this might be the all time great.

And of course this leads to an inode feeding frenzy: the one way file systems have of determining whether two file references are to the same physical file is by comparing inodes. But you can't do this anymore because the inode is one more NeXT/Unix thing Apple have unwittingly (stupidly) corrupted and tossed on the trash heap of computer science history.

Macs are cool.

No more 'x' bits. Sometimes you gotta wonder where Apple think they're taking their users. Sometimes you gotta wonder if they even remember they got on the supercomputer map by a big purchase order from Virginia Tech - and if they ever gave a thought to how those computer 'scientists' were going to be able to deal with a system with a file manager that can no longer control executable bits?

Not that things haven't already been bad enough before Leopard. Users - admins and ordinary users alike - have been unable to control symbolic links, hard links, number of links, inodes, sticky bits, and set ID bits. They've been powerless to administer their systems.

Apple's phenomenal 'user experience engineers' seem to cringe at the thought their underlying operating system has anything resembling a sophisticated security model. They seem hell bent on getting the admins out of the user space and even shutting down the server side of the business.

This has been going on for years. Ever since Apple 'acquired' NeXTSTEP/OpenStep with the altruistic ambition to 'improve' it.

And the admins have all but laughed Apple out of the server space anyway. When shown the brilliant hardware they've justifiably applauded; but when shown what they're expected to administer these systems with - when shown Arno's FF - they've walked away.

And now it's even worse: now you can't even set the 'executable' bit on files anymore. And no it's not a joke. Not a funny one at any rate. You get to choose between 'read' and 'read & write'. That's it.

And you still can't see symbolic links, hard links, number of links, inodes, sticky bits, or set ID bits.

[Xfile will get you there but you need third party software to do it. That's not the way it should be. That's unconscionable on the part of Apple. Ed.]

Buggy apps. Steve Wozniak wasn't kidding when he said the buggiest software he uses comes from Apple. It's one thing to have an app in development and to have kinks that have to be ironed out; it's quite another when you've 'inherited' stellar code from another company and you find yourselves incapable of even touching it without introducing a caliber of new bugs seldom seen in the industry. Both Apple's Mail and Safari - representing the #2 and #1 killer apps on the web today - are threatened by an armada of bugs introduced by none other than Apple's own engineers.

Safari's probably the least of the offenders today. Today the underlying WebKit is being used and inspected by the likes of Google and Nokia; if there are shortcomings (and if Google and Nokia don't toss in the towel) then these endemic flaws may gradually disappear.

Safari inherited Dave Hyatt from the Mozilla Camino project; Hyatt turned around and opted not for the impeccable Mozilla Gecko engine but for the lighter (but buggier) KDE engine. KDE's way of handling JavaScript therefore has to be held suspect.

The normal 'MO' up to now was to cruise along and wait for crashes - then go in and apply patches to the KDE code. One after the other. [Gecko programmers don't have to worry about this. Their engine 'just works' and always has. Ed.]

The Safari released with 10.4 Tiger is all but unusable today. It's a ticking bomb. It crashes all over the place. As JavaScript practices have changed the flaws in the KDE 'MO' have been exposed. Using the 'fix a bug at a time' approach instead of coding defensively so applications simply don't go south hasn't been the order of the day. Whether things improve now will take time to tell.

When first released Safari for Leopard had this really cool feature called 'inspect element' - except if JavaScript wasn't turned on the whole vehicle tanked - it crashed and burned.

Somehow this got through Hyatt's quality control; somehow the inherited JavaScript code still wasn't any good.

And Safari will still let you deface any of its read-only pages. Another first for the industry - a H/T to Apple.

But if Safari raises eyebrows then Apple's Mail should drag them to the back of people's heads.

Apple Mail. This used to be a good program. Apple didn't write the code - the NeXT engineers did. Apple inherited the code. And for a while things were pretty much OK. Even as far removed from Redwood City as August 2002 (release of Jaguar) things remained satisfactory.

Then the inevitable happened: Apple started 'improving' the code base.

Today there are so many bugs and design flaws in Apple Mail it's not really realistic to hope they'll ever be sorted out.

Here's a short list.

1. You don't get to see the drafts folder so easily. Some 'user experience engineer' decided it was not 'user friendly'. You can move messages into this unseen folder but you can't get at them once they've been moved. Brilliant.

2. The program intermittently saves messages to the drafts folder anyway. But because the folder won't often officially exist it's never cleaned out. You'll find remnants of messages you've long ago sent on disk - a great big gaping privacy hole if there ever was one. And another industry first for Apple.

3. The program doesn't check what messages are on disk as its NeXT predecessor did. It relies on intermediate files it constructs on its own. Hardware glitch? Runaway process? Forget it. If Apple Mail says your message isn't there then you're not going to get it. Conversely if Apple Mail insists your message is there when it's not you'll never get rid of it.

4. Try dragging the wrong file type to Mail's dock icon and watch it crash. [Remember what Steve Wozniak said.]

5. Save a message draft as plain text and watch Mail open it again as rich text. Over and over and over again. Bug? A whole colony.

6. Watch Mail mess up the indenting and the colours. You'll never get it right - because the Apple programmers will never get it right.

Electronic mail is the #2 killer app on the web. And it will always be. To have such a crucial application in such a sorry state is downright embarrassing.

And speaking of 'embarrassing' Apple still have the screen remnants introduced in Tiger.

Screen remnants. Do you know what a scroll bar is? You do? Do you know what half a scroll bar is?

A half scroll bar appears when Apple's reworking of their low level kernel programming interfaces (KPIs) for Tiger got borked by the trusty Apple engineers. So suddenly when you dragged a scroll bar in Safari only half the scroll bar followed along - the other half stayed right where it was. Like the uncoupled caboose on a train. Just sitting there. Looking really dumb.

Have you ever seen Windows do something like that? Nope.

Screen remnants are also when your menu bar at the top - the 'Apple' replacement for the brilliant cascading menu system of NeXT - suddenly gets munged with titles from several applications in there all at once.

Screen remnants are also when you want to reply to an incoming mail message and you find Apple Mail leaves the last line of the file duplicated and hanging off the bottom because they're using the wrong invalidation rectangle. They don't see it but you do. So do all the visitors to the Apple stores who end up walking out almost rolling over in belly laughter.

The table view. Probably no component of the graphical interface has undergone more punishment in recent years as the Cocoa table view represented by the code class NSTableView. Starting with the release of Tiger a whole new 'type' of 'event driven programming' was introduced, turning the paradigm on its head. Suddenly processes were running dozens of threads they'd never seen before (and which naturally weren't documented - we're talking 'Apple' here).

No single message queue for these people. Hop skip and jump your way to fame.

Then comes Leopard. Are any of the really bad Tiger bugs going to be fixed? It's hard to say. The rollout of Leopard sadly coincided with the rollout of the iPhone and guess who got higher priority? [Clue: they took the word 'computer' out of their corporate name. Ed.]

At time of closing shop PST the day of the iPhone release developers finally started getting replies to their Tiger bug reports.

Please wait for the release of Leopard. Then purchase Leopard and test your bug there. Thank you.

So was anything fixed with Leopard? Put it this way: Apple had other things to work on. Such as the iPhone. They turned the coding of Leopard over to volunteers from the wetback cleaning crews.

1. The text field cells in table views now have tooltips. You can't turn them off. Now imagine what things look like when a cell has 1,000 characters of plain text data.

2. The table view is now running a timer. And everyone knows what a CPU hog timers are.

3. The table view now has 'mnemonic response' - something Microsoft have had for at least ten years. Except Apple's version doesn't work right. It's still buggy beyond belief (or possibly repair). [At least you can turn this 'feature' off. Ed.]

4. See #2 above. There is now a one second realtime delay before a 'select all' is cleared. This is good for nothing.

5. See #4 right above. For it gets worse. You can't double click a row and expect good behaviour anymore. The double click goes through (after about half a second) before the timer expires - the 'select all' will remain and the user will have no inkling what was clicked on.

6. Perhaps the most astounding of all: you can no longer effect multiple selection ranges. This is so taken for granted in graphical interfaces today it's mind boggling Apple can have borked this too.
   
   You start a new set of selections by clicking on one row. No control keys allowed. This will clear all previous selections. [After one second on Apple systems. Ed.]
   
   You now hold down shift and click on the next row you want. And everything between the first row and the new row will be selected as well. This is so endemic to graphic interfaces it goes back to Alan Kay.
   
   To add a selection range you now hold down ⌘ (Ctrl on other systems such as Windows Gnome and KDE without ⌘) and click on the start of the new range.
   
   To complete this range you hold down shift and click on a new row.
   
   Your first selection range will remain. You will now have two selection ranges. This is by design.
   
   And it's worked everywhere in the world for the past thirty years or so.
   
   Until now.
   
   Another H/T to Apple.

The system login items hole. This is a huge and extremely dangerous design flaw that allows essentially anyone at all to take over an Apple system - and thereby most likely take over any network to which it is connected.

It's closely related to the 'Opener' hole which was finally patched - after a few ifs ands and buts - shortly after the release of Tiger in April 2005. Its existence essentially means no corporation can use Apple computers securely in their networks without drastic measures akin to protecting Windows docking stations.

Any admin (non-superuser) process (or intruder or corporate spy) can simply place a 'request' in the proper location without privilege escalation and without authentication and then simply wait for a reboot and a new login.

At which time the machine is totally pirated.

The 'request' can be sophisticated, clever, or downright cruel. It doesn't matter. The hole prejudices against none. It can be used to create a new phantom superuser account so the intruder can login thereafter as root and own the machine (and the network it's connected to). It can be used to break into secured files with closely guarded corporate secrets. It can be used to destroy - just vandalise everything.

And as of now there's no way to stop it. No way.

It's been claimed the hole was needed for third party software titles that today are obsolete and therefore the hole can be closed. Someone in such case is an ostrich: you don't facilitate use of third party software by opening your security barn door so the whole world can get in. Period.

The good news. Is there good news? Granted the above is but a short list and a more complete list would be overwhelming; but is there good news too? Yes there is.

Prior to Leopard 10.5.6 - a release rumoured to be so bugged Apple are going to have to rush 10.5.7 out the door just to remedy the mistakes - Terminal would often open two windows at startup if said startup included a first command. Suddenly things run almost as fast as with Tiger again.

[That was the good news. And yes that was all the good news. Suck it up. Ed.]

Promises Promises

If Microsoft committed the ultimate crime by - as BSD/vi programmer and Sun's cofounder Bill Joy said - putting a standalone system on the Internet without a thought for the safety of the user then Apple committed the penultimate crime by acquiring the technology to put Microsoft to rest once and for all and then systematically reducing it to beige box rubbish.

For Apple's OS to live up to its promise several things are necessary.

Clean the code. This is ostensibly what version 'Snow Leopard' is all about. See that it happens. There are too many quirks in the code as things stand today. These have to be weeded out to save the corporation further embarrassment.

Open it up. And get rid of the beige box rubbish. It's time to decide which operating system you're going to use. And there's only one realistic choice. You can't have two separate underbodies running in the same box. There must be one and only one path through to the kernel and to the computer resources. Period.

And that kernel has to be open source. And completely so. It can't be something where developers can pluck components at random - it has to be a complete system that can be downloaded in source form, built, and installed on any computer running the OS.

Brian Kernighan's golden rule #3: let the other guy do the hard work. There's no reason at all - on the contrary - to mess about with one's own kernel when the FreeBSD group are always doing nicely, thank you. Use the FreeBSD code straight out of the box.

Work with the FreeBSD people instead if there are security concerns. Cooperate with them - don't take their code and bend and twist it without letting it undergo the same rigourous vetting process. That only leads to mistrust and disaster.

Get it running on Linux. And for that matter: on Windows, on Solaris, on HP-UX, on them all. So the FreeBSD underbody can be removed and replaced by any of the above. It's called modularity. And it only leads to better code. Does that sound familiar? Because it should.

Don't fight the clones - work with them. It's time to stop being so anal retentive. Anal retentive is so 1970s. The Attack of the Clones is well underway. The company could find success in fighting the Florida front but the Canadian one is much more difficult. Give it up - admit you have something the world at large wants and give it to them. You can't supply the entire planet with all the computer hardware they need. Stop being such a snob. Yes Steve that means you.

Tak a pint-stowp o' gude-willy waught. And greet 2009.