ZooLib can protect your business, and your users' businesses,
from vendors who don't serve the needs of you or your users.
February 26, 2001
Operating systems vendors invest a great deal of energy in getting applications developers to code products directly to the native API of the OS.
The result is that it is very difficult for the developer to bring the product out on a competing platform, and it discourages users from moving to a different OS when they feel the vendor isn't serving their needs (because they can't get the solutions to their problems).
If the developer doesn't want to deal with the OS vendor anymore, he's really got a problem - either suffer under the vendor's thumb, or make a great deal of personal sacrifice to move to a different operating system.
I was sick of Apple so I wrote I'm worried about my future. That's why I'm a Be developer.
And in fact I shipped (and still do support) on of the first commercial applications for the BeOS, Spellswell from Working Software.
Nothing Be ever did made any sense, and while there are individuals at the company that I regard highly, on the whole I felt the company to be uniquely unresponsive and incompetent.
The BeOS is no longer published, though one can still download BeOS 5 Personal Edition and installation CDs for BeOS 5 Professional Edition can be had from places like eBay.
However, a binary-compatible Open Source clone called Haiku has been in development for many years, and is expected to reach Alpha Test soon.
And just when they were showing some promise of shipping enough BeOS installations that I had some hope of making more than the measly couple hundred bucks I'd earned in royalties in the three years I'd been working on Spellswell, they announced a "change in focus" and said they weren't going to support the desktop anymore, except for the extent necessary to use it as a development platform for their new Strategy Du Jour, Internet Appliances.
After I posted on BeDevTalk that Some of Us Work for a Living, the moderator told me he was fed up with a developer who was trying to discuss business issues of concern to Be's third-party developers on Be's third-party developer mailing list. That was my last message to bedevtalk - he unsubscribed me.
I've been working on a really challenging C++ application for a few months, and after reading C++ Answers with Bjarne Stoustrup I got excited about really digging into the basics of programming - but from the perspective of a developer with 13 years of work experience and a lot of shipping products.
I bought a few books, mostly on C++ and also hit some websites and newsgroups, and I became a much better programmer as a result. And I really felt that I did better to spend my time on core architectural and language issues rather than dealing with OS-specific nits or tool issues. And so I wrote Study Fundamentals, Not APIs, Tools or OSes.
So this brings me back to being used by operating systems vendors to serve their material needs at my expense and the cost of much personal pain. If you become a better programmer by learning the basics better, to can fluidly go from operating system to operating system without much of a learning curve.
But there's the problem that you have to use some API to code your application to, and while Java claims to be "platform-independent" it is really a proprietary platform in itself - just try making use of platform-specific code in a Java application, yes you can do it with the Java Native Interface but it is difficult and an assault on the Java developer's senses to write a dll in C or C++ to load into the runtime.
So what you really need is a cross-platform application framework that you can write in with a language such as C++, that comes preconfigured with easy-to-use preprocessor symbols so you can drop into OS-specific code at your whim, and will compile from a single sourcebase to native machine code for multiple operating systems.
Funny that, since December '99 I've been writing a multithreaded special-purpose graphics editor that is also an HTTP client with just such a cross-platform application framework. I can develop on Mac or Windows as the need suits me and switch back and forth at a moment's notice (especially now that I've got filesharing between my machines). My client only asked for Mac and Windows versions but I could port to BeOS or Linux in a few days. The framework is called ZooLib.
It was written by my friend Andrew Green of The Electric Magic Company, originally to insulate himself from Apple's API nonsense. (Do you remember when all progress on developer tools at Apple and Symantec stopped while they went off into the sunset to develop Bedrock, itself a cross-platform application framework and an immense investment of time and money - and then abandoned it? If it hadn't been for then-tiny Metrowerks Apple would have gone out of business after shipping the first PowerPC Macs, because there would have been no native PPC compilers.)
He felt that if he could code to his own layer and Apple changed their API, he'd just have to reimplement the OS-specific layer and he'd be working again. But then a little more work and he'd be cross-platform...
Get it right here.
While ZooLib is to be newly released to the public it is not new code. It has been in use in commercial products for about ten years - and in development in my own products since last December. Part of why Andy gave me the code and I've been working with it is to give him meaningful architectural feedback and detailed bug reports so he can prepare it for public release.
I've been urging Andy to release the source as-is for a couple of years but his standards are incredibly high for a programmer. Andy's code doesn't just work, it is correct.
Andy spares no effort or time to fix the smallest problems (this is especially important in multithreaded code - think about reference counted smart pointers that are operated on by different threads, as you can do with Zoolib), and part of why he's been delaying the release is to improve the overall architecture.
But now ZooLib is available for your use and enjoyment. Use it well.
The following quotes are excerpted from rulings issues by U.S. District Judge Thomas Penfield Jackson in the Department of Justice vs. Microsoft antitrust case:
In this case, Microsoft early on recognized middleware as the Trojan horse that, once having, in effect, infiltrated the applications barrier, could enable rival operating systems to enter the market for Intel-compatible PC operating systems unimpeded. Simply put, middleware threatened to demolish Microsoft's coveted monopoly power. Alerted to the threat, Microsoft strove over a period of approximately four years to prevent middleware technologies from fostering the development of enough full-featured, cross-platform applications to erode the applications barrier. In pursuit of this goal, Microsoft sought to convince developers to concentrate on Windows-specific APIs and ignore interfaces exposed by the two incarnations of middleware that posed the greatest threat, namely, Netscape's Navigator Web browser and Sun's implementation of the Java technology. Microsoft's campaign succeeded in preventing - for several years, and perhaps permanently - Navigator and Java from fulfilling their potential to open the market for Intel-compatible PC operating systems to competition on the merits.
-- Conclusions of Law and Final Order
78. Although they have been the most prominent, Netscape's Navigator and Sun's Java implementation are not the only manifestations of middleware that Microsoft has perceived as having the potential to weaken the applications barrier to entry. Starting in 1994, Microsoft exhibited considerable concern over the software product Notes, distributed first by Lotus and then by IBM. Microsoft worried about Notes for several reasons: It presented a graphical interface that was common across multiple operating systems; it also exposed a set of APIs to developers; and, like Navigator, it served as a distribution vehicle for Sun's Java runtime environment. Then in 1995, Microsoft reacted with alarm to Intel's Native Signal Processing software, which interacted with the microprocessor independently of the operating system and exposed APIs directly to developers of multimedia content. Finally, in 1997 Microsoft noted the dangers of Apple's and RealNetworks' multimedia playback technologies, which ran on several platforms (including the Mac OS and Windows) and similarly exposed APIs to content developers. Microsoft feared all of these technologies because they facilitated the development of user-oriented software that would be indifferent to the identity of the underlying operating system.
-- Findings of Fact
I suppose this does not bode well for ZooLib. Microsoft might crush it, you say. But the cross-platform API's mentioned by Judge Jackson each had a chokepoint because they were proprietary products each sold by a company; because ZooLib is Open Source and distributed under the MIT License, once the code has been downloaded there's not a lot any OS vendor or anyone else for that matter can do to stop its distribution and use.