Cross-platform framework coming soon

From: Michael D. Crawford (crawford_at_[hidden])
Date: 2000-10-19 05:34:17

Friends,

My friend Andy Green has spent the last five years writing a
cross-platform
application framework that he calls ZooLib.  Originally created to
insulate himself from Apple's decisions about platform API's for Mac
programmers, he's been using it solely for his own use and that of his
clients until he let me start using it last winter to help him get it
ready for open source release.

It allows you to write a single set of C++ sources and build native
binary applications compiled for MacOS, Win32, BeOS (http://www.be.com)
and POSIX flavors with XWindows.

ZooLib requires only very low-level support from the operating system
and GUI layer (rendering basic vector graphics, text and bitmaps, window
management, GUI events like window update messages, threads (unless the
ZooLib thread implementation is used), some kind of network stack, a
filesystem of some sort.  The platform-specific layer is compact and
cleanly designed enough that ZooLib could be bound to a new platform
like, say, QNX (http://get.qnx.com) in just a few weeks.

ZooLib applications are multithreaded, it provides a GUI with a uniquely
flexible layout architecture, platform-independent mutex classes,
reference counted smart pointers, file access, streams, platform
independent networking classes, and a lightweight database file format.

The databases are kept entirely in single files so you can use a ZooLib
database as a user document, and send them via email for example.

The GUI widgets can use platform specific renderers so your app looks
like a native windows app when run on Windows, and a native Mac app on
the MacOS (it uses the Appearance Manager if it is available).  There's
even a switchable renderer so you can change the look and feel of your
program at runtime for testing and demonstration purposes.

It has extensive debugging support, with assertions used throughout core
components, and a debugging memory allocator that provides such things
as heap block headers and trailers (to detect overwrites) and
preinitializing allocated memory to garbage as well as filling memory
with garbage just before returning it to the underlying heap.

You don't need to drag in the whole thing to use some of it.  For
example, you could use just the networking code to build a
platform-independent network server with no UI.  I'm pretty sure the
only thing that's requires is the core technology like the thread
classes, reference counted smart pointers and the mutexes.

In part because ZooLib is so well architected, and in part because of
the runtime support for debugging in debug builds, I've found that my
own application built with ZooLib has a dramatically lower level of bugs
than any application I've ever written.  It has been very rare that I've
had a crash bug during development that persisted for more than a few
hours, and only a couple times that I've sent a test build to my client
that had any crashes she could find.

It provides two different thread implementations for platforms that
don't support preemptive multithreading.  In one, it uses non-preemptive
threading (explicit yielding) by running its own scheduler during each
mutex acquisition.  In the other, Andy's hacked on the C library setjmp
and longjmp to set up thread stacks and jump back and forth between
them.

Unlike Java, which is more of a proprietary platform in itself rather
than a cross-platform framework, ZooLib doesn't lock you in.  Some
platform-specific classes are provided for such things as file open
panels (to filter by filename extension on Windows and filetype (an
attribute in the filesystem) on the MacOS.  If you want to escape to
OS-specific code in your app you just use the handy preprocessor
symbols:

#if ZCONFIG_OS == ZCONFIG_OS_Win32
        // put windows-specific code here
#elif ZCONFIG_OS == ZCONFIG_OS_MacOS7
        // put macos-specific code here
#else
        // etc.
#endif

ZooLib is not available yet but will be soon.  About thirty developers
have been participating in the beta test for a few months.  Andy's been
going over the code with a fine-tooth comb for quite a while now,
picking the tiniest of nits and I think he feels it's about ready. 
ZooLib is Andy's little baby and he has very high standards - I think he
wants to be sure its done before its released.

Contrast this with some open-source projects that wind up with buggy
development code compiled into commercial products meant for production
use.

The above material is technical information about why ZooLib is a good
API for writing a program to.  I've also written a discussion, perhaps a
little more assertive in its tone, as to why ZooLib and cross-platform
frameworks
in general are good for the business and human aspect of being an
independent application developer.  

Have you ever felt that an operating system vendor didn't represent your
best interests?  Then I'd like you to read:

The Cross-Platform Manifesto
http://www.goingware.com/manifestoes/crossplatform.html

Regards,

Mike Crawford

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
crawford_at_[hidden]
  Tilting at Windmills for a Better Tomorrow.