O/R Status Report: Helix 6.0
Operation going well; vital signs are all stable
1 September 2003--When Helix came under our care a little over a year ago, we performed a number of immediate procedures that were necessary to stabilize the patient and restore a "quality of life" that had become somewhat deteriorated.
Helix 5.1 and 5.2 proved that our diagnoses were correct and that our medical team was making the right decisions. The patient (and family) has benefited from these immediate improvements, but in the back of everyone’s mind, the big operation was still lurking.
We knew that this was going to be a marathon procedure requiring surgeons with all sorts of expertise. So while we were doing all of the relatively minor procedures that have had immediate and visible results, we were also busily preparing for the significant work to come.
Rx: Longer-range vision
We have already described in some detail how vital it was to build Helix in a more modern environment, and how that was a critical technical achievement both for version 5.2 and future versions of Helix.
We have said over and over that our short range goal--Helix 6--is to have Helix running in macOS. We have also stated that beyond that door lies Helix 7, running under Mac, Windows and Linux operating systems.
What we haven’t presented, until now, is how these ideas are at work right now in Helix 6 and 7.
Remember, getting to macOS is only part of long-term plan for Helix and we have made a conscientious effort to see that each step we take toward macOS in no way derails us from getting to our later destinations.
Every modern operating system includes sets of standardized "application programming interfaces" (APIs) that enable a programmer to access OS features. There are APIs for managing windows, displaying dialog boxes, making sounds, getting input... virtually everything that you see on your computer screen goes through the OS’s APIs.
For example, Helix never actually draws on the screen. Instead, Helix sends the instructions for drawing (whether it is a framed rectangle or a piece of text) to the MacOS QuickDraw API and QuickDraw handles the rest. When Helix 5.2 added the ability to display all sorts of new document types, that was done by calling the appropriate routines in the QuickTime API.
With the introduction of macOS, Apple changed how many of their APIs work, added new APIs (eg; Quartz Extreme) and made others obsolete. The current set of APIs that Apple says will work under OS 9 and macOS are known as the Carbon APIs. (The APIs known as Cocoa are macOS exclusive, so using them would limit Helix to running on only macOS Macs.)
OS 9 also supports many legacy APIs from earlier versions of the Mac OS. A Macintosh application that calls those 'non-carbon' APIs will run in Classic mode. For that application to run natively under macOS, those calls must be replaced with updated Carbon equivalents.
Some APIs that existed in earlier versions of the Mac OS have been updated for Carbon, and calls to those APIs must be updated as well. Getting Helix (version 6) to run natively on macOS requires this process that the world now knows as "Carbonization."
The process of carbonization as it applies to Helix involves performing little tweaks in some cases and rewriting of entire routines in others. For example, Helix’s printing system, its UserEditor and document management functions each need to be reworked in their respective entireties.
We knew Carbonization would require ripping up a fair bit of code. Supporting multiple platforms could require ripping it all up again (and again). Keep in mind that each platform has its own set of APIs. The MacOS has the QuickDraw API, but Linux and Windows have totally different APIs for displaying information on the screen.
This was our dilemma: how do we quickly Carbonize the existing Helix code without having to turn around and redo that work in order to support other platforms? We knew we had to have an efficient way to do this, especially one that could shorten the time for Helix to achieve platform-independence from as long as 6-8 years to as short as 2-3 years.
Java not our cup of code
The most widely-known cross-platform technology is Java, which is an idea that has been batted around by practially every Helix programming team since it was introduced. Unfortunately, going to Java would require rewriting significant portions of our code right away, and doing that would seriously delay even the macOS native version of Helix.
Furthermore, as the old saying goes, "the jury is still out" on whether Java is really up to a job like this, for various reasons. An investment in Java at this point would not only push our timetable even further into the future; it might even turn out to be a dead end.
Consequently, the Java approach was rejected, leaving us back at square one, faced with the task of Carbonizing Helix so it would run under macOS and then starting all over with the cross-platform coding.
But then we found wxWidgets.
wxWidgets is a cross-platform C++ framework with more than 10 years of development behind it. wxWidgets supports Windows, Linux and Mac OS 9 and X.
wxWidgets is an open source project, consisting of a set of 'generic' APIs that are 'translated' into the equivalent APIs for each platform. It’s constantly being enhanced: experienced programmers from each of the supported platforms contribute to the APIs, making sure that the generic calls translate correctly for their personally-favored platforms.
In effect, by using wxWidgets, Helix gets the benefit of having a bevy of Linux partisans making sure the APIs translate correctly for Linux. Of course, being Mac partisans, we’re constantly looking at ways to make the wxWidgets APIs work better on a Mac. We’ve already enhanced some of the APIs and in the true spirit of the open source movement, we’re giving them back to the wxWidgets community.
Another key factor about wxWidgets is that the code is C++. This is an incredible advantage to us because it means we can integrate it with our existing code (Helix is a combination of Pascal, C, and C++) on an "as needed" basis. The Carbon compliant code already in Helix has been well tested for years: we know where it is good and where it is weak. wxWidgets allows us to keep that existing code (where it is good) and update just the code that needs to be updated now to get Helix running as a native macOS application. And where the wxWidgets APIs are weak we are under no compulsion to use them. We are free to mix wxWidgets calls with Carbon API calls and code of our own devise.
And did we mention that wxWidgets is free? There are no licensing fees to be paid to anybody. Ever. We can make modifications to the framework if we need to, or fix bugs we find right when we find them.
Early on in the recovery process, we put forth the goal of making sure that every dollar spent on Helix 6 also had a tangible benefit for Helix 7. Keeping to that goal is what drove us ultimately to wxWidgets as the tool of choice. We started using it about 3 months ago, and we’re happy to report that our programmers were able to immediately adapt and we’re making great strides using wxWidgets in Helix.
For instance, the foundational code that deals with system level events (like moving or resizing a window, putting Helix in the background, processing mouse clicks and keystrokes, etc.) has alrealy been replaced with wxWidgets code. The initial benefit of this work is limited (it doesn’t give you any noticeable new features, but it does make Helix a better macOS citizen) but the core event loop -- the most critical piece of code in Helix -- is now macOS native, and when we’re ready to move on to the next platform, that critical code is already done. In this way wxWidgets will pay us dividends as we use it to get to Helix 6 and beyond.
Every step of the way, we remind ourselves that the long-term goal is Helix 7. As such we only incorporate things that don’t derail us from our destination. We have been and will continue to actively solicit input regarding how we can transform problems such as uncarbonizable code into opportunities to provide the best new features possible, and we have been actively doing this with input you’ve given us through our Helix Forums.
Why should you care about this?
As we move forward, we are finding places where the Helix code was written to do some very clever things, giving Helix some unique capabilities long before they were part of the Mac OS APIs. Unfortunately, much of that code is what keeps us from being macOS native and has to be rewritten.
When we find these areas in the code, we post a message to the Helix forum and request your feedback. Your feedback tells us which features of Helix are rarely used (and can be discarded entirely or updated with minimal functionality) and which are essential (and should be enhanced during the updating process). So please make it a part of your regular "checking up on Helix" routine to visit our Forums and give us your feedback.
If wxWidgets is so great, why is there no release date for Helix 6 yet?
Money. Our current income is sufficient only to keep our programmers working part-time. We don’t have any independent financing, so we can only go forward as quickly as income allows. If you haven’t upgraded to Helix 5.2 yet, we need you to do so now. If you have, you might want to consider
References to wxWindows changed to wxWidgets.
Find Previous — Find Next