Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Three Reasons 2/3

Apple's 'Leopard' OS remains a system punters can and will adopt but Apple are not within reach of the more important professional market.


Get It

Try It

Apple are now into their fourth release of the world's major 64-bit operating system and according to pundits everywhere things still aren't right. Eventually the previous (Tiger) version will disappear and the single digit user base will use the new system almost exclusively. But that doesn't correlate to anything significant. Apple's OS will remain doomed to the margins.

There are at least three reasons for this. These are perhaps difficult for punters to understand but they're there still the same.

This article addresses the second of these.

Good code gone bad. NeXTSTEP had ten year whiskers when Apple acquired the code in 1997. That represents a lot of hard work. And a lot of debugging. And getting into that code - especially for die hard Pascal programmers - can't be that easy.

'Discovery' is the process whereby a programmer delves into a program or a snippet of code and 'discovers' why it works as it does and more importantly why it's written as it is. Programming is more than learning language syntax: it's also mastering the side effects. Neophytes often never get that far. And wonder of wonders it seems neophytes at Apple have time and again been unleashed on legacy - and impeccable - NeXTSTEP code.

There are countless examples, mostly dating from the 'Panther' period and increasing in frequency dramatically during the 'Tiger' period to go almost literally ballistic in the current 'Leopard' period. All the more reason why 'Snow Leopard' might be a good thing.

'Applications can't open themselves.' The NeXTSTEP 'openFile:withApplication:' group of APIs aren't used much today. For punters there's only one program to open a file - or so they think.

Things are a bit more sophisticated for professionals who have to be able to look at anything with any program. Thereof the API - found for that matter in early pre-releases of Terminal.app.

A curious situation arises when the user interface - such as in Terminal - wants to help the user along by supplying suggestions for either the 'file' or 'application' fields. This can be done by the 'getInfoForFile:application:type:' API.

The program fills in the first field on input and gets the name of the application the system would use to open it on return.

getInfoForFile:application:type:

Retrieves information about the specified file.

-(BOOL)getInfoForFile:(NSString *)fullPath application:(NSString **)appName type:(NSString **)type

Parameters

fullPath

The full path to the desired file.

appName

The application the system would use to open the file.

type

On input, a pointer to a string object variable; on return, if the method is successful, this variable contains a string object with the filename extension or encoded HFS file type of the file.

Return Value

YES if the information was retrieved successfully; otherwise, NO if the file could not be found of the application was not associated with the file.

Availability Available in Mac OS X v10.0 and later.

The hitch is: what happens if you happen to supply the name of an application? A running program can't know from one moment to the next what a user - or other snippet of code - is going to send in.

There has to be an intelligent answer here. And for sixteen years there was. Until Apple turned good code into bad.

The logical - and correct - answer to the above quandary is of course 'the application itself'. What application is used to open /Applications/Safari.app? You guess.

And so it worked - until sometime in 2003 or 2004 when someone at Apple - who will never be known - was in that snippet for another totally unrelated reason, glanced at the code, perhaps understood a bit of what it did - and reacted. Negatively.

'Oh! Oh! Oh! Applications can only open files! They can't open themselves!'

And so it went for over a year. Finally Apple got around to reading their bug reports. And sometime in the autumn of 2005 or spring of 2006 the code got switched back again.

No attempt was made to patch earlier versions - the 'Panther' releases. The fix was for Tiger only. If you didn't have Tiger - then pony up. We're not fixing Panther, sucker.

And the fix took years. For such a simple thing. For such an inexcusable blooper.

  • Leopard Mail's crashing on dock drops. Tiger Mail was fine. What happened? Good code gone bad..
  • Neither Leopard Mail nor Leopard Safari can figure out how to interact with the AppKit services. Mail and Safari used to be able to do this; now they can't anymore. Good code gone bad. Do a Google: you'll find these are issues people have been complaining about for over three years. Things used to be fine; now they're not. Good code gone bad.
  • The bugs in Apple Mail are today too numerous to mention. The question sane developers and users are asking is: how could Apple have let this happen? The program used to work wonderfully - flawlessly. Good code gone bad.
  • Apple shipped Leopard 10.5.0 with a dysfunctional ActiveDirectory. Admins were taking salary hits because of it. This is code that used to work great. So what happened - besides the lack of QA with a major OS release for such an important function? Good code gone bad.

There are countless examples. And many of them date back to 'Tiger' 29 April 2005 over three years ago. What happened?

Same answer every time. Good code gone bad.

And how does a Leopard Safari surfer handle cookies? Here's a typical scenario. Joe Surfer visits a dozen or so sites and wants to clean the cookie cache. This is what it looks like when he opens it.

Joe Surfer wants to get rid of his New York Times and Guardian Online cookies. Should be easy. He starts by selecting the first New York Times cookie. He then holds down a shift key and selects the last New York Times cookie. Things now look like the following.

He next selects the first Guardian Online cookie by holding down command and clicking on it. This preserves the first selection of the New York Times cookies. Things now look like the following.

He now proceeds as he has for the past ten years of OS X: he holds down a shift key as before and clicks on the last Guardian Online cookie. But what happens?

Good code gone bad.

People have patience with a new system. Even corporations have patience. A bit at any rate. It can take time to iron out all those wrinkles. People are OK with that.

What people - what corporations - are not OK with is seeing what used to work suddenly no longer working. What they can't understand - what they won't ever understand - is how a company can take perfectly good code that's worked admirably and perfectly for almost twenty years and systematically ruin it.

And that makes the news of 10.6 'Snow Leopard' all the more interesting.

See Also
Developers Workshop: Three Reasons 1/3
Industry Watch: 10.6 A Maintenance Update?
Hall of Monkeys: That Wobbly House That Steve Jobs Built

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