Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!elroy.jpl.nasa.gov!news.arc.nasa.gov!vsi1!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Message-ID: Newsgroups: comp.sys.amiga.programmer Subject: Re: Information on Amiga Technical Reference Seri Distribution: world References: <3036@public.BTR.COM> <22455@cbmvax.commodore.com> Date: 15 Jun 91 19:23:57 PST Organization: Amiga makes it possible In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >If you think not having source will hurt application developers, you've >not begun to imagine the long-term hurt to users and developers which >would be caused by releasing the source. Why? Because there seems to >be some confusion that the _implementation_ of the OS is its definition. >Nothing could be farther from the truth. The documentation is the >definition, and the implementation is subject to change. Seeing the insides >of routines will only encourage developers to take advantage of tricks that >are not part of the definition and not supportable. It would effectively >mean either the end of OS development or a significant down-turn >in compatibility with future revs of the OS. We won't allow it, >and you shouldn't want it. > I hate to argue the point, Peter, but the documentation doesn't define the OS, because it (like the code) is subject to change. I've bought three full sets of manuals that are radically different from one another over the years. 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. It's also interesting that I have at least 4 different (I don't mean copies - really different) sets of 1.3 header files... Seeing the insides of routines is an awesome way to learn about programming in all aspects. 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. You could roll your own by taking the source to BltMaskBitMapRastPort() (that is a mouthful :) and hack out what you don't want. If you want to encode/decode MFM with the blitter, you could reinvent what CBM has already done, or you could just go look at the source and take what you need. The apps that use routines done this way won't at all break under future OS revs or anything. Seeing the insides of routines doesn't encourage me to rely on the action of what an OS call does. Not having source code hasn't prevented this from being a problem anyway. >Further, Commodore has a very dynamic and accessible support program. >Official developer support is affordable and easy to reach. Unofficial >support is provided on places like Usenet by CBM employees who aren't >required to be here. If you have a question, ask it, instead of >asking for the source. 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. >And before you ask for the source, be sure you avail yourself of >the existing documentation and tools that exist to make your >life easier. Do you have the 1.3 RKMs? Do you have the 1.3 autodocs >and include files? Do you subscribe to AmigaMail? Are you a registered >developer? Do you stay up-to-datewith the Fish Disks and other sources >of freely-redistributable stuff? Do you own the good books that are out >there? Do you run the validation tools we make available (eg. mungwall, >enforcer?) Start there. > All great things to look for/at. If CBM ever did publish the source, why not ship all the machine readable files you can find with it. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************