On 15 Dec 2003 at 6:14, Philip Aker wrote: > On Sunday, December 14, 2003, at 12:07 PM, David W. Fenton wrote: > > > 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.
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? > > 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 ); Late binding (i.e., runtime), we call it in VB. > 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. Er, wouldn't you have appropriate error handlers that would catch it so that it wouldn't be a fatal error? 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? Is Apple still tweaking API functionality so extensively that the APIs don't work the same? If so, that's a pretty big indictment of Apple at this late date. 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. Win2K added "file protection," that attempts to prevent this kind of thing, but what it means is that files which are not really a part of Windows, 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 (this is what happened with MS's comctl32.dll in c. 1996-98 -- MS started releasing apps built with a version of this library from their development tools that was somewhat incompatible with the earlier versions, but was not yet shipping it with their development tools and prohibited other developers from using it). If that's the case, then Apple is using practices that will cost its development community lots of money and trust. > >> 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. . . . It would? The whole OS, from top to bottom, is being re-architected around the idea of a database-type file system. > 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. > ### > > 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. And these are UI features and don't really mean much, though many of them may very well be enabled by the change in file system. > 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... UI is not everything. In any event, at this stage in the development process, Microsoft *never* commits to final UI design. In any event, that article doesn't go into any detail of what is meant by "not unlike OS X" (which is not the same as "like OS X," of course), but seems to imply that it has something to do with graphics. Ooh, ah, Windows will have a Quartz knock-off, so we, too, can see massive performance degradation just so that we can have user- unfriendly transparent dialogs. I can't wait! An article that actually examines Longhorn in detail can be found here: http://www.pcmag.com/article2/0,4149,1356731,00.asp The overview of that article lists these things as differences in Longhorn: 1. a list of the-same-but-better items (security, communications, collaboration, stability, UI, etc.) 2. .NET in the OS (not an add-on), and managed code (which is more secure and more portable), and all the "benefits" that brings. 3. Next-Generation Secure Computing Base, which is described as "splitting the OS in half," with one hardware layer and one software layer. Of course, this is just marketing, as this has been the architecture of Windows since the release of the first version of Windows NT, back in 1991 or so. Later in the article I find that this is a renamed version of Palladium, which was just Passport on steroids, and really has little to do with "splitting the OS in half," after all. 4. WinFS (built on Yukon, the upcoming release of SQL Server), the new file system. I don't see anything here that is even vaguely copied from OS X. The second page of the article briefly describes the Aero shell, which sounds like a cheap knock-off of Aqua, perhaps a little better copy than the Luna interface of WinXP (which is only very superficially copied from Aqua). Transparency and 3D effects are what are described as the new "innovations" in Aero. To which I say Who cares? This isn't something that is significant -- it's only appearance. Now, if MS implemented a true analog to the Finder, *that* would be significant. I'm sure MS will also implement a copy of Exposé, since it's such a good idea (and it's a pretty simple thing to do, as WinXP already has quick user switching, just not with the impressive and intuitive animation). It looks like there will be OS-level support of wide displays (something that already exists in the Windows world). Perhaps Apple was first to offer wide displays, but it's not clear that this is copying from Apple so much as it is supporting hardware vendors that copied from Apple. Then there's talk of "task-based UI" design, which gives me the willies. I hate wizard-based UIs, as they almost always restrict your flexibilityto get the job done. What would be nice is if MS would allow an "expert mode" of operation that would skip the wizards by default. In Win2K and WinXP, for example, security and user management requires extra clicks because you can't really do the job until you've clicked from the default dialog to the Advanced dialog. If MS would allow me to set a flag that says "always go direct to the Advanced dialogs), I'd be happy. As it is, I just have to do extra work to get there. The examples described in the article sound more like another case of Microsoft putting application functionality in the OS (their example is photo editing), which is just part of MS's longterm monopoly strategy, of course. MS is also apparently going to try to breathe new life into the completely un-needed Active Desktop that was so breathlessly introduced in Win98 and then promptly ignored by everyone because it provided no useful functionality, but simply sapped performance (everyone who knows anything turns it off on first boot). MS has continued to slip it into various components in ways that provide no real functionality yet tend to eat up screen real estate (like the middle pane in Windows Explorer, which displays the details of what you have selected in the right pane, and is completely useless when you've got nothing selected there; and doesn't do anything but take up space in some circumstances). The rest of it looks like expanded hardware and technology support, which is just part of creating an updated OS, not something you copy. There's more on the NGSCB (Palladium redux), with a chart that basically shows that it's a trust-based system. I hardly see how this truly improves security, as it just moves the problem into a different space (how do you know to authorize the OS to trust an app or process?). The one difference is that there is a hardware component of the whole thing, so that it will be built into the CPU. This is, of course, how the DMCA will be enforced, as the OS won't allow you to break the rules set by the content owners. This is probably a bigger change in architecture than the Yukon-based file system, now that I think about it. And it's much more worrisome to me (not that I had any plans to use Longhorn, in any event). But, of course, the new file system is designed to allow you to navigate non-hierarchically, and that would be a major UI switch: http://www.pcmag.com/article2/0,4149,1357941,00.asp I've been saying for years and years that Windows needed a modern file system, one that worked at least as well as the Mac's file system (since abandoned in OS X). My one disappointment in what this article says is that there's no clear indication that Longhorn's new file system will get away from the limitation of name-based file association. That is, it's just bloody stupid to determine which app to load data into based on the name of the data file. Given MS's wild- eyed emphasis on XML everywhere, it would seem to me doubly stupid to maintain that one-file-extension-to-one-application connection, as an XML file is the ideal multi-use data storage format, one that is perfect for loading into different applications for different uses. Other than superficial UI appearance and Quartz copying, I see nothing at all that is copied from OS X. Do you? > ### > > 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). . . . Er, the Windows knockoff of AppleScript functionality was the Windows Scripting Host, implemented in Windows98, and installed by default with IE5, and part of WinME, Win2K and WinXP. Unfortunately, MS implemented it in an insecure fashion, so it is basically totally useless. It was the WSH that allowed the ILOVEYOU vbScript trojan to propagate. > . . . 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. That's a wonderful benefit that OS X users get as a result of being built on top of a UNIX kernel. But I'd hardly say that is something copied from OS X, so much as it is copied from UNIXen in general. But, on the actual point, Windows has been deficient in GUI scripting. But Windows users don't seem to have missed this deficiency. And, of course, the MSH really isn't about GUI scripting so much as it is trying to port to the command prompt a powerful model of functionality found in UNIXen. DOS has always provided a teeny-tiny bit of that functionality. Until OS X, the Mac didn't provide any commandline interface at all. Did Apple copy Windows by providing it in OS X? Of course not! And the existing of the MSH beta (it is only a beta -- it won't necessarily end up in the shipping product) is not by any stretch of the imagination evidence of copying from OS X. It *is* evidence of copying from UNIXen, though, of which OS X is one variety. > ### > > 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. I can't speak about backward compatibility in an OS that is not going to be released until 2005 or 2006. Indeed, there were prerelease rumors that WinXP would not run any DOS programs, but that turned out to be demonstrably untrue -- WinXP runs even ancient DOS programs extremely well. The biggest obstacle to backward compatibility would be, of course, the new security model. But that shouldn't be any big deal to run the non-trusted apps in a sandbox that allows them to work but prevents them from doing anything dangerous (insofar as preventing that would still allow them to work). But let's see the shipping version before we judge it poor in backwards compatibility. In any event, I think users are happy to sacrifice backward compatibility for really enhanced functionality. Mac users managed it with the switch from the original Motorola chip to PowerPC, and it didn't seem like such a terrible hardship. Of course, during the transition period, everybody provided dual binaries. But eventually that stopped, right? Some people are not happy with Apple's decision to no longer ship hardware that boots OS 9. I don't see any analogous behavior by Microsoft at any point. Microsoft *has* been good with backwards compatibility. That doesn't mean they will continue to be, but I can't see any way that they could ever sacrifice their vast user community by forcing them to purchase all-new software in order to run their new version of Windows. But I could be wrong. 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. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
