On the other side of the Atlantic
News seems so quiet since the beginning of this year... So what's been happening?
It's not like the crew at Staz Software have been spending an idle time on the French Riviera. In actual fact, as soon as the Release 7 was out, Release 8 was already underway.
The next Release will see a major change as the whole IDE will be carbonized. In other words, when working in OS X, you will no longer need to launch the programming environment in Classic. Of course, you, as a programmer, may wish to check how your application fares under Mac OS 9, that's why you'll see a new item in the Editor's Command menu allowing you to force your Carbonized application to run in Classic mode.
We have little more info to deliver concerning the next release. We suspect that there won't be a lot of new features, because all the efforts are concentrated in getting the IDE to work properly under OS X in the first place. Some glitches in the FB3 header files have been repaired since Release 7; very few to say the truth, simply because very few were reported. Release 7 is truely a milestone release which, for the first time, allows us to produce carbonized applications. Think about it, a while back we had been waiting five years to be able to compile for the PPC!
So far so good, but any gossip to share? you may ask...
Well, well, well... Currently beta testers are playing with a pre-release that features the carbonized Compiler. It has been said that it compiles faster under OS X; compile time seems dramatically shortened, especially on dual-processor machines. Very cool!
The Debugger is up and running in Carbon too, but at the moment there is no carbonized Editor, nor Project Manager, to test. That's understandable. The Editor is a fantastic piece of heavy work written in FutureBASICII that began its life probably a decade ago. It has been a heavy optimised 68K application, and I bet you didn't even notice. You may have now an idea of all the work that must be done. The program must make its way through two transitions at least, namely PPC and Carbon, without counting that it will most likely be written for the new Appearance Runtime. That's clearly a huge update, so we all have to be patient.
Silence of the Lambs
On the other hand, the Release 7 was such a new thing with so much feed to the mill, that we have all noticed the slowdown in the announcements generally coming from the FB community. Porting to Carbon is not always a straight-forward process, particularly for programmers who want to convert full featured applications patiently enhanced and maintained over the years. Even more so if they intend to bring their applications to the new and recommended Appearance runtime. Refering to our technical support, it seems that some advice is in order:
First, you need to know that many programming techniques have become obsolete with the arrival of Carbon: you cannot just expect a big program to run smoothly in OS X as soon as you hit the execute command. We can't put the blame on FB here and the best anyone can do is to read the Carbon documentation coming from Apple. However, if you are eager to see your application running, you should read, before anything else, the FB3 manual called "Porting to Carbon", available under the Help menu in the Editor. This lists the most common difficulties you will meet along the way.
This little handbook was written following the updating for Carbon compliance of the thousands of heavily commented examples that populate the CD. By the way, revisiting all those files is the best thing you can do, if you want to find how some difficulties can be solved. You should see this set of files like a gigantic manual which is frequently updated, most often with each new release. Beside, with Release 7, most of the example files were rewritten in order to showcase the adaptation required to run in Carbon and old code was left intact in conditional compile structures. This may have cluttered the code but it allowed the same snippet to run in PPC and even in 68K.
A lot of well-known Toolbox procedures and functions have changed with Carbon. Some have totally disappeared. Some have slightly changed or were just renammed. Bazillions of others have spung to life. There is a lot to learn here again. You will have a lot of reading to do since you cannot bypass entirely Apple's documentation on these subjects.
You can also download the Apple header files from the Apple Web site, or install the Developer CD that comes along with OS X and pay an edifying visit to those header files that now make up the Carbon Toolbox. Like you already know, a big bunch of example files rely upon Toolbox calls, so that's another reason to examine them one more time.
You can also consult the FB3 header files because, in the end, the Runtime calls the Toolbox to do its job. Of course, if your program uses pure BASIC code you should have less to worry about since the hard work is done behind the scene by FutureBASIC itself.
You should also note that not all the new Toolbox calls that have emerged with Carbon are implemented in the FB3 header files. In the above-mentioned "Porting to Carbon" documentation you will find hundreds of declarations ready to copy and paste in your own code if they are missing from the headers. And if you need them, of course.
Ain't no cure for the Run-ner-time blues?
With the new enhanced Appearance Runtime comes an important decision. The Appearance Runtime is promoted as the way to go, this is clearly the future for FutureBASIC. However, this is also a whole new ball game, a whole new ball park even, with a fair amount of new things to learn, especially for all things concerning the Appearance Manager. Mastering that beast requires some time. Hence, I'm inclined to think that for big programs it is better to get them carbonized in the first place with the Standard Runtime until they run correctly. Updating your application for Carbon and the Appearance Runtime at the same time could become a nightmare quite quickly. This excludes all the applications written with Program Generator since the latter is not Appearance compatible. Doing otherwise you would have to face much more difficulties.
To learn about the Appearance Runtime you need to read the Reference Manual (which is also updated with each new release) or/and the book called "Switching to FutureBASIC" that ships with Release 7.
Reading the Appearance Manager documentation from Apple, I can't say this enough, is a must.
Finally, examining the example files and more particularly those by Robert Purves, the author of the Appearance Runtime, is mandatory. Notice, that there is also the freeware "FB3 Code Styler" with its source code on the CD; this is a complete project written for the Appearance Runtime -- you can learn a lot there too.
For pretty old programs one thing you may have to take into account is the 68K support. I'm not kidding, we've heard about someone making a decent living with FutureBASIC targetting almost exclusively 68K machines. This doesn't come as a surprise for us because the 68K code generated by FB is excellent, as fast and as tight as code produced by a good C compiler. Most likely, your choice will be dictated by your user base, but you have to remember that the Appearance Runtime does not, and will never, support that a 68K CPU. In fact, only the Standard Runtime will allow you to handle a single project addressing not only 68K and PPC, but also Carbon targets. If you need to support 68K and you're going to the Appearance Runtime anyway, you will end up maintaining two different programs for the same application.
On the other hand, once your application is carbonized with the Standard Runtime, you will immediately notice its outdated, not to say clumsy, look when it runs under OS X and no doubt you'll want to change that. It is certainly possible to play with the Appearance Manager in the Standard Runtime, provided you use Toolbox calls extensively and work around some of the built-in Runtime mechanisms, but this is noneless heavy going and I can't recommend it. In fact, nowadays the question revolves more around the PPC support; you will notice that the code tends to get cluttered just to make things work the same there.
Now that you know the Standard Runtime is slowly but surely headed off to "better places" and that your carbonized applications will fare just as well running in OS X as in Classic, it is time to envision the conversion to the Appearance Runtime.
Although there is a limited support for the so-called legacy code, herited from the Standard Runtime, a few things are handled quite differently; others are totally new and you might notice unexpected behavior by your freshly converted application. You will have to spend some time fine-tuning your code. In that regard there's no solution other than reading the manuals and examining the example files.
If you have followed the programming techniques recommended by Staz Software for so many years, the conversion should be easier. Even easier if you followed the good practise of isolating the code that deals with the user interface from the code that does the actual work in your application. Then, perhaps, it is time to revise the sections in your program dedicated to the handling of files and abandon the dead (but still functionning thanks to Andy G.) Working Directory Reference Number and go to the FSSpec structure which is also supported by FB at the Runtime level. Note that that structure is already almost obsolete due to the Unix fundation of OS X. Gasp!
Finally, I hope that you are prepared to be confronted to a fair lot of discrepancies:
- different appearances and behaviors of your application between PPC and Carbon applications
- different appearances (of course) and behaviors of your application between Standard and Appearance Runtimes
- different behaviors of Carbonized applications between OS X and Mac OS 9
- different behaviors of your application between Mac OS 9 and Classic
- different behaviors of your application between two consecutive versions of OS X
- bugs in the PPC Toolbox that don't show up in Carbon
- bugs in Carbon that don't show up in PPC
- bugs in OS X
- possible bugs in the Appearance Runtime (we hope not).
This list might look impressive at first glance, but keep in mind that those little glitches don't pop up at every line of code. All in all, nothings stands in the way of you porting your application to Carbon and OS X.