Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!news.funet.fi!funic!nic!vinsci From: vinsci@nic.funet.fi (Leonard Norrgard) Newsgroups: comp.sys.amiga.programmer Subject: Re: Information on Amiga Technical Reference Seri Message-ID: Date: 18 Jun 91 01:02:22 GMT References: <3036@public.BTR.COM> <22455@cbmvax.commodore.com> Sender: vinsci@nic.funet.fi (Leonard Norrgard) Organization: Soft Service, Inc. Lines: 196 In-Reply-To: peter@cbmvax.commodore.com's message of 14 Jun 91 15:28:31 GMT In article <22455@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: In article vinsci@nic.funet.fi (Leonard Norrgard) writes: > Now, style isn't everything. Publishing your not all too nice source >code is OK. Style has nothing to do with it. In fact, significant chunks of the OS are in excellent shape, for example Intuition (thanks in large part to Jim Mackraz - hi jimm!) Good. >What *may* scare CBM is clones of the OS. Now it has >already happened to the PC BIOS, Apples ROMS, Apple II ROMs and PC BIOS ROMs are quite trivial compared with the Amiga ROM. Triviality hasn't got much to do with it, I'm afraid. As soon as someone sees a decent margin on the project and they have a customer, it will be done. Not that I'd envy those poor programmers who would have to do it! >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. >IT SURE DOES HURT YOUR APPLICATION DEVELOPERS. 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. When will you tell people it's naughty to write viruses? Do you seriously think virus-writers would follow your recommendation? Will developers start to write viruses when they see the bad guys writing viruses? I think not. 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. Try to decide now, you just said that the OS wasn't ugly. Now you're telling us the opposite. Do you mean that the OS relies on side effects? Have you knowingly designed in side-effects? Hope you're all walking encyclopedias, you must have some memory! Unless you specifically documented the things as side-effects of course. But then it wouldn't hurt anyone, devlopers *can* read comments if they *can* read the code. 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. Is this how Unix ended? VMS? OK, so you'll say that every application will have to be recompiled for each new OS version, maybe even with a change or two. Since most game software seems to not be using the OS anyway, that leaves the "serious" software. Well, if your software supplier doesn't update the software you bought, it will be outdated anyway. If you want the OS to mature and become an accepted citizen in this world, you'd rather accept that backward compatibility isn't everything. 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. The funniest part about it is that one of the Usenetters arguing for sources to be released has recently dealt with a bug in code he is responsible for. The problem was code that was depending on Intuition preserving some fields that in the manuals were specifically _defined_ as being trashed. Under 1.3, they just happened to be preserved. Under 2.0, they weren't. Boom. You can't seriously want more of that? Yes, I want exactly that. A developer who maintains his software, namely. Let's face it: the perfect software package doesn't exist. We all try hard to deliver it, and some even claim they're doing just that. 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! Further, Commodore has a very dynamic and accessible support program. Official developer support is affordable and easy to reach. It's not as homogenous as it could, though. In europe, there's usually quite a long delay (as in 24 hours) before you can have an answer. If the answer needs a clarification, or leads to related questions, add 24 hours again, and so on. I could elaborate on this, but this isn't the right forum. Talk to you in July, when the "accessible support" forum should be available here again *if* the current promises hold (currently after a pause for more than six months!). This has nothing to do with you however, so let's not talk about it. 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. As you probably know, I have done just that (through the appropriate channels, when possible). Most of the time, if there had been source, there would have been no reason for it. And that's not because we're looking for side effects to "benefit" from. Some of the most usual reasons are things like timing, efficiency & algorithms used (maybe your developer community happen to unknowingly sit on faster code?). And as you decribe above, debugging. Why is this code suddenly blowing up? With the source you can check it out and understand it immediately. More important, you'll know if the bug is in the OS or in your own code. Believe me, no developer can afford to test their code agains your *written specifications*. If it doesn't work as it is assumed to, you try 10 different ways before making an OS bug report. Doing those 10 different ways takes time and costs money. Time and money that could have been saved. OS bugs that could have been reported immediately, OS documentation bugs that could have been reported as well, if only somebody had been given a decent chance to pin-point the problem. 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. Good general advice! Do you have the 1.3 RKMs? Yes. Do you have the 1.3 autodocs and include files? No, I deleted them since they aren't up-to-date anymore. What kind of advice is this anyway? Do you subscribe to AmigaMail? Yes. Are you a registered developer? Yes, commercial level. (CBM's highest level for those of you wondering) Do you stay up-to-datewith the Fish Disks and other sources of freely-redistributable stuff? Yes, but *never* trust those sources. You'd be depending on something that isn't necessarily written to the specs. (I'm serious, even if this could be written with a great deal of irony in response to your previous comments about relying on side-effects in the OS.) Do you own the good books that are out there? Yes. Do you run the validation tools we make available (eg. mungwall, enforcer?) Yes, in addition to our own. Start there. I did. I'm still frustrated. Not that I'm looking for any particular bug right now, but I know the day will come, again and again and again. All the time we could have saved. All the time that could have been used for productive programming instead. BTW, are you aware that the September/October '90 Amiga Mail master index for Amiga documentation listed 21 sources for Amiga technical documentation (almost all originating from Commodore). What is this? Distributed documentation? To "do the right thing" usually requires being familiar with all of these. My hat is off to Ken Farinsky of CATS for writing the x-ref, though. >-- Leonard Peter Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. -- Leonard