Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch » The Technological

Contact the Vendor for an Updated Version

Never underestimate the number of pinhead programmers in Cupertino.


Get It

Try It

Five years: things were bliss. Through OS X Jaguar, Panther, Tiger all worked so very well. Cocoa services are a boon to any desktop - if used correctly and if the poor user can clean away the debris on the menu which often ends up looking like the Windows Start menu.

Chinese Text Converter? Sure everyone from Juneau to Johannesburg needs fast access to that, right? And sticky notes? Hey we all make sticky notes a thousand times a day, don't we?

But given that there are tools to clean up the menu and that one is thereafter left with a simple efficient and above all useful Services menu - then they're great.

But now and again the unwanted happens in Cupertino. A fanboy gets a job programming. And he's put on an assignment where nobody thinks he can do wrong. Trusting people. Tsk tsk.

The genius of the ACP Text Services - and text services from a lot of other vendors who often serve up hundreds of them at a time - is that it's possible - even though you're not in the same address space - to communicate adequately with the client.

The client and the provider are not connected save through the pinhead programmer working on this code in the AppKit. He's the one passing data back and forth. He's the key. The weakest link.

The Empty String

There must be a way for a service provider to indicate - through the pinhead - that no changes can be made to selected text. The provider doesn't have access to the model or the view. It can't see if any changes are possible - and even if it could it wouldn't be able to enable or disable menu items accordingly: those items are in an address space belonging to another process. AppKit services use the age old NeXTSTEP system with a special pasteboard. And this pasteboard is passed both to the client and the provider.

Once the client has indicated it would like text services it's asked by the pinhead for the text to be modified. The client considers its selected text and then puts it on the special pasteboard provided by the pinhead. The pinhead then passes a pointer to this pasteboard to the provider.

There is no further (or closer) contact between the client and the provider.

The provider now takes the string passed through the pinhead and over the special pasteboard and begins working on it. But what happens if the client wants the text put in lower case and the text already is in lower case?

Clearly the provider should not intimate any changes are necessary or have been made. And up until Leopard - and since the inception of NeXTSTEP twenty years ago - the solution has been both imminent and obvious.

You pass back an empty string.

The empty string is a legal entity. It really exists. In the world of NeXTSTEP (and yes Cocoa DUH) it's an instance of the NSString class, it has authentic allocation - IT REALLY EXISTS.

And you can legally put an empty string - or a pointer to any empty data set - on any pasteboard. IT'S PERFECTLY LEGAL.

So what happens when the client gets back an empty string? Easy. And it's perfectly logical. Say it aloud to yourself. 'The client is now replacing the selected text with *nothing*.'

Nothing changes; the red button does not get dirtied; the file does not need to be saved again. Most importantly: the user of the program can know there were no changes made. Which can be wildly important with text files of inordinate size.

And that's the way the ACP text services and a lot of text services for OS X have worked since time immemorial. Until the pinhead was called on to rewrite the code for 64-bit Leopard that is.

You can almost see him at work, this pinhead: he's in uncharted territory; he's 'discovering' this ancient NeXTSTEP code which for so long has worked so well; AND SUDDENLY HE SEES SOMETHING HE THINKS IS WRONG.

'Return an empty string on the pasteboard? That can't be a good idea!!1!'

[Note the pinhead has to directly interfere at this point: all he really needs to do is wait for the reply from the provider and then call the client again with a pointer to the pasteboard - THIS PINHEAD IS BUTTING IN WHERE HE'S NOT SUPPOSED TO - WHERE HE'S NOT WELCOME.]

This pinhead has arbitrarily decided to inflict AppKit services with NEW RULES. Note these rules are not part of a new protocol; there is no announcement there has been a change in the protocol; the age old sample from Ali Ozer stands as it did back in 2004 when all of this worked without a hitch. No - our pinhead has introduced these changes on his own - and probably without approval from 'above'. Ian Malcolm Syndrome™.

And to prove his point he issues a dialog with the arrogant text as follows.

To say this is arrogant would be too kind. There is no notification to any vendor about any changes in protocol; there have been no changes in protocol; the vendor certainly won't know what the F is up; THIS IS PASSING THE BUCK PURE AND SIMPLE.

It's also cowardly. And worse still it's a LIE. The service did in fact provide 'valid data': it works on Jaguar, Panther, and Tiger - and would work if this pathetic excuse for a programmer hadn't got involved.

What to do? Reduce everything to the boneheaded speed and IQ of Cupertino. And in fact now do something REALLY ILLEGAL - which of course our dear idiot doesn't catch.

YOU PUT A NULL POINTER ON THE PASTEBOARD. You tell the hopeless loser you're returning a string and then you dump a big goose egg on his pointy defective cranium. And this - despite being BAD CODE - actually works™.

And you might be asking yourself: 'is there any difference between the two dialogs save for the different service names?' And there doesn't appear to be, no. But here's where the punch line comes in.

If you send too many empty strings to the pinhead he eventually loses it and his AppKit code SPINS amateurishly OUT OF CONTROL and in the end NOTHING WORKS and you have to REBOOT YOUR COMPUTER.

But if you keep putting null pointers on the pasteboard - hey things go great!

In the one case you do something perfectly legal and pinhead can't wrap his over exerted mind around it and so he outlaws it; in the other case you do something reprehensible - something that should be outlawed - AND PINHEAD CAN'T CATCH IT.

It's nice and comforting for Apple customers to know their computer use and interests have been put in such capable hands.

But if you bomb pinhead's special pasteboard with bad code it works. The users have to put up with a really stupid dialog - and way too much user interaction and feedback at least for those with more computing skills than your typical Cupertino turnip - but at least it works.

Welcome to the Beige New World where everybody thinks same and Big Brother loves you.

Not Quite the First Time

This isn't the first time OS X has been hit by an attack of pinheads. Of course it's not. Pinheads by their very demeanour seem to be the perfect employees for One Infinite Loop. It's just that as programmers they're endemically and by definition hopeless and always will be. They're hired on and everything is all smiles and then the code gets the royal shaft. Oops. Sorry, brother.

A while back a pinhead (perhaps the same pinhead but that's doubtful) decided that the twenty year old definition that a Cocoa bundle was opened by itself made no sense because he couldn't wrap it around his little pinhead. So without further ado he changed NSWorkspace.

Years later Apple caught the error and fixed it but as per usual they didn't apply the fix retroactively and so hundreds of vendors and hundreds of thousands of users were left with band-aid code all over the place.

Then another pinhead (can it be the same stupid pinhead all the time) decided it would be cool and groovy to collect metadata on all apps and docs opened and run. Except he forgot to remember (or remembered to forget) that the launch services could in fact pass data from failed attempts to open docs and run apps.

Skills-wise that pinhead's in the same bottom drawer class as our AppKit services pinhead.

And he too undoubtedly walked around in his Beige Euphoria™ muttering to himself 'I wrote code for Apple dude!!1!' and was so very proud of himself. Except his code - like with all these pinheads - is total crap and it too now must be fixed.

Steve Wozniak himself says Apple write the buggiest code he uses. There's evidently something to his claim after all. It doesn't have to be this way but until Apple and their micromanager effect a sea change this is the way it's going to remain.

All the while the serious players, governments and industry wait on the sidelines and try to figure out how they're to react.

'Can we take Apple seriously?' they're asking themselves. 'The hardware looks fabulous and the graphics are dazzling and this new OS is 64-bit - so do we roll with it?'

And then they read things like MASSIVE DATA LOSS and Bill Scott's tale of woe and they dig deeper and discover they've been looking only at the symptoms and not at the disease.

And they're not sure they want that disease. Who would? And no one can really blame them.

No Report

There are two bugs here; they are not being reported to Apple. They are not being reported because Apple never act on bug reports. In the few cases they do act on bugs it's too much exertion over too long a time for the indie developers who are expected to do all the research, digging, followups, etc.

But most of the time developers don't get that far. The Apple bug reporter team are world class but the Apple 'engineers' who catch them in the middle are the snottiest, snarkiest, most unpleasant people in the business who will go out of their way not to fix their bugs BUT TO SIMPLY GET RID OF THE REPORTS.

So these bugs as others will be reported only here.

Cupertino != Miramar

Steve Jobs used to do it right. When he set up NeXT he did it right. He said he'd learned that the top engineers in the software industry were not two or three times better than the average but hundreds of times better. And having said this he went out to find these top engineers and he hired them on. And the rest is history. And legend.

But that was then and this is now. And a different company with a whole different attitude and focus on quality. As for example with the person depicted below. Who was responsible for the entire .DS_Store fiasco but kept quiet about it for eight years, fully aware of what he'd done. And then came out of the closet and admitted he and his coworkers were aware of the bug but in eight years (?) had not got around to fixing it.

If Apple want to play in the majors - and they're indicating they do - they need to stop hiring programmers like this and get back to Top Gun. Otherwise the industry will continue - despite the woes of Microsoft - to regard them as a joke.

See Also
Developers Workshop: Clearly Legal

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.