Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <1989Nov20.182741.2658@eng.umd.edu>
Date: 20 Nov 89 18:27:41 GMT
References: <5249@internal.Apple.COM> <17090@dartvax.Dartmouth.EDU> <5292@internal.Apple.COM>
Sender: news@eng.umd.edu (The News System)
Reply-To: russotto@eng.umd.edu (Matthew T. Russotto)
Organization: Merriversity of Uniland, College Purgatory
Lines: 48

In article <5292@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>In article <17090@dartvax.Dartmouth.EDU> erics@eleazar.dartmouth.edu (Eric 
>Schlegel) writes:
>> On pp. 385-6 of IM, volume 2, is documented the Restart procedure. It's 
>> marked Not in ROM; assembly-language programmers are advised that "you 
>can
>> give the following instructions to restart the system:"
>>      MOVE   ROMBase,A0
>>      JMP    $0A(A0)
>
>This raises an interesting point: Inside Macintosh actually does 
>programmers a disservice by saying things like "assembly-language 
>programmers can..." and then giving code that relies on specific ROM 
>addresses (or even specific ROM offsets, like above).  The CORRECT way to 
>get that same effect, given that there's a routine called RESTART that is 
>marked NOT IN ROM is to Link in the appropriate library (usually Runtime.o 
>for MPW users) from your development system, and make the call to the 
>library routine.  That's what libraries are for.
So?  Your application still breaks.  Unless you have a dynamic linker,
of course... (was it REALLY that hard for apple to keep a JMP to the right
spot in 0A(RomBase)? )
>
>In article <17090@dartvax.Dartmouth.EDU> erics@eleazar.dartmouth.edu (Eric 
>Schlegel) writes:
>> Sorry, Paul. The examples are few, far between, and obscure, but they
>> do exist.
>
>Indeed they do, but a) how much stuff breaks as a result of our System 
>Software and hardware architectures evolving, and b) is it the software 
>that's broken, the documentation, the hardware, or is it all a matter of 
>interpretation?
It isn't the hardware, but whether it is the software or the documentation
depends on your answer to the following:
If a program does not conform to specifications, is it the fault of the
program or the specification.
>
>__________________________________________________________________________
>Just because I work for Apple Computer, Inc. doesn't mean that they 
>believe what I believe or vice-versa.
>__________________________________________________________________________
>C++ -- The language in which only friends can access your private members.
>__________________________________________________________________________


--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
You know you are in trouble when you need a kill file for 'junk'!