The tale of a developers quest for sanity.
Note - Images updated on 12/Nov/2007
Computer geeks are generally very passionate about
Operating System advocacy. There are literally millions of internet
pages where advocates (and
zealots) debate the merits and weaknesses of rival systems. A good
flame war can be quite educating and amusing to watch, but sadly a lot
of these debates end up being driven by
FUD and good old fashioned uninformed ignorance.
Even though I develop embedded software professionally for a living, I actually
enjoy working on my own little pet projects every now and then in my spare
time. These pet projects are always run on the platform, programming language
and API of my choosing. One of my pet projects is *Yet Another* cross platform
3D rendering engine called Yarra, named after the
Yarra River in the city I live in.
Yarra was designed to be a C++ based multi-threaded cross-platform rendering engine, using
OpenGL for 3D graphics and OpenAL for positional sound. Unlike existing
engines, Yarra was primarily designed to allow dynamic adding of programmable
objects to a scene graph with handlers to control game flow. This design
doesn't suite a majority of software out there, but works great for games. But
this article isn't about Yarra, it's about my experiences working with
Windows, MacOSX and BeOS.
I will now describe my personal experience developing software for three
popular operating systems. I'll discuss the pro's and con's of each
environment, and give a very subjective opinion about the merits of each. Just
like every person on this planet, it's almost impossible to be impartial or
unbiased towards the subject I'm about to discuss. I am but a human, sometimes
emotional, sometimes illogical, but always passionate. Lets have some fun!!!
Windows XP
|
WindowsXP, with Visual Studio 2008
Click on image to view hi-res screenshot
|
The WindowsXP box is running on an Dual Core AMDx64 CPU, 2Gb RAM and a pair of
7200 RPM disks running in a Raid-0 configuration. Microsoft Visual Studio 7.0
is the primary development tool, with MSDN documentation. Platform specific
code is written in C++ and utilises the C based Win32 API
The windows experience is based on a
Multiple Document Interface workflow. The Visual Studio window is best
used when maximised, and it contains all the individual panes which a developer
needs. When working on a single task, the primary pane snaps into focus and I
find this actually improves workflow since I do not spend as much time
rearranging windows like I do with
Single Document Interace systems (OSX and BeOS). However, the moment I
wish to compare two files (or I'm working with 2 projects), MDI becomes
annoying since every window is consumed with countless menus and toolbars,
wasting limited screen real-estate. The SDI systems generally have less
toolbars and menus, so by their very design are more usable when working with
multiple projects simulteneously.
The Windows native API (Win32) is just horrible. Lets face it, if it were any
good, Microsoft would not have had to release so many other API's (like MFC and
the new .NET) to compensate. The worst aspect of Win32 programming is finding
the correct information you need in MSDN. Since Microsoft have released so many
API's for various languages, MSDN is intermixed with all these references. A
search will return results for the language you are not interested in, or for
an API you are not using. Microsoft has not impossed a unified naming scheme,
so its very difficult to Google for a code example using a specific API
reference (ie. the BeOS API prefixes all functions with the letter B and all
constants with B_, so it becomes trivial to Google for examples. Likewise,
Apple uses the NS_ prefix. It is much simpler to search for BButton and
NSButton than plain old Button). Fortunately, there are 3rd party API's
to help developers retain their sanity (ie. Qt from Trolltech)
Managing files under Windows is quite fast. For instance, extracting and
compressing files is significantly quicker under Windows when compared to the
other 2 systems, and this is probably due to Windows not having to update the
file system journal and file system attributes. Conscequently, compiling files
is also faster, due to the fact that the file system is doing less work.
Likewise, navigating directories and displaying their content is very quick
under Windows. It is overall a very pleasant experience. However, sometimes the
file system will throw a fit when you attempt an operation on an open file.
Windows generally aborts any file operation when it cannot access an exclusive
lock on the file. And if a shared networked file system is out of reach, so too
is your Windows box until the internal network stack times out.
Having said all that, Visual Studio is an excellent tool for development.
However, the amount of options available can easily confuse even seasoned
professionals. It's probably the nicest software Microsoft ever released. It
has almost every feature you need, and it's very snappy. This is especially
apparent when you move from a MacOSX development box to Windows - the system is
by a magnitude more responsive.
Note 12/Nov/2007 - Apple have finally achieved Teh Snappiness (TM) with Mac OS X 10.5 (Leopard)
Mac OSX
|
Mac OSX 10.5 (Leopard), with XCode 3.0
Click on image to view hi-res screenshot
|
The MacOSX box is running on a MacBookPro Core2Duo notebook, with 2Gb RAM and a
160Gb 5400 RPM disk. XCode 2.4 is the primary development tool.
One of my biggest annoyances with Mac OSX is the amount of usable screen
real-estate available when developing software. Even though the overall pixel
count is similar between the 2 boxes (and even when running the same resolution
on the same external monitor), graphical elements in OSX seem to consume more
pixels than what the other 2 systems consume. Yes, the GUI looks much nicer in
OSX, but the cost is a dramatic decrease in usable real-estate. Finder (the OSX
file management application) seems to be the worst culprit, consuming a
ridiculous screen-shot friendly amount of pixels - a tragic example of a form-over-function
based design. Apple desperately needed Expose and the upcoming virtual desktop
application (Spaces).
Just like Visual Studio, XCode has every possible option under the sun
available, and then some. XCode can also manage application documentation,
application packaging and distribution, revision control, everything including
the kitchen sink. The help is meaningful and actually applicable, which has
really been useful to me since I'm an absolute beginner when it comes to
developing software under the Mac OSX platform.
Apple also offer a choice of various programming languages and API's. Even though Objective-C
and Cocoa are the preferred API for development in the Mac OSX ecosystem, it is
possible to mix Objective-C and Cocoa with good old fashioned C++ and the libraries Yarra depend on.
Much to the dismay of "Learn to program a new language in 24 hours" books, learning a
new language in and of itself is not very time consuming, the problem is that
it takes a significant amount of time to learn a new API, and several years
more to master it. Only a small subset of the Cocoa framework is utilised to support the Yarra engine
(user input and window management), while threading and locking support is provided by Darwin.
.
Notebooks generally have lower performance when compared to similarly speced
desktops, primarily due to slower hard drives and power management
restrictions. Apple with MacOSX have placed an additional burden on its
hardware by being Apple. The additional eye-candy (fonts, animations, widget
sizes), the additional background services, and robustness of 'user friendly'
software, etc. continue to tax the hardware more than when compared to the
other 2 operating systems reviewed today. MacOSX is just annoyingly slow on a
modern 2.33GHz dual core CPU based notebook. But then again, anyone running
Windows in a coorporate environment will relate to this experience since they
are also running a box riddled with all those additional programs and services
(anti-spyware, filtering software, anti-virus software, coorporate snooping
software etc).
Note 12/Nov/2007 - Apple have finally achieved Teh Snappiness (TM) with Mac OS X 10.5 (Leopard)
BeOS
|
Zeta 1.2, with bdb (based on Metrowerks CodeWarrior).
Click on image to view hi-res screenshot
|
The BeBox dual boots together with Windows, and runs YellowTab Zeta 1.2 on a
seperate IDE based 7200 hard disk. One of the AMDx64 cores is disabled due to a
kernel bug which incorrectly identifies this particular dual core CPU. The
development tool is the original BeIDE (Metrowerks Codewarrior), a GUI front
end for all the GCC / GDB tools.
Geeks everywhere will sadly remember the day BeInc lost focus in late 1999. I
must be a masochist at heart, since I must publicly admit that I still find
greater joy in using a 7 year old system than any modern system available
today. In the computing world, 7 years is a lifetime. I'll count the years for
anyone still reading - 2000, 2001, 2002, 2003, 2004, 2005, 2006. MacOSX 10.0
wasn't released when BeInc lost focus. Windows 2000 was released after BeInc
publically quit the OS business. Heck, even AmigaInc still had a viable
business plan when BeInc switched from Operating Systems to Internet
appliances.
While working on the Yarra engine, I regularly have to move from MacOSX to
Windows to BeOS. Going from OSX to Windows is like going from driving a truck
to driving a passenger vechicle - the responsiveness is just too hard to
ignore. You accelerate faster after a set of traffic lights, you handle corners
better, etc. Moving from Windows to BeOS is like moving into a performance
racing car. The system is amazingly responsive, no matter how much you stress
it (and when developing OpenGL rendering code, you get to stress it quite a
bit), the user always feels that they are in complete control. This is
primarily due to the spartan nature of the OS and its applications. There are
hardly any services running in the background competing for CPU resources, and
the fact that the kernel and application server are more multithreaded by
design than any other system out there. What really amazes me is that this
single core system feels more responsive than its dual core brethen.
If you were to casually inspect the 3 screenshots on this page, you may
conclude that the BeOS development tools are quite featureless. This is but an
illusion - what you really need is there, what you may need is in a menu, a
what you may never need is accessable via an additional command line parameters
box. At the end of the day, you are still interfacing with the same GCC based
compiler, linker and debugger.
The BeOS API is probably the most pleasant C++ based API I have ever
encountered. Just as NextStep uses Frameworks, the BeAPI uses Kits to
subcategorise the API. The entire API adheres to a common design and naming
scheme, and once you get the hang of it, you stop second guessing it. However,
if you have never dealt with multithreaded code before, you are in for a rude
awakening when using BeAPI derived objects. The BeAPI imposes
developers to use a mulithreaded based design, regardless of how trivial (or
simple) the application needs to be. For instance, a simple application which
shows a single window displaying the popular " Hello World " quote,
needs to inherit from a BApplication, BWindow and BView objects. BApplication
and BWindow objects are derived from a BLooper class, which means your
application automatically has 2 threads. Take into account that the
ApplicationServer also creates a thread to match each BLooper object (for
communication and passing messages to your application), and the most trivial
application is already running on 4 threads. And the thread count keeps on
growing...
The Tennis game visible in the screen shot above running on
the Yarra engine requires 4 threads for the engine alone. The BeOS version uses 4 additional
threads on the application side, with the Application Server matching 4 of these threads.
Thats 12 threads jostling for CPU cores. As a comparison,the Windows and MacOSX version of the same
Tennis game run in 5 threads.
BeOS really suffers due to lack of coorporate support. There is no money to be
made in the BeOS (and by extension, Haiku)
world. Hardware drivers are usually late and hard to come by, professional
applications are almost non-existant. The hard-core remainder of the BeOS
community has gravitated towards Haiku, and new projects are brewing on these
hard drives. With the very first Haiku release imminent, things are looking
promising for the aspiring Haiku application developer. To misquote the always
quotable JLG, " ... it's more important for Haiku to breed the next Adobe
than to convince Adobe that Haiku is their next platform "
Final words
I'm really suprised by the migration of so many developers towards Java. One of
Java's biggest marketing points is that it allows write once, release everywhere
applications, but in reality it's write once, compile everywhere. Remind
me again when was the last time anyone ran a Java Mobile Edition application
(most mobile phones) on their desktops. Heck, even some mobile phone software
is not portable across different model phones from the same manufacturer, let
alone competing manufacturers. Lets not get started on the slight binary
incompatibility between Microsoft JavaVM, Symbian JavaVM and Sun JavaVM. Dont
forget that by using cross platformJava, we're also dealing with the
overhead of JIT compilation, and virtualisation.
Yet it is quite possible to make a C++ based application run natively on
multiple platforms after a simple recompile. All you really need to do is use
common libraries (ie. OpenGL, OpenAL, libpng, etc), adhere to language
standards, and to only use cross platform API's (ie. Qt, GLUT, and why not,
even Yarra). As long as developers don't take shortcuts by using native OS
calls when developing their applications and instead rely on using the
published interfaces available to the cross platform API, then their
applications will be 100% portable across mulitple operating systems. And the
apps will run at ludicrous speed.
Written by Zenja Solaja
January 28 2007
Melbourne, Australia
