Volume Number: 15 (1999)
Issue Number: 11
Column Tag: Factory Floor

CodeWarrior in a Carbonized World

by Richard Atwell and Dave Mark

Back in August, our good buddy Richard Atwell gave us a glimpse of life with a Carbon-based CodeWarrior debugger. This month, Richard parts the curtains a bit more and talks about life with Mac OS 9 out the door and Mac OS X right behind.

Richard Alexander David Atwell, aka ratwell, is the Mac OS Debugger Engineer at Metrowerks. Richard collects vintage CodeWarrior CDs in his spare time. You can contact him about the DR/3.5 CD you'd like to send him at ratwell@metrowerks.com.

Dave: This past summer, you told us all about Metrowerks' debugger plans. Can you tell us what has happened since then?

Richard: Since the August interview, we've made tremendous progress on the Carbonized IDE. Now that Mac OS 9 has gone final, you can look forward to an update that has been built for Apple's latest OS release. The Mac OS X version is right behind it and we'll have a better idea of the release date once the next IDE update comes out and after Apple delivers another Mac OS X developer preview CD. Keep reading the Factory Floor to find out.

Dave: Given all the operating system compatibility issues that developers have to consider how many versions of the IDE are there going to be?

Richard: Just one. We've put a huge amount of effort into maximizing the experience and minimizing the adjustments that developers will have to make. To that end we're planning to deliver a single IDE binary that runs on Mac OS 8 through X. The IDE 4.0 from Pro5 supported the last version of System 7, Mac OS 7.6.1, mainly because of the MRJ minimum runtime requirements.

We're not sure how much longer we can continue to support pre-8 releases of the operating system. Our tools are no longer hosted on 68k and there will no doubt be compelling reasons to move the IDE forwards that will make backward compatibility difficult.

If you are familiar with Carbon development, you'll know that even if you decide to only target Carbon there are several development issues that crop up depending on how far back you want to support older operating systems. We believe that most of our developers keep up with OS updates but we also understand that being able to debug and develop on older systems is sometimes an important necessity. We'll support System 7 as long as we can.

Dave: What are the latest Factory Updates that have been released?

Richard: Before we delivered Pro 5 we announced that we were going to release annually instead of semi-annually. In between releases we promised to release updates to tools and libraries to address bugs and feature requests. We've done that recently with two Factory Updates: 5.1 and 5.2.

The first update contained a new IDE 4.0.1 and was released to address some outstanding IDE 4.0 bugs that we weren't able to fix before the Pro5 release. The 5.2 update contained updated compilers, MSL and an IDE 4.0.2.

We are excited about this approach because it returns us closer to our original release cycle. Up until CW11 we released every 4 months in an almost clockwerk like fashion but it became harder to maintain this release schedule as the IDE became larger and larger. So you can see we are going to be updating the tools just as often; we're just not pressing CDs as often.

Dave: I noticed that Pro 5 MetroNub isn't compatible with previous releases. What happened?

Richard: That was unfortunate. In order to add Mac OS X and AltiVec debugging support at the same time we were constrained to release a version of MetroNub that couldn't be installed and used with previous releases. This meant you couldn't install a single MetroNub extension and use Pro4-Pro1 debuggers or older Pro-based releases like our CodeWarrior tools for the Palm Computing Platform.

Dave: What good are the older releases?

Richard: Well, it depends. You may have older projects that you can't update because they are works in progress or you might be on a tight development schedule and unable to upgrade. You might prefer to debug your program on an older version of the system software using the standalone debugger, MW Debug, that last shipped with Pro 2.

In any case, Pro5 forced you to switch MetroNubs and reboot in order to switch tools. I've rewritten parts of MetroNub to bring backward compability so you can continue to mix the new tools with the older ones. This MetroNub has been beta tested by some brave individuals from the comp.sys.mac.programmer.codewarrior newsgroup and we will release this version in the next factory update.

Dave: There's more to CodeWarrior than just the IDE. Can you give us a rundown on the progress that has been made with the rest of the tool suite?

Richard: PowerPlant is the premier Macintosh framework. PowerPlant has been shipping on CodeWarrior since the DR/1 days thanks to the brilliant work of Greg Dow.

Lately, Greg has been carbonizing PowerPlant for use with the Universal Interfaces 3.3. Greg released a preliminary version to our beta testers and we are planning on releasing PowerPlant 2.1 in an upcoming Factory Update. Hopefully Greg will appear in a future column to explain all the goodies packed into the latest PowerPlant.

We write our tools using PowerPlant as the underlying framework. If you still haven't looked into PowerPlant you're missing out. Check it out.

Dave: What's happening with ZoneRanger?

Richard: ZoneRanger has been with us for a long time. Joshua originally wrote it as a shareware tool and we brought him on board to improve it for our Mac users. In fact you can still find an older version that we give away on the website.

You can use ZoneRanger 2.2 in order to help you understand how your program manages memory. Look inside the "Other Metrowerks Tools" folder for ZoneRanger and alongside it you'll also find a sample program called LeakyApp. It's very instructional to watch LeakyApp trigger events in ZoneRanger based on actions you select from the menus in LeakyApp.

LeakyApp was built with a file called ZoneRanger.c that you'll need to add to your project. This C file works it's magic by replacing memory allocators in MSL that register the blocks of memory in a way that the ZoneRanger application can record. In order to do this you must alter the link order of your project so ZoneRanger.c links before any of the MSL C libraries in your project. Look for linker warnings telling you that some of the allocators were previously defined in ZoneRanger.c and you'll know you are on the right track.

In previous releases ZoneRanger's recording mechanism was built in the MSL libraries and turned on by default in Pro 4. This slowed down release versions of programs a little that didn't even care about memory management so we moved it outside of MSL.

You can learn more about ZoneRanger by reading the manual located on the CodeWarrior Reference CD.

Dave: I've used the Profiler before to speed up my programs. What's changed?

Richard: The MW Profiler 1.7 that Steve and Neal wrote is essentially the same one we've shipped for several releases. Users complained that because the icon was the same as the IDE it was difficult to select the right application from the tear off application menu that appears in Mac OS 8.5 when neither the IDE nor the Profiler were the foreground application. We changed the icon with Pro 5 so they won't get confused.

We've also added two features to the Pro5 version. The first is the ability to accurately profile the time that threads are using. Previous versions miscalculated the time threads were asleep so you couldn't really profile your threads. Now this is fixed you'll be able to fine-tune your application even further.

The second thing we did was to add capability into the Profiler to analyze the data that the profiler libraries generate and feed this information back into the linker. Why would you want to do this? One good reason is VM. Without going into a lengthy discussion about operating systems, when virtual memory is on, your program is residing on disk and parts of it are swapped into memory as the OS deems necessary. It does this in order to execute it and maximize the use of memory between multi-tasking programs. Functions in memory that call functions that are not in memory have to be loaded first and this is time consuming because disk drives are so much slower than memory. All this happens in the background without any control by the running program so you probably didn't realize that you could do anything about it.

Between the CPU and the disk t RAM and fast cache memories exist and as a general rule the more you can execute within the context of the cache the faster your programs will run.

Towards this end the Profiler can now write out one of two kinds of .arr files. These are called arrange files and they contain lists of functions that are given to the linker in order to instruct the linker to organize the functions so the ones that call each other frequently are proximally close to each other. This can reduce the time that the OS wastes going to disk to retrieve functions to be called. Because programs don't call all programs with the same frequency you can see how optimizing the layout of the binary can speed up the program.

To set up your project this way, go to the PPC PEF preference panel, set the code sorting popup to read "Use .arr file" and add your arrange file to the project. You've been able to manually create this file yourself with the last few compiler releases but now we have a tool that can generate it for you based on the way your program actually behaves.

Dave: Is the Find Library new?

Richard: The Find Library is a set of text files that MWRon produces. MWRon is our ombudsman in the newsgroups. Ron got tired of answering questions that explained which libraries contained what API call so he disassembled all the libraries and stripped them off all the "junk" leaving only the name tables.

You can open CodeWarrior's Find Dialog, drop all Find Libary files on it, and search for the library that contains the function you are looking for. Then you just add the library that matches the name of the disassembled file MWRon created to your project to remove any linker errors.

MWRon updates this set of files each release to match the latest Universal Interfaces from Apple.

Dave: We talked about MetroNub Remote in our last chat (The Factory Floor, August 1999).

Richard: That hasn't changed since Pro 5. We'll update it for a future release. Many networking improvements will come from the MetroNub plugin and extension release that I said was forthcoming.

MetroNub will continue to evolve as the OS evolves. As long as we can continue to make MetroNub and MetroNub Remote run on older system you'll be able to debug anywhere the IDE can't run.

There's a hidden treat in the Metrowerks CodeWarrior folder. Look inside the (Debugger Extras) folder and you'll find a folder called MetroNub Utilities. This folder contains a C file and instructions to allow your project to determine if it is being debugged by the IDE. You may want to know this in order to call DebugStr or take some action to help you debug your program when you know it's under the control of the debugger.

We used to have a co-existing file called MWDebugUtils on the reference CD but it became obsolete when the debugger became integrated into the IDE.

Dave: DebugNew is a hidden treasure. Why is it hiding in the Mac OS Support folder?

Richard: DebugNew used to be hidden inside the Libraries sub-folder of Mac OS Support so we moved it up so users could find it easier.

DebugNew is a another memory tool like ZoneRanger but it is designed to be used only in debug versions of your program. If you are writing programs in C++ you can add DebugNew to your project and use it to track memory leaks, memory overwrites that occur when you use new, delete, new[] and delete[].

You can find instructions on how to use it in the manuals on the Reference CD.

Dave: What can you tell me about the ways in which I can customize CodeWarrior with third-party tools?

Richard: Several ways: you can replace a CodeWarrior plugin with a third-party compiler but there are other options as well.

Locate these three folders in the Metrowerks CodeWarrior folder:

(Editor Extensions)
(Scripts)
(ToolServer Tools)

The first one is for BBEdit[TM] Extensions. BBEdit[TM] is a full featured editor that comes with several plugins called extensions to automate editing. You can use these from CodeWarrior by placing the extensions in the shielded folder and turn on the "Use BBEdit[TM] Extensions" option in the IDE Extras preference panel. When you do, an extra menu will appear in the menubar that displays the names of the extensions that are in the folder. The menu shows up as an icon so it's easy to recognize.

The Scripts folder allows you to access AppleScripts and execute them from within the context of the IDE. You can write scripts that drive the project engine or modify the text of your source code. Take a look at some of the example scripts we're already written and placed in that folder. You will need to turn this feature on from the IDE Extras preference panel also.

The last folder contains a text file with instructions for enabling the ToolServer window from within the IDE. ToolServer is part of MPW and is located within the CodeWarrior MPW folder. When properly installed, you can execute MPW tools from a CodeWarrior window. If there's a feature you've been looking for us to implement you'll probably be able to find it in the form of an MPW tool.