Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: Information on Amiga Technical Reference Seri Message-ID: <22523@cbmvax.commodore.com> Date: 17 Jun 91 23:25:42 GMT References: <3036@public.BTR.COM> <22455@cbmvax.commodore.com> Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Organization: Commodore-Amiga, Inc. West Chester, PA. Lines: 79 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >I hate to argue the point, Peter, but the documentation doesn't define the OS, >because it (like the code) is subject to change. The documentation is supposed to define the OS, and largely does. We attempt to address areas where this is untrue. You're overlooking that older documenation still holds true, it's just incomplete (doesn't document features implemented after the documentation was written). And, like any definition, it's subject to be improved (as well as extended) over time. >I've bought three full sets >of manuals that are radically different from one another over the years. Right, but you can program according to the 1.1 or 1.3 RKMs and still expect to work pretty well under 2.0. That would not be as true if you took your inspiration from 1.1 or 1.3 source code. >And to >top it off, I get developer support materials that come with the disclaimer that >any information contained within is subject to change without notice. Those are typically distributed in advance of the finalization of the spec. At that time, I suppose you'd want pre-releases of source code. And you honestly believe that preliminary source wouldn't have such a disclaimer? Be serious, the documentation specification can be finalized long before the last significant code changes. >Seeing the insides of routines is an awesome way to learn about programming in >all aspects. Assuming the quality of the routines. The Amiga OS is pretty good, but like any real-world product, it has it's ugly bits. There are also multiple compilers and languages at play, including a few arcane pre-processors. Not only that, but the ROM-writers have certain special priviledges not enjoyed by "external" software. For example, 2.0 Intuition.library is guaranteed to have 2.0 graphics.library available. Your routine based on source to 2.0 intuition.library doesn't have that luxury. As well, if we make a hardware improvement to the Amiga, we can alter the ROM at that time. Therefore we can leave code that's technically incorrect according to the Amiga specification but is 100% correct for all existing machines. We get to change it before the new machine is out. You can't. Nevertheless, we haven't done anything wrong in the ROM. >It is also a good source to start from if you need a routine similar >to one in the OS. Consider the case where you want to do BltMaskBitMapBitMap(), >which the OS doesn't have. Developer support can provide information on how to proceed. The answers they give are sometimes based on their inspection of the source. If you don't ask, you'll never find out. >Seeing the insides of routines doesn't encourage me to rely on the action of what >an OS call does. Good for you. However, that doesn't mean there are no people unlike you. As well, even though we can list dozens of ways in which you could incorrectly rely on the action of a particular implementation, one doesn't need to be too clever to accidentally stumble on a different dependency that one doesn't even recognize until it's too late. >Too many Europeans with A500s programming the Amiga aren't able to access >your support program. It costs money, and they don't want to call long distance. >I'm not demeaning the value of CATS in any way, it's just that CATS can't reach >out and touch every developer. There are plenty of programmers on both sides of the Atlantic who program with insufficient documentation. There is plenty of documentation they can avail themselves of, and the biggest problem is they don't. Someone who doesn't acquire what we make available is unlikely to understand and/or care about the fairly complex issues involved in working from source. We guarantee the functional and structural interface, not the implementation. Therefore, it is entirely natural that we publish the former, and not make the latter available.