Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: Problems with changing display Message-ID: <21656@cbmvax.commodore.com> Date: 16 May 91 19:46:21 GMT References: <52749@apple.Apple.COM> <21505@cbmvax.commodore.com> <52861@apple.Apple.COM> <21589@cbmvax.commodore.com> <1991May15.214209.22389@jato.jpl.nasa.gov> Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Organization: Commodore-Amiga, Inc. West Chester, PA. Lines: 62 In article <1991May15.214209.22389@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I "invented" my own method to patch a DOS entry in the device list, >because at the time (1985 - 1986) I didn't know how. There has never been, >especially back then, much information on AmigaDOS. Last year when I com- >municated with a C= former member about my way of doing things (Rob Weisman), >he said that when the C64 was big, developers made up so many ways of doing >things that C= couldn't risk updating the OS. He said that can't happen to >the Amiga and I agree. I realize that for 2.0 some of these "methods" had to >be integrated into the OS, but where does C= draw the line? We can't really draw the line, since the developers are free to do as they please, even though we encourage them to follow all the rules, and provide technical support that can, for example, when there is _no_ legal way to do something reasonable and important, help work out a technique that _we_ can live with in the future. For 2.0 compatibility work (most of the fruits of which will appear in 2.04), the thing was roughly as follows: let's say we have an application that made some mistake or bent or broke some rule, and didn't work with 2.02. We'd consider a fix based on some or all of the following: - Do we know there's a problem, and what is it? - How easy is it to fix? - How much ROM space would the fix cost? - Would the fix affect system performance or RAM use? - How reasonable was the "illegal" thing that the application did (for example, there originally was no supported way of doing overscan, so we've put in tricks to support as many ways as we could, even though some of them were odd) - How many applications are affected? - How badly are they affected by it? - Would the fix compromise the integrity or maintainability of the system? Here are a couple of examples. The registers A0, A1, D0, and D1 are specified as not being preserved across ordinary system functions, but of course some functions may not end up trashing them all. There was one application that accidentally depended on Intuition 1.3's habit of not trashing A1 across a particular function (I forget which). A change in 2.0 meant that A1 was now trash. It was a simple matter to re-introduce the preservation of A1, and now that application runs fine. A different example concerns layer damage. When part of a window is exposed (brought forward or revealed or sized bigger), a REFRESHWINDOW event is sent to it, so that it may redraw itself. Under 1.3 and earlier, layers.library was dumb about SIMPLE_REFRESH windows: if you moved one (even the frontmost one), it would get completely erased and redrawn, for no reason. 2.0 adds the nice optimization that all preservable information is preserved. That means that if you move such a window, no refresh event is generated, unlike 1.3. Well, one program used that trick to learn when its window moved. Since the resulting problem was only a minor cosmetic one, and since restoring 1.3 behavior would have meant a significant performance hit, we let that one lie. >-jeff Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."