> We keep hearing that GEOS 3.0 is compatible with 2.x, but our SDK docs say
> otherwise. They say that when GEOS loads a program, it will check the
[...]
> is why our 2.0 apps work on the OmniGo. But for the major version number, it
> only loads it if it's an exact match, as the major version is supposed to be
> used to indicate incompatibility. Doesn't that mean we'll have to recompile
Just as you say: increasing the major protocol (!) number should only take place
if the "exposed" interface of a Geode is no longer compatible to code written to
older specifications.
Normally, this should not be necessary for updates which cause internal changes
or which simply add new functionality (classes and/or API entries). In most
cases, this will also be true for bug fixes, except for cases where old
applications actually rely on the presence of such a bug... An example would be
code which is based on the assumptation that parameters to a GOC API entry are
passed in a certain incorrect manner - fixing this would obviously break the old
code.
In other words, I wouldn't expect too many problems of that sort, unless there
is a good reason for it - just because the product is named "3.0", this doesn't
mean that all of the individual protocol numbers will be updated...
OTOH, don't take my word for it - the third party software market for Geos is
not exactly big, and it hasn't received too much exposure, so the temptation may
be there to break existing code in favor of introducing some "new and clean"
designs... I'd personally take this as the "lesser evil", provided the changes
would really benefit programs using them.
ciao marcus
ps: Obviously, these considerations say nothing about the appearance of
previously unnoticed bugs when applications are used with new versions of the
operating system (or if the operating system has to run applications which it
hasn't been tested with... :-)). A nice example for this from the CompuServe
client for Geos:
The developer(s) of the code apparently have been a little confused whether a
failing File...() function should return 0 or -1 to indicate failure. In most
places, they chose to expect -1 (which is C-like, but wrong), and they also
declared file handles as being int (sword) instead of word.
In one place, the program checks for an invalid file handle by testing whether
it is less than or equal to zero (signed!). This works quite well on older
platforms, because negative handles will rarely appear there, but it fails on
the OmniGo. The reason is simply that the high number of libraries normally open
on the OG will push the handle values beyond 7FFFh, causing them to "wrap" into
the negative range. Boom! :-)