ccplumb@watmath.waterloo.edu (Colin Plumb) (01/16/88)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) wrote: > Due to a bug in 1.0/1.1, which had to be preserved to prevent >breaking anything, sprites are exactly one pixel off on the X axis. You'll >have to correct for this internally. I was just thinking about this, and thought of a solution that should keep everyone happy. Keep the old, buggy entry point at its current offset, but add a new, non-buggy one. Change the libraries so the _LVO offset points to the new entry point, and dream up a name for the old entry point, just in cas anyone wants to use it. Thus, binaries don't break, we're rid of the bug, and we don't have to put up with silly names invented to distinguish the new version from the intuitively-named old version. The only problem comes if you try and recompile old source with the new libraries. However, I believe it's reasonable to assume that anyone who gets the new library disk will be able to read the README file telling them they have to do a global search-and-replace on the source. I'm sure people have #defines to hide the off-by-one bug, at least, which would probably make things still easier to change over. Opinions? -- -Colin (ccplumb@watmath)
ain@s.cc.purdue.edu (Patrick White) (01/18/88)
>ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) wrote: >> Due to a bug in 1.0/1.1, which had to be preserved to prevent >>breaking anything, sprites are exactly one pixel off on the X axis. I thought this is what the version numbers were for when you open libraries -- so you could have new code, open an old version of the library, and have the new code act exactly like the old version did? Is this right, or am I hosed? -- Pat White UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (01/18/88)
In article <1958@s.cc.purdue.edu> ain@k.cc.purdue.edu.UUCP (Patrick White) writes: >>ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) wrote: >>> Due to a bug in 1.0/1.1, which had to be preserved to prevent >>>breaking anything, sprites are exactly one pixel off on the X axis. > > I thought this is what the version numbers were for when you open >libraries -- so you could have new code, open an old version of the >library, and have the new code act exactly like the old version did? > Is this right, or am I hosed? Hosed. In most cases, there is no room in the ROM for an old function and a new version. When a fix is necessary but will break people, sometime a new modified function can be provided (like NewModifyProp) with it's own entry point. If you call the new function, you get the new function. If you're calling the old function, it's still there. But in most cases, there is just one version of each function in the ROM, and only fixes that won't break valid programs can be done. The library version in OpenLibrary() is basically for programmers whose code requires new functions that didn't exist in previous OS versions. (So they can exit with an error message when the OpenLibrary() fails instead of jumping to non-existent library offsets and crashing). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=