Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uunet!sdrc!cinnet!kilian From: kilian@cinnet.com (Kilian Jacob) Newsgroups: comp.sys.amiga.programmer Subject: Re: Short Hello World Keywords: LVO include hard coding OldOpenLibrary OpenLibrary compatibility Message-ID: <1991May21.013817.9522@cinnet.com> Date: 21 May 91 01:38:17 GMT Organization: Cincinnati Network, Cinti. OH Lines: 83 >In article <1991May11.211913.21863@cinnet.com> you write: >>Well, theoratically, you're right. In reality, though, there is no reason to >>change (or interchange, to be excact) library vector offsets. The only >>reason I see why OldOpenLibrary() one day might not have the offset -408 is >>that Commdore dicided to get rid of it. In that case neither program (the >>one that uses the .i files nor the one that doesn't) would work by simply >>reassemblying it. In both cases you would have to insert a sub.l d0,d0 >>before the function call and use OpenLibrary() instead. > >What you say may never happen has already happened the OpenLibrary >vector used to point where OldOpenLibrary now points. (Surprising, Come on! :-) What I ment was changing the vector offset of a function and using its original offset for a different function (or not using it at all). In the case of OpenLibrary, the offset -408 performs the same action in all OS version. (It doesn't matter whether it's called OpenLibrary (v1.0) or OldOpenLibrary (v1.1+).) >but this is where the "Old" comes from!) But it was documented as >doing what the new OpenLibrary does. The new one was added rather >than changing the existing vector so that existing binaries wouldn't >fail. > >So the source for a program compiled into an old binary (where >OpenLibrary pointed to OldOpenLibrary) would fail when OldOpenLibrary >is deleted but would work if recompiled to use the new OpenLibrary >vector. > Well, that depends on the program. The "hello word" program for example would work in neither fashion (includes vs hard coded LVO's), because it doesn't specify any version number.: original short hello world source code: OpenLibrary equ -408 .. move.l $4,a6 move.l #DOSBASE(pc),a1 jsr OpenLibrary(a6) ... DOSBASE dc.b "dos.library",0 This works under any OS version as long as the offset -408 points to the OldOpenLibrary (version 1.0 OpenLibrary) function. short hello world using include files: include "dos/dos.i" ... move.l $4,a6 move.l #DOSBASE(pc),a1 jsr _LVOOpenLibrary(a6) This actually only works properly using the v1.0 include files, since the new (v1.1+) OpenLibrary (-552) requires a version number in d0. (You would have to do a moveq.l #0,d0 [or sub.l d0,d0] before you call OpenLibrary -- re-read my original post. That's what I already wrote.) My point is that you can't substitute OpenLibrary (-552) for OldOpenLibrary (-408) 100%, as you suggest. Thus, compatiblity is no reason to use include files instead of hard coding LVO's. If you could use the new version without modifying your source code (here: having to pass a second parameter), it (new OpenLibrary) would still have the old offset (as it is true for newer versions of other OS functions). In such case, obviously, whether to use includes or hard code LVO's doesn't matter either. >Also ROM space may not be the only reason for removing the >OldOpenLibrary call. > Well, I also mentioned the size limitations of the Library jump table ;-) -- what other reason are there? Later, -- /