Nov 99 Factory Floor
Volume Number: 15
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.