|macOS Native Helix & Xcode Transition Progress Report, Part One: August 2007 – January 2006|
|August 29, 2007||
First, the misery of the week: Matt’s MacBook is where the ‘test builds’ of the new code are made. On August 19th the hard drive failed, after only 15 months of use. (MacBook buyers beware!) Fortunately, AppleCare replaced the hard drive and Retrospect restored the data, so nothing was lost other than time. Fortunately this did not delay Helix progress at all, since there had been no new code to build and test lately anyhow. All of the engineers have been working on ‘deep’ projects (see below) which are starting to bear fruit. Things should start hopping now.
The last few weeks have been spent diving deeper into the code and fixing obscure bugs involving combinations of features, like multiple nested (two deep) subforms, subforms containing buttons, etc. To give you a feel for how this phase of the project works, here’s one engineer's report on what he has been doing for the last three weeks:
In the meantime our other two engineers have been working away. Here are some more notes:
We expect this to be the last set of major changes before beta testing begins.
|August 15, 2007||
Yeah, so we’re trying to debug something related to what happens when you hold the option key down while starting a sequence and we stumble upon this:
For those of you who don’t write code, that is a “directive” — an instruction that tells the compiler to use the next section of code only under certain conditions. This one says to use this code for Motorola 680x0 (68K) processors. The last Mac with a 68K processor was the Macintosh LC 580, running System 7.1 at a whopping 33MHz. Folks, that’s 12 years — and 3 processor architectures — ago. For some odd reason that code won’t work on an Intel-based Mac running macOS!
|August 9, 2007||
Whoa. Despite evidence to the contrary we recently discovered that the PICT data format is supported natively on the macOS Pasteboard. (Formerly known as the Clipboard.) Armed with this new knowledge, we now have functional picture fields in Helix! This cuts a lot of time off the work required to get the Picture field working in macOS, and it solves a potential transition problem for end users.
Memory leaks are an ongoing problem (and working in Xcode shows that Apple has quite a few of their own!) but some new tools are helping us keep them in check.
We continue to plow into more and more complex collection constructions, looking for bugs in the rewritten code. It takes a more complex collection (or a unique approach to collection design!) to flush out a new bug these days. This program is starting to look good!
In the process of adding a new feature to RADE, another old bug in the Paste Structure code was found and fixed.
|July 25, 2007||
More random bugs fixed:
Sequences are now being scrutinized more throughly. Lots of odd cases have been found and fixed. More work remains. Sequence execution speed is abysmal.
|July 5, 2007||
More random bugs fixed:
|April – June, 2007|
|June 18, 2007||
Dynamic popups that allow typing (the Helix equivalent to the macOS Combo box) are now mostly working. There are still problems, but the really hard work is done. We also found and fixed lots of little bugs like: specific rectangle types that were not printing, Helix was unable to remember the windows you left open when you last used the collection, specific constructions of views that would disable the Enter command… lots of little things.
|June 4, 2007||
Four Steps Forward:
Two Steps Back: Concurrent to the work on Helix Engine, we continue to test our code with Client/Server. Although Helix Server 6.0 runs in macOS, it uses Apple’s ‘Classic’ event based mechanism for regulating network activity. That was a perfectly legitimate first-step when we did it. Unfortunately, updating Helix’s main event loop to modern standards forces us to take the next step now. Here is the blunt assessment of Steve Keyser, the author of the original Multiuser Helix code, and the guiding hand of our successful OS 9 to macOS networking transition:
The basic problem is that Helix can only do one thing at a time. (Concurrent searches are just smoke and mirrors, Helix is never doing more than one search at a time, multiple searches are just being broken into discrete chunks, and anything that interrupts a chunk has to wait.) Mac OS 9 agreed with this philosophy. Its event issuance and window updating events were designed to let one thing finish before the next begins. macOS is more attuned to multi-threaded applications, although single window apps don't have to worry too much about that, multi-windowed apps are expected to be multi-threaded savvy. Since Helix is not [yet truly] multi-threaded, ([Helix contains its own multi-threading code, written before Apple implemented theirs]), we are going to have to find all the places where macOS lets things get started and close them off, so that new activities can begin only when the program is idle and we can keep Helix in its single minded bliss. The [new code trap we inserted] flags the cases where Helix has started a new task without finishing its previous one.
So much for the dream of a painless path to a macOS native Client. At least Helix Engine continues to make steady progress.
A Side Note: As people starting using Intel-based Macs to run Helix Server 6.0, we became aware of a recurring theme: the Server tended to crash when users were involved in heavy posting operations. Concurrent with that our internal alpha testing on Helix 6.1 revealed a bug in the code that compiles the posting code. This bug appeared to have little or no effect on PPC-based Servers, but we are now starting to see a connection. So if your Helix Server crashes at all, please take time to review the information in this tech note and see if it addresses your situation. You may want to review the information in this tech note as well.
|May 29, 2007||
One ‘need to do’ item addressed: command rectangles (buttons) with pictures pasted in now show the picture!
Another week of bug fixes: getting quick queries to work correctly, getting styled text fields to stop claiming they were changed when they were not, getting views with scroll bars turned off to stop scrolling … and more.
Helix no longer crashes when a view with a command rectangle containing conditional sequence is closed while the sequences are running.
Fixed a bug noted on May 21: menu items can no longer be selected while a sequence is running.
|May 21, 2007||
Another week of ‘little bug’ fixes: progress dialog thermometers were not incrementing correctly, simply moving the cursor via the keyboard while in a field marked the record as needing to be replaced, problems with conditional styles, views that generate errors if a record is showing when first opened, problems with the home field sequence command… and more.
Some fixes to plain text rectangles never made it into styled text rectangles. (Although most of them did because of the wonders of object-oriented programming and inheritance.) The remaining cases have been fixed.
Two ‘thorns in the flesh’ remain: 1) Combo boxes (as seen in dynamic popup menus) still need work. 2) The menus remain active even when a sequence is running. This is a serious problem — if the user were to activate (or close!) a window while a sequence was running, it could be a disaster. The idea of allowing the user to do other things while a sequence is running is tantalizing, but there are many things that would have to be worked out before that could become a reality.
|May 14, 2007||
Collection Designers rejoice: Helix 6.1 looks for Custom Help in the same folder as the collection, making distribution of stand-alone solutions easier. (Helix Client continues to look in the folder with the application, as the remote structure is more likely to move.)
Although we still recommend putting Helix applications in the macOS Applications folder, Helix 6.1 is more forgiving if you move it to another location.
More dialogs (e.g: Why? messages) use macOS alert code instead of old Classic dialog code.
Lots of bugs fixed: The time stamp command should work now. The optionally show dialogs attribute in sequences is now honored. Paste Records works. Visibility attributes for elements on a view all work. Views now autoscroll when tabbing to a field that is outside the display area. Pasted data is now being stored correctly. Fast Find works. Dynamic popups work on the Client. Other esoteric things. As you can see, we’re at the stage where we can test hard enough that lots of bugs pop to the surface. This is both encouraging and frustrating at the same time. But it is progress.
|May 7, 2007||
An interesting problem was observed — and fixed this week. Although I don’t want to bore you with the details, it does point to the difficulties involved, so here we go. The originally observed problem was that ‘Keep Values would not Keep.’ But nothing is ever that simple and by the time we pinned it down we discovered that this bug only struck when (a) a field is inert, (b) the relation the field is in has no ert (non-inert) fields, (c) the rectangle that field is in (in a template) is set to Keep Value, and (d) that field is posted to another relation. If all of these conditions are true, the posting failed.
In solving that problem (and another one) an ‘unrelated cousin’ was discovered that may affect you now. In the last month have seen two problems in Helix Server 6.0 that have been traced back to faulty form compiling. One is documented here and the other here. The solution in both cases is to open the collection with RADE and force all of the compiled data to be discarded and rebuilt. Read those technotes for more information.
And here’s a bit of annoyance for you to consider: Helix allows a checkbox field to have three distinct states: true, false, and undefined. Classic Mac OS had no notion of an undefined checkbox, but macOS does. (It is represented as a checkbox with a dash through it.) Unfortunately, the macOS implementation of checkboxes forces us into a compromise. Here’s why: macOS has two checkbox styles, one that allows the undefined state and one that does not. The one that does cycles through the checkbox states in a defined order: true, undefined, false. When you create the checkbox, you have to say which type you want. At first we were simply using the ‘three state’ checkbox for everything. But this does not work if the field has a default value of true. In that case, the view opens and the checkbox is defaulted to true. Now, you decide to change the value to false, so you click the checkbox to toggle it off. But in macOS, the state after true is undefined and as soon as Helix sees the undefined field, it fills it in with the default value (which is true) making it impossible to ever get to the false state.
The only solution we have found is to use the ‘two state’ checkbox when there is a default abacus in the rectangle along with the field. But this means that a Helix construction such as if test then true else undefined can not set the checkbox to undefined, as its checkbox has been declared as a two state checkbox.
That is unpleasant, but considering the rarity of this sort of construction, this is the solution we are going to stay with for now. If you need the ability to default an undefined value into a field, our recommendation is to use an alternative format: radio buttons, popups, and plain text all work fine.
|May 1, 2007||
Buttons can now have transparency! Those of you who put graphics in the background layer and overlay transparent buttons can rejoice. In fact, all of the issues mentioned in the April 21 posting have been resolved. All that is left (for now) is to draw pictures in buttons. (Those of you who paste graphics into command rectangles, please be patient…)
Record locking works! And that old bug is squashed. Fixing this turned up some fundamental issues in the way wxWidgets handles focus — which field is active. This is the current focus of effort.
Also accomplished: the viewable on … page settings are working, sequences now enable/disable at the right times, and some dialog boxes have been updated to use the cross-platform API.
The new ‘question of the week’ has to do with the Enter & Return keys. See our newest poll to provide feedback on this one.
|April 21, 2007||
Ugh. This week was spent fighting through some incredibly difficult code…
On one front was the button name issue. Helix allows you to name buttons dynamically, using the output of an abacus to provide the button name. There are also options for dimming and hiding inactive buttons and making active buttons transparent. The naming code is mostly done, and it features a couple of immediate improvements as well as being written in a way that will allow us to provide some serious feature improvements down the road. However, there are issues still to be dealt with. Transparency is going to prove difficult, as the Carbon button code only supports transparency as part of the disabling process. Also, Carbon buttons do not allow the label text to wrap to multiple lines. We are working on some solutions, but they probably won’t be easy.
Another engineer spent the entire week working on record locking. (Before this, our macOS Client/Engine did not lock records, and being able to edit the same record on two views — or from two Clients — would be a serious flaw.) On top of that, we discovered a bug that has existed in Helix, apparently from the very beginning:
This bug was addressed while implementing write locking. But even without that problem, adding write locking was incredibly difficult. Both HIView (Apple’s code) and wxWidgets (the cross-platform API) believe that something really should have keyboard focus in every window. Helix assumes that nothing will have keyboard focus if the record cannot be changed because it is locked in another window. The fix involves changes at many levels in the architecture of the program and to intercept keyboard and mouse input at a more fundamental level.
|April 13, 2007||
This week was spent trying to get irritating inconsistencies fixed. This is the stuff that makes programming painful. Getting buttons to enable/disable at the correct time, getting the background objects in a template to stack properly, getting dynamic popup menus to be dynamic (and not crash), getting label rectangles with pictures to put the picture in the right place, getting the ‘Option-Enter’ keystroke to be recognized… the list goes on and on.
One ongoing struggle is with ‘popup menus that allow typing’. In macOS these are called Combo Boxes. For some miserable reason, you can tab into them, but you can’t tab out.
Still, Helix Engine is actually starting to become a usable product.
|April 4, 2007||
Arrgh! Getting a cross-platform API like wxWidgets to understand the difference between the Return key and the Enter key is a real pain. Add to that Helix’s variations on what Enter means: Enter (aka: Enter/Find), Replace (Replace/Find), Static Enter (aka: Enter/Stay), Static Replace (Replace/Stay), Enter Overide, Static Enter Override, trigger default button, accept dialog box input, …) For the collection designer there is quite a bit of work to do to make sure Enter does what it is supposed to do in all cases.
In the process of updating the code for macOS we have had to sort these out, and in the process, we have made a change to the way Helix works, closing an inadvertent design loophole where a view with a default button could still be ‘entered’ by using the Enter menu command. In Classic Helix a designer who wants to make absolutely sure the user can never simply enter a record — e.g. because the default sequence must be run — must also remove the Enter command and/or remove the Add/Replace permissions for every user for that view. Removing Enter from the user menu creates other logistical problems. Removing specific view permissions from users is an arduous process where errors can easily slip in. Toss in the fact that most designers do not clearly understand the purpose of the Enter Override and Static Enter Override commands and you have a situation where making sure the user can not simply enter the record — and keeping your data sound — can become a complex and time-consuming task.
The revised code treats the Enter menu command exactly the same as pressing the Enter key. If there is a default button on the view, selecting Enter from the menu now triggers that button. The Helix Reference (18.104.22.168) does not explicitly define what was formerly expected to happen in this case; it only notes that if you remove Enter from the menu you must make Enter available in a sequence (button) on the view to enter the record. We debated what the wording in The Helix Reference implies about Enter in the menu and concluded that this spec change does not counteract any explicit specification. That conclusion, along with to our desire to close the loophole, plus the fact that this ‘path of least resistence’ to get Helix to macOS, helped make this decision.
This should not be interpreted to mean that an Enter command within a sequence will also take on this behavior. That command (which will be renamed ‘Enter Record’ in the future) continues to simply enter the record on screen. Use the sequence command Keypress: Enter to simulate a keypress/menu selection Enter when needed.
Also note that the Enter Override and Static Enter Override commands placed on a user menu will
The names of the enter commands as seen within sequences will be changed to Enter Record, Static Enter Record, Enter Record Override, and Static Enter Record Override in Helix 6.1 to make the distinction clearer.
|January – March, 2007|
|March 26, 2007||
The Import/Export & Copy/Paste Record Options dialog has been reworked for macOS. Much nicer.
Sort Order now has an inndicator to specify the ‘default’ index. (Bold+Italic text)
The Export Ordered code was left in place, but blocked out, since 100% of our survey respondents so far say they never use it.
More bugs fixed.
|March 20, 2007||
Sort Order is reimplemented as a toolbar widget. Much nicer.
Styled Text works much better now. (No memory leaks, color support, etc.)
Lots of little bugs fixed: tabbing from field to field is better, static enter works, dialog box response to keystrokes, dynamic popups no longer crash when clicked on, etc.
|March 9, 2007||
Open Query is now functional in macOS.
A nagging problem has been fixed: the new view code thought that simply tabbing through the fields in a record was enough to signify a change to the data, and Helix would ask if you wanted to save changes before closing even when no changes were made. This was traced down to a bug in wxWidgets and fixed.
|March 2, 2007||
One from the ‘Ugh’ Department: Buttons in Helix have been changed from Aqua Push buttons to Bevel buttons. This was done because Push buttons are limited to specific sizes, while Bevel buttons allow virtually any size, allow pictures instead of text, etc. Bevel buttons provide the feature set Helix designers expect, so although we personally find them ugly, we have to go that way.
Here’s a link to Apple’a HIG Page Showing Button Styles.
|March 1, 2007||
One sentence from Larry in this morning’s email: Printing works!
More words: “I think I’ve got all the pieces, although I’m not completely confident that the pieces all work in every combination. Let the bug reports begin.”
This is a huge step forward and, based on our initial in-house testing, may allow us to finally zero in on a time frame for eventual release of macOS Engine/Client.
|February 19, 2007||
Printing. This is a huge task, and probably the last (and largest) hurdle we have to cross before serious testing can begin.
Basic page printing is working, now come the details: large templates (larger than one page), suppressing rectangles where "Printable" is off, honoring the "First Page", "Middle Page", "Last Page" check boxes, printing in sequences, handling a Cancel during printing.
|January 31, 2007||
More ‘rough edges’ are being knocked off. The Quick Query toolbar no longer opens every time a view is opened. Subforms are now clickable. List selection is now fully functional.
|January 16, 2007||
Click to select records on a list, and double-click to open records on a list now work according to the new spec. The new spec resolves an ambiguity by recognizing the difference between double-clicking an unselected record (which does not create an "ad-hoc query"), as opposed to double-clicking a selected record, or one of many selected records, (which does create an "ad-hoc query".)
A single click selects the record that is clicked, and deselects everything else. The first record selected sets an "anchor point", and a shift-click selects only the records between the anchor point and the clicked record (inclusive.) A command-click toggles the selection of a record, adding or removing it from the selection as needed.
Records in a subform list can be opened with a double-click, but not selected. (Consistent with existing spec.)
Dragging over a list of records to select records under the mouse is not implemented yet.
Next up: Bug swatting.
|December 31, 2006||
Converting views to run with native macOS controls is long, slow business. Although the views are up and running we have encountered (and fixed) bugs with names like: "Sequences Can Not Be Cancelled", "P# does not display Page Number", & "Scroll bars still visible when turned off." Many more remain, but steady progress is being made.
Be sure to read our final "The Latest Word" of 2006 for a few screen shots.
Next up: picture rendering, selectable list functions.
|December 18, 2006||
One round of "obvious bug" swatting complete. Found some unpleasantness in sequence execution, among other things. It’s still not really usable, but we’re making progress.
|December 8, 2006||
Display Subforms! The subform code is the most complex piece of code that must be migrated to macOS before we can ship native Client/Engine. It is finally done — until testing starts finding obscure bugs in it, that is.
On another front: Helix Client’s Visit/Open dialogs had to be reworked, and we took the opportunity to add a few nice enhancements.
|November 15, 2006||
This page switched to listing event in "most recent first" order. (Because who likes to scroll all the way to the bottom to read two lines?)
|November 9, 2006||
Helix Server’s conversion to Xcode has reached the stage where we can start testing this build to see if Xcode has broken anything.
A "first run" Helix Client macOS was built today and successfully connected to the new Server. Another major milestone is passed!
|October 31, 2006||
Some bug fixing on the first pass at entry forms is being done.
And during that bug fixing… oh, wow… the "Helix is a processor hog" bug was found and fixed! Or so we think.
|October 25, 2006||
The list code has been committed and sent to testing. Subforms are next.
|October 20, 2006||
Alpha testing on entry forms continues. List forms are shaping up. The first version you see may not look like much, but the stage is being set for many new features. (As much as we’d like to do them now, we resist so as not to allow the ship date to slip further.)
|Sept 29, 2006||
A giant step forward. Our Xcode projects for Helix have been totally restructured for more efficiency. The all new, MLTE-enhanced view code has been integrated into the revamped project. Our in-house Alpha testing can begin in earnest.
Please note that this does not mean that release is imminent. We still have a lot of work to do. Nonetheless, this is a major milestone.
|Sept 20, 2006||
Popup menu work is completed. Checkboxes and Radio Buttons are up next.
On a separate thread: we now have a proper About Box (complete with live links to our web site and a "current version" lookup) and an Open Recent menu item.
|Sept 14, 2006||
Dynamic Popup menus are nearing completion.
|August 28, 2006||
Styled text hit a few snags, requiring a re-evaluation of the code. In the end we discovered that Apple’s Carbon implementation of the Font Panel is a bit buggy (to be kind) and we switched over to using the Cocoa Font Panel. It seems to be 98% right, which is close enough for now, given the time constraints we are under.
The Fixed Point data type was exhibiting some oddness (nothing to the right of the decimal point, funky rounding) but that’s fixed now.
|August 22, 2006||
Pictures in template rectangles now draw correctly. Picture fields work fine, except that macOS clipboard does not seem to support the PICT format anymore. We’re studying the issue.
Styled text is working, except that the old Classic "Shadow" type is removed from macOS, so that type of text displays as plain text. (There’s nothing we can do about that, sorry.) Helix now uses the standard macOS Font palette (Select "Show Fonts" in TextEdit or Mail.app to see it) to specify font/style data! It all works except specifying a color.
|August 10, 2006||
MLTE work nears completion. Views — including Quick Queries — are like a whole new (macOS native!) world. We’re thrilled to be (mostly) past this obstacle.
|July 12, 2006||
MLTE work continues. (Did we mention that this is a big project?)
|June 14, 2006||
MLTE work continues. (This is a big project!)
The login interface been rewritten to present a single User/Password login window. This adds security since the intruder must now guess both the name and password at the same time. With User Name Security turned off, the login dialog now uses a popup menu (using macOS controls, so it is also type selectable!) to select the user name.
|June 5, 2006
from TextEdit to MLTE
This week (actually, last week) one of the ‘hard jobs’ of converting an old application like Helix to macOS was started: converting from using the TextEdit APIs to MLTE.
What is TextEdit: TextEdit was originally designed to handle editable text items in dialog boxes and other parts of the system software. Although TextEdit has been enhanced to provide more text-handling support since its inception, especially in its handling of multi-script text, it retains some of its original limitations. (From Apple’s Carbon Reference for Legacy APIs)
What is MLTE: MLTE (Multilingual Text Engine) is an application programming interface (API) that allows your application to provide Carbon-compliant Unicode text editing. MLTE is a replacement for TextEdit that offers more features than those in TextEdit—features such as document-wide tabs, full justification of text, support for more than 32 KB of text, built-in scroll bar handling, built-in printing support, support for inline input, support for the advanced font features of Apple Type Services for Unicode Imaging (ATSUI), and support for multiple levels of undo. (From Apple’s Carbon Reference for Modern APIs)
Considering that the time required to replace TextEdit with MLTE is expected to be about the same as updating our old TextEdit code to be macOS compliant, this decision was a no-brainer. We’ll have a better fix on ‘how long’ in a few days.
Note: our plan at this point is to leave Unicode support turned off in the first release of a macOS Client/Engine. We need to fully understand the ramifications of that before adding such a dramatic new feature and work out how this will interact with the existing OS 9 Client.
|May 30, 2006
Adriaan van Os, macOS/Pascal code guru and member of the GNU Pascal Compiler (GPC) development team has signed on as a consultant. Adriaan will be working with us to improve the performance of the compiler and to work through the tricky details of moving our Pascal to Xcode.
|May 15, 2006||
With Helix Engine in the hands of testing, engineering turns its attention to creating Xcode versions of the other Helix products. In less than one week the Helix Server project was moved from CodeWarrior to Xcode. The few wrinkles that were found were ironed out quickly. Next up: Helix Client.
|May 12, 2006||
Helix Engine is now ready for initial alpha testing. Next week we start running our baseline tests and looking for obvious bugs.
|April 27, 2006||
Larry writes: Some more real progress was made today. I got the query window dialog working, and actually stored some data and found it with the query. I checked in my current code...
|April 24, 2006||
Progress on Helix Engine has been stalled over window drawing issues. It took days to track down the problem. The old code that draws windows is going to be a problem until we have time to totally rewrite it. For now, we stick with QuickDraw (which has been depreciated by Apple and will be dropped at some point) and give up all the nice things Quartz would give us. Getting a macOS Client/Engine is deemed more critical than having beautiful, anti-aliased text.
Parallel to the main work, there is an ongoing project to eliminate the last vestiges of OS 9 dependent technology. Behind the scenes, we were still using one of Apple’s ancient apps (MPW Shell) to generate the code that gives each type of icon its attributes. MPW Shell is an OS 9 only tool, and therefore destined for the dustbin. All of the scripts that ran in MPW Shell have now been converted to Python and thoroughly documented, so we now have a firm handle on this fundamental aspect of Helix code creation. Next up is the Dynamic Popup Menu code, which is still (believe it or not) written in 68K assembly language!
The best example of where this comes into play is in the copy/paste structure code. Helix’s ability to paste structure from older versions of code requires thorough knowledge of the attributes of the objects, particularly how they changed as new versions of Helix were released. Some of the copy/paste structure bugs we’ve fixed lately were introduced because there was, from 1997 to 2003, nobody working on Helix who thoroughly understood how this code worked.
On a more sober note, this week Larry’s father encountered some serious health issues, and Larry may be sidetracked for a few days. While the rest of us continue plugging away on Helix, we ask you to join with us in praying for the best for Larry and his family.
|April 11, 2006||
Larry writes: Helix Engine can now launch cleanly, open a collection, enter records, and save the collection. (This is a major milestone!)
|April 3, 2006||
Helix Engine compiles in Xcode, but crashes immediately when launched.
Since Helix Client is, essentially, Helix Engine plus networking, getting Helix Engine converted is a much more efficient way of working on the code. Once Helix Engine is debugged, Helix Client will be mostly complete. (Helix Server is already running in macOS, so our networking code is already there.)
|March 9, 2006||
“Update Collection now works.”
Attention turns to moving Helix Engine to Xcode.
Our first product to convert to Xcode is Update Collection. This is chosen because it is the smallest Helix application, which will give us faster turnaround times when making changes. (It’s good to start with a simpler project before trying to tackle a huge one like Helix Engine.)
Converting large CodeWarrior projects to Xcode projects is not the walk in the park Apple presented it as. Many fundamental assumptions (e.g. how many bytes are required to store an integer) must be challenged and revised. Helix code must be painstakingly searched for such assumptions and turned into explicit declaration.
Xcode’s lack of support for legacy Pascal requires that we go on a search for a third party Pascal compiler that works with Xcode. We settle on GNU Pascal Compiler (GPC).
Apple releases Intel-based PowerBooks and iMacs. We accelerate plans to build macOS native Engine and Client in Xcode.
|December 31, 2005||
After we "made a valiant attempt at creating a Helix Client with CodeWarrior" and saw that it wasn’t going to work, we made the decision to abandon CodeWarrior and start moving to Xcode. Larry Atkin is tapped to head this project.
|December 19, 2005||
We ship Helix Server, Helix Utility and Update Collection as macOS native components.
Attention turns to the feasibility of quickly creating macOS native Client and Engine built in CodeWarrior. CodeWarrior’s general inability to handle our user interface code makes progress slow.