ZBlackBerry is a suite of code that implements the BlackBerry USB communications protocol in a generic fashion. A few hundred lines of code let Macs use that protocol. A few hundred more allow multiple Mac applications to talk to a single BlackBerry simultaneously, something that has not been possible till now.
Under the hood KF 4.6 has moved from using ZDBase for its backing store, instead using a tuplebase. This makes it possible to split HTML page generation into separate processes, potentially running on multiple front end machines. It also restores support for a rich client application, now written in Java, using ZTSoup to efficiently communicate changes in the tuplebase, whether made by other clients or by the web interface.
UNIX does not make an explicit distinction between programs that are servers vs programs invoked by a user. Each flavor of UNIX provides a mechanism for the management of these programs, generally by using naming and placement conventions of descriptor files in the file-system.
In contrast, Windows NT/XP supports servers with a specialized API and management tools. Windows services are packaged as regular applications, but when they are invoked by the service framework they register a callback with that framework to which status and control messages can be delivered.
Initially I provided Java access to a tuplebase instance by implementing Java classes whose most interesting methods were marked as native, and thus invoked via JNI. This was very powerful because Java could use any tuplebase implementation simply by calling the appropriate factory function and I could expose any existing C++ functionality simply by implementing the appropriate JNI glue.
It was thus relatively straightforward to implement ZFakeWindow_NSPlugin, which translates between the Netscape browser plugin and the ZFakeWindow APIs. What was actually more difficult was finding a decent implementation of the plugin glue code and header files. In 2002 there wasn't anything that would work with current compilers and with current browsers, so most of the effort was in putting together ZNSPlugin, which is a usable implementation of the glue.
Most of my work till this point had not required 'interesting' operations with file systems, being restricted to creating and opening files in externally determined locations, then reading and writing the files' contents. When it became necessary to ennumerate the contents of directories, and to deal with permissions and locking I took the opportunity to define an API that would be consistent across Windows, Mac and UNIX whilst cleanly accomodating their differences.
ZooLib had always maintained the ZFakeWindow abstract interface between user interface elements and the hosting environment. This allowed ZooLib UI widgets to be used within MacApp applications, standalone applications, Control Panels, XCMD windows and XObject windows. It worked very well.
However, when the portability axis was across platforms rather than hosting environments there was the potential for a lot of replication and ugly code in ZWindow, the standalone application derivative of ZFakeWindow.
So, I abstracted the interface to OS-windows, placing it in ZOSWindow, and modified ZWindow to use a ZOSWindow, rather than be conditionally compiled for different platforms.
