Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: Short Hello World Message-ID: <21825@cbmvax.commodore.com> Date: 23 May 91 00:15:45 GMT References: <1991May18.172039.7477@batcomputer.tn.cornell.edu> <1991May20.143242.10424@starnet.uucp> <21779@cbmvax.c Organization: Commodore-Amiga, Inc. West Chester, PA. Lines: 106 ommodore Sender: Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Followup-To: Distribution: Organization: Commodore-Amiga, Inc. West Chester, PA. Keywords: In article mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >How long is "a long time to come"? Five years? Ten years? Until >development on the Amiga stops (which could well be shorter than the >previous two)? And why have CBM employees said that those writing 2.0 >code shouldn't be shouldn't be using OpenWindow()? If you're going to write 2.0-only code, you'll almost certainly want to take advantage of what OpenWindowTags() has to offer. But I'd be surprised if anyone at CBM has recommended against using OpenWindow(). But, there are a lot of people working at CBM, and their words are not policed, but their words are not policy either. I'm not in a position to state policy, but I can tell you that I'd be surprised if OpenWindow() stopped working between now and the next significant upgrade of any major product. >On the other hand, realizing what happens to systems that retain >compatability for everything that they ever supported takes looking at >one. I don't really recommend doing that; it's not a pretty sight. >Even trying to stay source-level backwards compatable while adding >modern features leads to odd things over the course of a decade. You seem to be implying that maintaining compatibility is universally damaging to the integrity of the system. Whenever we consider having to migrate people over to a new method, some thought is given to how expensive it is to support the old method. Plenty of compatibility measures (even some that cover blatant application bugs) do not in any way compromise the integrity, maintainability, or any other aspect of the future of the system. A well designed system such as the Amiga is more resilient in that regard than older computers where things like ROM-jumping was the norm. >Planning for the best implies assuming that some of the backwards >compatability hacks in 2.0 will vanish in the future. Once you assume >any of them will vanish, you might as well assume all of them will >vanish, and code accordingly. Sure, some of the hacks may vanish. However, a good example of a hack that won't need to vanish is one Intuition routine (I forget which) that explicitly preserves A1. Why does it preserve A1? Because it turned out that under 1.3, A1 was unmodified, and some application assumed that. Well, that's a pretty serious application bug. What does it cost the OS to preserve A1? Absolutely nothing (the code even came out to be the same size). I wouldn't bet my life that that kludge will remain in, and I expect the affected developer to correct the mistake for his next release. But I wouldn't be sweating bullets if I owned and used that application. There are hacks in there which are considerably uglier, and have impact on system performance, and those indeed risk vanishing over time. However, support for OpenWindow() in 2.0 is not a hack. OpenWindow() is a well-defined entry point and has been since time immemorial. We certainly have a greater obligation to support defined features than undefined side-effects. And when you consider the implementation of OpenWindow(), it looks something like this: struct Window *OpenWindow( struct NewWindow *nw ) { struct TagItem *tlist = NULL; if ( nw->Flags & NW_EXTENDED ) { tlist = ( ( struct ExtNewWindow * ) nw )->Extension ); } return( OpenWindowTagList( nw, tlist ) ); } Absolutely nothing in there compromises the future of the OS, and the OS will not be left behind in the dust because of things like this. And it's still a viable thing to write code that works under both 1.3 and 2.0. Thus OpenWindow() is still very much a current function. For OldOpenLibrary(), the case is different. Nobody NEEDS to use OldOpenLibrary(), since nobody should still be running AmigaDOS 1.0. So anybody that thinks they really _want_ to use OldOpenLibrary() is just plain silly. But worrying about whether it might vanish any time soon is far sillier. >Of course, it may be that you'll have an AmigaDOS with 20 years of >backwards compatability built into it. I won't - I'll have moved on to >a modern OS (one that's less than 15 years old) years before that. Please trust us to chart a successful future for AmigaDOS. We do have half a clue as to what can stay and what needs to go to keep AmigaDOS up-to-date, fun and efficient to use and program. >