macOS What is causing the Leopard incompatibilities

saltyzoo said:

On another thread I asked why an application would not work in Leopard and the answer I got was "Some applications look at the version number and won't run if it's not an approved version. All the developers have to do is recompile and their app will work".

That's nonsense.

I don't understand why so many applications are not working "out of the box" with 10.5. As an experienced developer in windows and unix, but a newcomer to OS X this is a little disconcerting.

What are the major causes of incompatibility with Leopard?

Click to expand...

1. Apple Bugs (Regressions)
2. Devs Using Undocumented API's to work around things they see as limitations.
3. Unable to test. We don't even have the final build until everyone else does... therefore we can't test on the final build!!

Usually its changes in the frameworks, such as removal of deprecated functions/classes, or slight behavior changes. Or it's just bugs on Apple's part.

saltyzoo said:

On another thread I asked why an application would not work in Leopard and the answer I got was "Some applications look at the version number and won't run if it's not an approved version. All the developers have to do is recompile and their app will work".

That's nonsense.

I don't understand why so many applications are not working "out of the box" with 10.5. As an experienced developer in windows and unix, but a newcomer to OS X this is a little disconcerting.

What are the major causes of incompatibility with Leopard?

Click to expand...

I find it surprising that so many programs work, not the other way around (and this is not a dig at apple or developers).

Basically no one wants to put out a program on an OS they haven't used yet. There might be a bug that makes the user lose all his data. What would you prefer? A program that doesn't work or a program that inadvertantly deletes all youf files?

It's therefore safer to restrict what newer versions run on, even if they will run perfectly (although it would be nice if you could force run them).

Windows has it's share of programs that won't run when a new version comes out, and don't get me started on linux... even "recompiling" from scratch won't get every program working on a new distro.

Come back to us in a months time and complain about the programs that still don't work then. Leopard was only fully released today.

saltyzoo said:

An API, by definition should not change it's behaviour from one minor release to the next in such a way that would destroy data.

Click to expand...

Leopard isn't "minor". I'd consider it major.

saltyzoo said:

That's not the point. A new release of an API shouldn't be breaking existing software. I'm sorry, but thats horribly sloppy IMO and I'm sad to see it is so. It is not what I expected from Apple.

Click to expand...

How long have you been using the Mac? This has been the situation for a while. Developers are used to it, and are usually on the ball on getting updates out, except in this case Apple isn't letting us access to the GM early

saltyzoo said:

An API, by definition should not change it's behaviour from one minor release to the next in such a way that would destroy data.

Click to expand...

You clearly are not a programmer and you clearly were not around during the earlier transitions of OSX from 10.1 to 10.2 to 10.3 etc... Apple made a lot of changes to the underlying core of OSX which broke a lot of programs. People are just protecting themselves.

I wasn't talking about an API either, i was talking about a program.

saltyzoo said:

That's nuts.

Click to expand...

Not nuts, if you were a programmer you'd understand.

saltyzoo said:

Not on the planet I live on. I can count the number of problems I've seen with applications not being forward compatible from win98 to win2k to win xp on one hand.

Click to expand...

That's true, mainly because MS spends a lot of time and money making sure that older programs will work perfectly on newer versions of windows. That's why windows has some lingering stability and security problems stemming from older versions.

Apple on the other hand has been known to make drastic changes and this leads to glitches in older software. This also makes OSX itself faster and more stable.

saltyzoo said:

That's not the point. A new release of an API shouldn't be breaking existing software. I'm sorry, but thats horribly sloppy IMO and I'm sad to see it is so. It is not what I expected from Apple.

Click to expand...

It depends how you define sloppy. Is supporting an old out-of-date API worth it? Making your brand new OS backwards compatible at the expense of speed and stability?

Or is it better to take the old API, find all the inherent problems in it and update it to be better, faster and more stable. This leads to problems with older software but certainly isn't sloppy.

Windows is slowed down by older API's, OSX speeds itself up by getting rid of older API's and using new or upgraded ones, linux on the other hand is really fast because it doesn't use API's (for the most part) which means it takes more work to support newer versions.

You as you mention are a developer. So this should be no surprise to you.

What surprises me is you insistance that Apple should do what MS do.

After reading what Raymond Chen has do with wanktastic pieces of sh*t on Windows from Adobe and other third parties (last count 3000+ pieces of compat code), I fully understand what Apple decided with OS X that they were not going to add compatability code to the kernel and other layers to get around idiot developers writing code that relies on a side-effect that will be removed in a later release.

As the previous poster stated this isn't common.

saltyzoo said:

Not on the planet I live on. I can count the number of problems I've seen with applications not being forward compatible from win98 to win2k to win xp on one hand.

Click to expand...

Well, I dunno what planet you do live on, but it evidently ain't the one I'm living on.

I make my living as a systems admin (both Windows and Macs) and have been doing so for some considerable number of years. Every time we've move to a new version of Windows there's a ******** of incompatibilities - to the point that I generally don't even CONSIDER in-place upgrades any more - we only move to a newer version when we switch the machine. We're currently unable to install Vista machines because our CRM application (from a major developer, btw) won't even install on Vista...

OS X, by comparison, causes me very few problems. Today, I've upgraded a Mac here to Leopard as a test. One minor utility (one I knew about in advance btw) was broken. Everything else, including all major applications, works just fine (and there's a LOT of software on this box). This is entirely in line with prior experience.

Apple have a really good record in this area - I've seen nothing to suggest that they're getting any worse at it.

saltyzoo said:

Ok, I'm dumb, your smart, I'm ugly, you're pretty. Happy now?

Click to expand...

Very

saltyzoo said:

Well, my bosses at a major US financial institution are going to be pretty pissed off when they find out that the last 15 years of C++ and java code I've given them was written by someone that isn't a programmer.

Click to expand...

Are you in the 90% or 10% bracket?

saltyzoo said:

The whole POINT of an API is so that changes can be made without rewriting the software. If you were a programmer you'd know this. (That last comment is a joke at your expense, I'm not actually suggesting you aren't a programmer)

Click to expand...

What if the the programmer is using a "glitch" in the API which gives them the result they want. However this is then fixed in the next version? Technically the API is the same but causes trouble for them.

What if the programmer uses undocument parts of the API which only apple use internally. These might give more control or better performance for the programmer but can be changed by apple.

saltyzoo said:

If an API call says it will do something it should continue to do that something in a new release. If you have further features or changes in behaviour you add new calls, you don't "break" the old calls. If you were a programmer you'd know that.

Click to expand...

A program which uses all the API's exactly as they should be used will have no trouble whatsoever. It's only the programs which use undocumented features will have problems. These are normally the programs that don't work.

saltyzoo said:

Look, I'm not a hater, I've had my mac a month and there is no way I'm going back. But I'm shocked that so many things are broken. It just shouldn't be that way.

Click to expand...

Actually i'd be interested to know what is actually broken?

saltyzoo said:

The changes to the API's are pretty minor.

Click to expand...

API changes aren't the main cause of incompatibilities, it's implementation changes that cause the really sticky problems, and there are massive changes in implementation throughout the frameworks in Leopard.

Aside from the bugs that are fixed and the bugs that may have been introduced, it's unavoidable that certain undocumented behaviours are going to change in a way that breaks someone's code. Badly written code will be the first to break.

saltyzoo said:

I've not upgraded. I'm not having problems. As I stated above, perhaps I'm putting too much stock in the reports on the various threads.

The whole point of my post was to find out what was causing the problems. If it's programmers using undocumented API calls they shouldn't be, then that's fine. Or if Apple made some huge change that I just wasn't aware of. That's what I want to know. That's why I posted the thread.

Click to expand...

What programs have you read about? I'm interested to know. I know parallels and VMWare have problems but those use a lot of low level hooks.

No, that's not really the answer, at least not in an obvious sense. The loss of parts of Carbon and the new Objective-C runtime only apply to 64-bit applications - in other words, it doesn't apply to any existing applications.

What you can get from this is that Apple has gone through the frameworks with a fine-toothed comb to make sure everything works in 32-bit and 64-bit mode, and, in the case of Cocoa applications, with and without garbage collection turned on. That's what I meant by "massive changes in implementation". That doesn't make 64-bit support a direct cause of problems, it's simply a general rule that the more you rewrite a bit of code, the more likely it is for its behaviour to change in unexpected ways.

Oh right. I think when you posted the other day, everyone was still in NDA mode, that's why you got responses in the most general terms.

To be honest, it's a miracle to me that so much software is still working...

saltyzoo said:

If an API call says it will do something it should continue to do that something in a new release. If you have further features or changes in behaviour you add new calls, you don't "break" the old calls. If you were a programmer you'd know that.

Click to expand...

Applications compiled for older versions of the OS will continue to use the the old behaviors if API changes are made. This goes for depreciated API's as well. This has been Apple's stance from the beginning. Apps that cease to function properly on the new os are either using undocumented API's, recompiled for the new OS and tripped over a bug, not using API's correctly (try subclassing NSManagedObjectContext) or Apple has introduced bug a regression (Apple did just gut almost every framework in the OS to add garbage collection and 64-bit compatibility...). These are the reasons some apps don't work perfectly, end of story.

Fukui said:

Applications compiled for older versions of the OS will continue to use the the old behaviors if API changes are made. This goes for depreciated API's as well. This has been Apple's stance from the beginning. Apps that cease to function properly on the new os are either using undocumented API's, recompiled for the new OS and tripped over a bug, not using API's correctly (try subclassing NSManagedObjectContext) or Apple has introduced bug a regression (Apple did just gut almost every framework in the OS to add garbage collection and 64-bit compatibility...). These are the reasons some apps don't work perfectly, end of story.

Click to expand...

I would say the majority of it boils down to programmers using undocumented APIs (I have done it from time to time, but try to retool the code once it is functional), and using deprecated APIs... with some random library issues to boot.

I ran across one bug where a developer's app wouldn't launch on Leopard because he directly linked against a particular version of a low-level library included in Tiger instead of the version-independent one. Mistakes get made, we forget to clean up code...