[comp.sys.amiga.programmer] OldOpenLibrary

chrisg@cbmvax.commodore.com (Chris Green) (05/16/91)

In article <ROCKWELL.91May16073418@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes:
>
>First off, 2.0 has not yet been released.  It is a bit premature to
>say "stop using OldOpenLibrary" when that would break on just about
>every amiga in existence.  This is part of life :-).
>

	I have no idea if OldOpenLibrary will ever be killed, but what's the big deal?
I can't image that even as little as a 1% chance of being incompatible with
a future OS release is worth one MOVEQ #V_1.2,D0 in your startup code before calling
the new OpenLibrary. There are cases where there are legitimate tradeoffs in
efficiency versus possible future compatibility, but this is not one, by
any stretch of the imagination.
-- 
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
|My opinions are my own, and do not         - killyouridolssonicdeath   o
|necessarily represent those of my employer.- itstheendoftheworld       r
*-------------------------------------------*---------------------------d

mmm@reaper.Chi.IL.US (Michael Marvin Morrison) (05/18/91)

In article <21648@cbmvax.commodore.com> chrisg@cbmvax.commodore.com (Chris Green) writes:
>In article <ROCKWELL.91May16073418@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes:
>>
>>First off, 2.0 has not yet been released.  It is a bit premature to
>>say "stop using OldOpenLibrary" when that would break on just about
>>every amiga in existence.  This is part of life :-).
>>
>
>	I have no idea if OldOpenLibrary will ever be killed, but what's the big deal?
>I can't image that even as little as a 1% chance of being incompatible with
>a future OS release is worth one MOVEQ #V_1.2,D0 in your startup code before calling
>the new OpenLibrary. There are cases where there are legitimate tradeoffs in
>efficiency versus possible future compatibility, but this is not one, by
>any stretch of the imagination.
>-- 
>*-------------------------------------------*---------------------------*
>|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
>|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
>|My opinions are my own, and do not         - killyouridolssonicdeath   o
>|necessarily represent those of my employer.- itstheendoftheworld       r
>*-------------------------------------------*---------------------------d

At the risk of getting flamed:

I totally agree, but someone should tell the people at MANX/AZTEC that this
function should be removed.  

I have disassembled quite a bit of different peoples code, and have discoverd
that under AZTEC, it will insert OldOpenLibrary().  If you don't believe me 
disassemble SetCPU1.6 by Dave H.  It was obviously compiled with aztec, and has 
OldOpenLibrary in it.  This may be part of the 'c.o' equivelent under aztec, 
but I don't know, since I own SAS/C, and I haven't found SAS/Lattice to do this. 

--
Michael M Morrison              /|                             |\
mmm@reaper.chi.il.us <or>      | |     Cold Steel on Ice       | |
reaper!mmm@miroc.chi.il.us      \|                             |/

daveh@cbmvax.commodore.com (Dave Haynie) (05/23/91)

In article <mmm.1299@reaper.Chi.IL.US> mmm@reaper.Chi.IL.US (Michael Marvin Morrison) writes:

>I have disassembled quite a bit of different peoples code, and have discoverd
>that under AZTEC, it will insert OldOpenLibrary().  If you don't believe me 
>disassemble SetCPU1.6 by Dave H.  It was obviously compiled with aztec, and has 
>OldOpenLibrary in it.  This may be part of the 'c.o' equivelent under aztec, 
>but I don't know, since I own SAS/C, and I haven't found SAS/Lattice to do this. 

Sounds very likely.  SetCPU V1.6 was assembled with Manx 3.6a.  Seems to me 
that 3.6a would have been released some significant time after "OpenLibrary"
became "OldOpenLibrary".  While it's no big deal for SetCPU, since the code 
and executable are public domain, you might think that a couple of commercial
packages, at least, are compiled with this setup.  That would indeed be a Bad
Thing.

>Michael M Morrison              /|                             |\

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      "That's me in the corner, that's me in the spotlight" -R.E.M.

kilian@cinnet.com (Kilian Jacob) (05/30/91)

Andrew,

>I was referring to your statement to the effect that reassembling
>would not fix either program.

>This is wrong as I tried to explain.  To be more explicit: Imagine a
>program written for 1.1 which used the OpenLibrary() function as
>documented.  When assembled by a 1.1 assembler it calls the
>(Old)OpenLibrary vector which doesn't do what is documented (doesn't
>work properly).  If re-assembled by a 1.2 or later assembler it will
>call the new OpenLibrary vector and now work properly.  If, however,
>the absolute vector is used to make the call then re-assembling will
>not fix the problem.

There must have been quite a number of programs (running under 1.0) that
did not use (Old)OpenLibrary the way is was documented. (In other words:
They ommited to pass a version number.) Otherwise, Commodore would have
simply *replaced* the v1.0 (Old)OpenLibrary by the newer version.

>> Well, I also mentioned the size limitations of the Library jump table ;-)
>> -- what other reason are there?

>Perhaps Commodore might want try to make a programmer think about
>what version of a library he needs by explicitly making him specify a
>version number.

I agree. 

-- /<ilian

-- 
Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891
UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian