Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!samsung!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: <22538@cbmvax.commodore.com> Date: 18 Jun 91 14:19:50 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: 145 In article vinsci@nic.funet.fi (Leonard Norrgard) writes: >In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: > In article vinsci@nic.funet.fi (Leonard Norrgard) writes: > >Reverse engineering is of course much simpler if you have > >source > > Reverse engineering is quite illegal if you work from the source. There's > nothing reverse about it then. > >"Reverse engineering" is writing specs from *something* and then have >someone else, who didn't check out *something*, implement it from the >specs. Like the black box you all want us to think of. Of course, I'm >no lawyer, and especially not a US lawyer. I do believe you're agreeing with me, and contradicting yourself. You said that reverse engineering is simpler if you have source. Now you say reverse engineering is done from a black box spec. Thus, you see my point. > 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. > >Of course, every developer is a child and from this follows that >Commodore must babysit every developer. With every rule you can come >up with, someone is going to break it no matter what. It is in our right and to the benefit of Amiga customers to act in a manner that will best preserve the future of the Amiga. The specific aspect of that which is at hand is "how shall we best ensure that the OS and the hardware can continue to evolve and have significant compatibility with third-party software that preceeds it?" It is in our commercial interest to do so, and we have every right. We take steps to maximize the ease of writing correct software, and minimize the kinds of information that can lead to incorrect software. >tell people it's naughty to write viruses? Do you seriously think >virus-writers would follow your recommendation? I agree with you that there are people out there who violate the rules we have today. However, it does not follow from that that if we release source, with far more complex rules, that things won't get worse. They will. > Seeing the insides > of routines will only encourage developers to take advantage of tricks that > are not part of the definition and not supportable. >Try to decide now, you just said that the OS wasn't ugly. Now you're >telling us the opposite. Please stop stuffing words into my mouth. Please re-read what I have written. _Some_ parts of the OS are very nicely written, but as in any real-world project, not all parts are so nice. >Do you mean that the OS relies on side >effects? Have you knowingly designed in side-effects? We can (and do) change the ROM when new hardware or software comes out, and _every_ user of an Amiga has an appropriate ROM. The same cannot be said for application software. > 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. > Someone from West Chester recently wrote here that more >than 50% (if my memory serves me right) of the 2.0 development time >was put in areas meant to maintain bug-level compatibility with old >software. IMHO, this is not sane. Let's continue on this track and in >7 more years, the Amiga will be then what the PC is today. Backwards >compatible, but nothing you'd really want. Your memory fails you. A few months of time for several engineers, that's all. You're missing the point that the acceptance of 2.0 is critical for its success, and therefore anything (such as increased compatibility) that helps the acceptance is a friend of you and of me. Please trust us when we assure you that by and large we did not insert kludges that compromise the integrity, maintainability, or future of the OS. There were things we could fix, but only in ways we deemed unacceptable. Here were some of the criteria for deciding if a kludge would go in. Based on those, you should be able to rest knowing that the process was extremely sane: 1. How many applications are affected? 2. How seriously broken are they? 3. Was the incorrectly-coded section a fair attempt, or blatantly stupid? 4. Was there any documentation on this issue, and how clear was it? (a good example is overscan: there was no approved technique for a while, and it was important; therefore many different techniques have been made to work) 5. How much of our time and ROM-space would be needed to fix the problem? 6. Would the kludge entail a serious performance penalty? 7. How would it affect the long-term future of our system to put in the kludge? The final decision was a carefully considered weighted decision based on questions such as these. Also, our interface is pretty well-defined. Which means that the kinds of kludges we did have to put in tend to affect the integrity of the system the way they've hurt other machines. Not only that, but we've kept a list of what we've done, so we can make that available, and also write tools that re-break kludged software, so a developer could tell if he was accidentally relying on such a kludge. >Customers who don't make sure they're running with the latest >(or so) version of a package take unnecessary risks and likely have >problems they need not have. So what do I do with 1.3 software that >hasn't been upgraded to be 2.0 compatible? It's either the trash can, >or if I need it real bad, I boot a machine in 1.3 mode. Usually there >is better and compatible software on the market, so no big harm is >done anyway. The developers who properly maintain their software will >get my money again and again, this while I'm still happy! There were a large number of first-rank applications that didn't run under 2.00. A large number now work under 2.04. Face it, even the person with the best intentions can write software that may have a bug that will only appear when a new processor, OS, or machine comes out. The active developer will always have an advantage, and Commodore DOES encourage active developers. However, we will not do this by avoiding easy modifications that make existing copies of software run again. I remain unpersuaded that there are sound technical reasons for releasing the source. Even if there were, there exist sound non-technical reasons to hang on to it. It doesn't have to be a whole lot more complex than that. > Peter > > Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. > >-- Leonard 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. "Gosh, didn't he have anything positive to say at all?"