Well, the question was over testing by Coda of a new version. If it ran without a hitch on Jaguar why wouldn't it also run without a hitch on Panther?
Coda is trying to support a wide range of MacOSes and items marked deprecated but still supported in Jaguar are now gone in Panther (it is a major release). As others have remarked, Macintosh Finale is sufferin' in Classic because of the past policy of only making the minimum changes necessary to get Finale to run on the latest MacOS.
Like to tell an object to perform some method not known at compile time with some parameter(s) not known at compile time...
Late binding (i.e., runtime), we call it in VB.
What I've described is not the same as C++ "late binding" for template instantiation at all. I'd be very surprised if VB was coded in Objective-C.
Now, because the existence of 'steakAndLobster' doesn't error at compile time...
Er, wouldn't you have appropriate error handlers that would catch it so that it wouldn't be a fatal error?
I would. I can't speak for anyone else, and as I mentioned before, I'm not the best person to explain the objc_msgSend() concept.
And exactly how would the API being written to be changed in a way that would break code that works in .1 and then breaks in .2 of that API?
If you're talking about Finale betas, I can't comment. If you're talking about something else, I'd need specifics.
Is Apple still tweaking API functionality so extensively that the APIs don't work the same?
These days, Apple's policy seems to be to upgrade ("tweak" is a little mild) the Cocoa frameworks to enhance functionality for the current and future OS version(s). But we're still at the same point of programmers sticking to missionary position API usage in order to insure upwards compatibility.
If so, that's a pretty big indictment of Apple at this late date.
Only in your book David.
Of course, there's an API and then there's an API. Microsoft's "official" APIs are only a small part of what real application programmers depend on to build applications. Most people use shared components provided by MS development tools, and when different applications try to install different versions, it causes problems.
This is not a factor in OS X for Cocoa or Carbon. It can be a factor with some Unix programs/applications because they would have all been developed on other unices, with dependencies based on other systems' library particulars which could not possibly have accounted for Darwin in the past. If a unix-based product updates system libraries, then all bets are off.
... but libraries provided with MS development tools, end up as de facto parts of the OS. And if MS decides to change them, it can potentially break other people's apps ...
If that's the case, then Apple is using practices that will cost its development community lots of money and trust.
It's not the case.
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. . . .
It would? The whole OS, from top to bottom, is being re-architected around the idea of a database-type file system.
HFS is a database-type file system. It's not gone in OS X.
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.
Changing to a file system that is stored in a database (it's going to be SQL Server, so far as I understand it) really is a change that trickles up to every level of the OS, for it provides functionality of a type that a non-database file system can simply not provide as efficiently.
You could search for info on Apple's patented (and very awkwardly named) "piles" thingme and arrive at a few conclusions about file presentation (note the date of the patent as well).
In Cocoa, those kinds of concepts are called "Views" (as in MVC: Model-View-Controller). They are already being used in Xcode and as of Panther in the Finder (it was previously Carbon but is now Cocoa).
A sidebar being that if you want to find out what Apple's exploring for possible implementation in an OS down the line, spend some time with Apple's Developer Tools.
From your description, I understand that M$ is trying to make the colossal, one-and-only, FILE SYSTEM. That's not Apple's approach at all. For them, it would be just another file system to support which has x, y, and z characteristics as differing say from UFS which has u, v, and w characteristics. That's the "Model" part of MVC.
[...copious snip but I read the entire articles...]
Other than superficial UI appearance and Quartz copying, I see nothing at all that is copied from OS X.
Do you?
Yes. You assume that the nuts and bolts define the difference. That can't be so because 1): the OSes are currently deployed on different architectures, and 2): there's this really ugly albatross centered about technology copyrights and corporate patents. UI isn't only appearance. It is also a communication method (a language) and facilitation for the user.
Gates (the person) is incapable of conceptualizing at this level. If you have seen a TV clip or other media presentation, you should be able to deduce this immediately from his diction and body language. Without really knowing how it works, Gates does conclude once again however that Apple has him by the short 'n curlies in UI expression, and has directed the rip-off implementation Windows users may see in Longhorn.
I'm not getting the feel from your remarks that "UI as a language" concepts are being perceived because you pooh-pooh them as being "superficial". And I fear that because you've been more involved with Windows than most folks on this list, over exposure to Microsoft corporate-speak has you duped into bypassing the whole area. If I could make an analogy by way of language, Gates is illiterate in the one called UI.
And once again, Apple's foray into UI design is now approaching artistic levels. You would actually have to experience Panther OS X for sometime personally to verify my assessment though.
I can't speak about backward compatibility in an OS that is not going to be released until 2005 or 2006.
OK. That's all I was saying before.
Of course, during the transition period, everybody provided dual binaries. But eventually that stopped, right?
For 68K yes. However with application packaging, it's possible to provide multiple executables (Carbon, Mach-0, unix tool, etc.) for multiple architectures.
As to any copying from OS X in Longhorn, I see no evidence of anything but very superficial copying. In terms of UI design and underlying OS structure, there is very little in common, except what is going to be in common between any two modern OS's.
See above. I truly worry that UI-As-Language has been omitted from your repertoire. Unlike Gates however, I perceive you as being more than capable of handling those concepts.
Philip Aker http://www.aker.ca
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
