Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!farrier From: farrier@Apple.COM (Cary Farrier) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: <52454@apple.Apple.COM> Date: 4 May 91 16:58:34 GMT References: <1991Apr30.133904.12649@msuinfo.cl.msu.edu> Organization: Part-Time Programmers Lines: 45 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >They don't publish complete hardware manuals, they don't define a specific >video architecture (planar, chunky, bits per pixel, etc.). They specifically Oh they publish complete manuals, but their existence isn't advertised. For example, if you wanted to know how to access the video memory directly on a Mac II, you need to find the right document, and good luck because it's not where you think it would be. The result is the same, however; the information is not easy to come by. >tell you that (and which) specific hardware features are likely to change. >You are right, that you can make software that works for just one specific >display adapter (that goes to the hardware), but it just isn't done. Apple Most programs that need fast screen updating (animations, etc.) go directly to the video memory on _every_ Apple cpu (even Mac). The original MacPaint did this. >has also radically revved their OS several times, while Commodore has only >done it once (2.0). 1.3 is pretty much the same as 1.0 with a few graphics >library additions and lots of bugs fixed. That's true, Commodore-Amiga could be a little more aggressive in terms of system software revisions. >Programs that follow the rules in the RKMs *exactly* are already >having problems with 2.0. For example, 2.0 allows you to change >the default screen and window fonts. Try changing to a 15 point font >and watch menustrips get screwed up! The whole point of my posting is >that there is NO way to maintain compatibility given the direction >things have and are going. Well you can't protect every user from themselves completely. I don't think that is a good example of a compatiblity problem, because it is a user controlled factor. >(Sonix) pokes the hardware a lot more than the RKMs say you should I wasn't aware there was a limit. As far as most developers are concerned, if it is documented then you can use it. Now when people start reverse engineering libraries and figuring out tricks then I just say "Thou has strayed from the narrow 16/32 bit path and shall suffer the eternal torture of revisions and brimstone" :-). -- Cary