> Anyone purchased the C based SDK from Geoworks? Any feedback is much
> appreciated....
I have been using the Geos SDK since... wait... must be December 93 or so -
which means that most of my experience is not OmniGo-releted, but due to the
nature of Geos implementations on different target platforms, most of it can be
easily transfered from one machine to another.
Basically, the SDK consists of documentation (as ASCII, Postscript and Acrobat),
include files, symbol files for debugging and of course some development tools.
In addition, you will need Borland C 3.1 (or newer), as the compiler for GOC is
implemted as a command-line preprocessor. GOC is an extended version of standard
C to add object manipulation at language level - compared to other object
extensions for C, GOC is somewhat closer to Objective C than it is to C++. For
efficent debugging, a second PC hooked up via serial cable (may even be a 286,
but anything like a 386/4MB will make life easier) is a good idea, although
by-wire-debugging may be done on an actual OG. The SDK includes an OG emulation
which means you can test your applications on a desktop PC in a fairly
true-to-life environment.
My feelings on the SDK are really quite mixed - on the one side, Geos is a very
rewarding system to work with regards to operating system concepts and (often)
rapid development - there is just a huge number of system classes and routines
that can do a lot of standard tasks for you, often giving you extra
functionality "for free" by basically just turning the extra options "on". :-)
Of course, this means a different way of approaching a problem, when compared to
DOS or (mostly) Windows development: the question is not how to solve a problem
yourself, but rather a matter of finding the part of the system that already
does what you are looking for... In addition, the possibility of making
extensive use of system features usually causes applications to be just
amazingly small...
As a result, the Geos SDK has a learning curve that is steeper that that of most
other development environments I have worked with so far - the printed form of
the SDK docs is said to be 5000+ pages - of course, most of it is class library
reference and routine descriptions, for both assembly and GOC programming.
Apart from the icon and resource editor (for translation of applications), the
SDK is completely non-visual and shows clear signs of its Unix heritage. :-) For
people like me who really want to be able to customize anything and plug in some
of their own tools in the process (like using one's favorite editor, writing
batch files or code generators for repeatig tasks etc.) this is very pleasant,
but one may also view it as being counter-intuitive for a graphical
environment...
On the downside, there are a few things which sometimes made me spend 90% of
time on 10% of a program, which oft weren't even the parts that I expected to be
complex or "vital" - instead, things that looked like a little nuisance turned
out to require days of looking for a workaround... A few general observations:
- Due to the amount of code and documentation that come with the system, the
"debugging state" of the various parts varies over a wide range: generally, the
assembly language interfaces and most code that is frequently used in the
applications developed by Geoworks themselves (like the Ensemble suite) seem to
be very thoroughly checked and are also well documented. On the other hand, C
interface "wrappers" for the system routines and a few specific areas like the
floating point emulation contain quite a number of flaws - most of these can be
worked around rather easily, but this often requires some assembly level
debugging to find out what happend and that it actually isn't actually your code
that cause the problem.
- The documentation and the various include files are not always "in sync":
some functions are just not implemented, although calls or suboptions have been
reserved for them - but there is no mention of this fact anywhere in the docs
until you look at the code executed at system level for them... in other cases,
updates to specs have been made to the assembly part of the docs, but not to the
C parts.
- Once you try to implement something a little more "obscure" (e.g. try to make
objects interact in a way that is not yet used in the existing applications),
docs and samples often leave you fairly on your own. In some cases, this may be
a sign of you trying to do something that is "against" a concept and that there
is a better way to do it, but in many cases it is just due to object
interactions being not fully documented.
All this doesn't mean that I consider Geos to be an overall "buggy" system -
taking into account the size of the development team, the system is amazingly
well designed. But as developer, I often found out that when a problem left me
completely clueless for more than a couple of hours, the reason was often a
system function just not performing as described. (my favorite example: try to
debug a set of floating point routines that have been working for years in a DOS
environment when suddenly in about half of the cases the operands of "-" and "/"
get switched around.)
ciao marcus