Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!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 Summary: long live source availability! Message-ID: Date: 21 Jun 91 02:29:57 GMT References: <22455@cbmvax.commodore.com> <1991Jun19.171539.5525@batcomputer.tn.cornell.edu> Sender: vinsci@nic.funet.fi (Leonard Norrgard) Followup-To: poster Organization: Soft Service, Inc. Lines: 108 In-Reply-To: riley@theory.TC.Cornell.EDU's message of 19 Jun 91 17:15:39 GMT In article <1991Jun19.171539.5525@batcomputer.tn.cornell.edu> riley@theory.TC.Cornell.EDU (Daniel S. Riley) writes: In article , vinsci@nic.funet.fi (Leonard Norrgard) writes: >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. A ridiculous argument. Peter says that OS routines may have side effects which developers should not depend on, and you somehow conclude that the OS depends on these side effects. Entirely specious... Reread it. The argument is rather simple: the os has, of course, built-in side-effects (without them, some things would be terribly ineffective). So that the WC people know why this code is there, it has to be documented as side-effects, when they knowingly rely on them. If they weren't documented, I'm sure they'd all tear their hair out each day. However, the last time I saw the team, they weren't bold, so I assume that is false and thus side-effects are documented. Well, system/application programmers aren't different from os designers/programmers. If *one* can read those comments, then the other can as well. Seems like a dead horse to me. :-) > 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. Guess what--even if you had the source, you *still* need all that documentation. The source only tells you what the implemented behavior is; you need the documentation to tell you what the defined behavior is. Nobody has disagreed on this point. The usefulness of source code are in the debugging area, avoiding the re-invent-the-wheel syndrome, making good choises of what routines to actually use (relative timing, and before you scream: I'd rather call the faster routine with this version of the os and risk loosing speed in a future version: that can be optimized in upgrades, which are inevitable anyway. Calling the slower thing now is definitely more costly). Programming to the implemented behavior without referring to the defined behavior of the OS is exactly why Commodore doesn't want to release the source. Why do they release the OS then, when people write viruses for it? The answer is that you'll never be 100% secure anywhere or with anything. Knowing this, they take the risk (not much choice there anyway :-). Let's assume that source was available. Let's also assume, for the sake of your argument, that a programmer reading the os source notes an (undocumented) side-effect in a routine. What would happen: a) Since the programmer always tries to cause CBM as much harm as possible, he proceeds to make worst possible use of the side-effect, knowing it will explode in his face anytime. b) Noting that the side-effect might at some point hurt the program he's writing, or CBM's business and thus indirectly his own business, the programmer duly reports his findings to bugs@commodore.com and the things get fixed or documented if the side-effect is intentional. c) Seeing that the world isn't perfect, the programmer makes suicide since the bugs will never end anyway. :-) d) Nothing, because the programmer doesn't know what a side-effect is and wouldn't recognize it even if it was documented. My bet is for case b) for most people programming this machine. Not many of us are sadists after all. So let's assume source isn't available. Our brave programmer, fighting his way through guru meditations finally gets his program to run as it is supposed to. In calling FooBar(), which actually contains a side-effect nobody is aware of yet, he happens to rely on said side-effect. What happens: a) Nothing. Nobody knows about any problems. No os bugs is reported. Nobody else gains from the os bug report, since it couldn't be done. b) Nothing at first, but then the program suddenly blows up after an OS revision. Nobody knows why. Otherwise like a). My personal preference happens to be with the source scenario. To every developer it is quite clear that the os isn't bug free. When more people can read the source, it means that bugs will be found sooner. *That* will benefit all of us. Maybe the whole argument is just about what effects you choose to be concerned about and how you weigh them. The negative approach is to concentrate on what possible harm could be done. The positive approach is to concentrate on the things than can be achieved. I'm quite proud of having a positive attitude to most things. But then, that's all personal. The above is also why you may see more of me working on unix, X11 and Sather than AmigaDOS in the future. Not that I don't like the Amiga, but unneccessary obstacles like no source availability sure makes it hard to justify. *Where is* that protected and virtual memory anyway? Followups directed to poster. I won't waste any more energy on this for now. At least CBM knows how we feel about it, maybe they'll change their mind sometimes in the future. For now, I'll concentrate on systems whose designers saw the source light long ago. -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University -- Leonard