The one thing about OS X that I don't really understand is why a .x upgrade would break programs that ran well on the previous release. What's that about?
I'd have to have a specific example to comment.
Is Apple removing functionality that existed in the previous release? Surely they are not adjusting the base APIs with every release? Or, if they are, they're doing it in a way that wouldn't break applications written to the earlier API? Obviously, that can't be it -- would it be the window manager that is causing the problem (Aqua/Quartz)? Or? I simply don't know enough about it to understand what level is causing existing software to fail in the new releases.
Perhaps we're encountering the same kind of issue you mentioned previously: "The smart ones programmed for the Win32 API". Generally, if programmers follow the recommended migration path, there aren't any problems. Stands to reason this is true for any platform. In the case of Carbon, this is very clear. In the case of Objective-C (i.e. Cocoa), similar things can be very tricky. I don't know if I can explain them that well but: In Obj-C it's possible to do some things unheard of in the C/C++/Pascal worlds. Like to tell an object to perform some method not known at compile time with some parameter(s) not known at compile time. This would be a call something like:
objc_msgSend( theButton, @selector( setHidden: ), NO );
Here 'theButton' is a real and known object type, but the selector and it's accompanying data value are only determined during runtime and won't actually error until theButton receives the message. A programmer could write anything there:
objc_msgSend( theButton, @selector( steakAndLobster: ), salad:YES, dressing:@"1000 Islands", potato:@"baked" ).
Now, because the existence of 'steakAndLobster' doesn't error at compile time you can probably see that unless the developer keeps abreast of OS changes diligently, things will slip through. Technically, it's not an OS error, it's a developer error.
I think the fairer assessment of MS vs Apple's backward compatibility handling will come about whenever MS can get the Longhorn edition out the door. Let's see how F2K2/F2K3 does on that system because it's supposed to be Gate's rip-off of MacOS X features.
Oh? Exactly how is the new file system (which is really what Longhorn is about) a ripoff of of OS X? It's a lot more than journalling (and journalling file systems are not new on UNIXesn, in any case, just something that OS X recently got).
I didn't mention file systems specifically, but it's been possible to turn on journalling in OS X for quite some time. In fact, interpreting "file system" as the only significant thing in Longhorn might belittle it. But I guess that's why one can feel sorry for Microsoft users. I mean it seems you're relegated to talking about nuts and bolts like file systems whereas with Macintosh, the emphasis is abstracted several levels up and in the area of facilities for creative expression.
###
A casual google for "Longhorn features" shows me the M$ equivalent of desktop presentation stuff that is already done in Panther. OS X features which will surely be more advanced by the time Longhorn makes it out of the starting gate.
From: <http://www.technewsworld.com/perl/story/32027.html>
The Longhorn spec, which will be fluid until the product is released to manufacturing, is covered in detail in other articles. But, in general, the operating system will have a user interface not unlike Apple OS X...
###
One item which more than illustrates how behind-the-times Microsoft is in software concepts is the touted 'msh' -- which claims it can script objects: <http://www.zefhemel.com/299.php>.
Pshaw! Guffaw!
Macintosh has had object oriented scripting since 1987 (HyperTalk->AppleScript). As of OS X, we also have built-in support for tclsh, python, ruby, java, tcsh, bash, zsh, and sh, and 100s of traditional unix tools. All of these are accessible from AppleScript. You can pipe from shell calls to AppleScript. Furthermore, 10.2.3 and up supports scripting UI objects.
###
Backwards compatible?
From: <http://news.com.com/2009-1016_3-5103226.html>
The next operating system, code-named Longhorn, promises... But those features come at a price: Most can be used only through client software that's designed specifically for the new system.
Philip Aker http://www.aker.ca
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
