Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!news.arc.nasa.gov!vsi1!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: Information on Amiga Technical Reference Seri Message-ID: Date: 20 Jun 91 09:33:05 GMT References: <3036@public.BTR.COM> <22455@cbmvax.commodore.com> <22523@cbmvax.commodore.com> Organization: Amiga makes it possible Lines: 89 In article <22523@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > >>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. > Hey, if I could step through beta OS routines with CPR or SDB with FULL source, I would be able to give you REAL accurate bug reports. I could tell you what file had the bug, what the problem is, and what to change to fix the problem. >>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. Make it all available in machine readable form. Just make sure it all makes... >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. > The rules for writing applications are well known, and you are always going to have to rely on us developers to tiptoe around the ugly bits. Some of the ulginess might get shaken out even. How about warning us developers way in advance of any hardware changes, so we can prepare our source code as correctly as possible as early as possible. >>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. > When I see the source, it is like the programmer speaking directly to me in the most natural language available for expressing algorithms. The transfer of this level of understanding of the source code through a third party is nowhere as good as seeing the code. >>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. > Let the reviewers flame away. Good products should get support for a long time to come. Some products have already been supported for years already. As these apps mature with your OS, you get progress. >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. Put all the disclaimers you want on the source code. Why not put the RKM in machine readable form, too? There are a lot of program fragments that would be nice to be able to cut and paste from. An on-line manual with documented source could be put on CD-ROM and would be an excellent thing to go with a CD Drive machine. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************