Volume Number: 13 (1997)
Issue Number: 11
Column Tag: From The Factory Floor

CodeWarrior Rhapsody Update, Part 2 and a Quick Look at WarriorWorld

by Dave Mark, ©1997 by Metrowerks, Inc., all rights reserved.

Last month's Factory Floor column featured the first half of an interview with the CodeWarrior Rhapsody team. This month, we'll finish off this interview, starting with a look at the yellow box debugging plans. We'll also take a quick look at a cool new web site, known as WarriorWorld...

Berardino E. Baratta is Vice President, Research and Development for Metrowerks Corp. With the Metrowerks R&D department quickly approaching 100, he has little time left for doing actual coding but he does still sneak it in (mostly by working on it late at night, or early in the morning, depending on how you look at it). Most recently having done compiler and linker modifications for PalmPilot Release 3. He also tries to spend as much time as possible with his wife and young son.

Since starting at Metrowerks in early 1996, Lawrence You has been helping shape the CodeWarrior debugging architecture for non-Mac OS targets, including Rhapsody. He has been a longtime Macintosh developer, also working for Apple and Taligent.

David Hempling is the CodeWarrior Latitude Techinical Lead at Metrowerks, where he is bringing the Latitude Technology to Rhapsody as well, opening new doors for Metrowerks existing applications. David co-founded Quorum Software Systems in 1989 where Latitude was born and has nurtured this unique porting technology as The Latitude Group's President from 1994 to 1996.

Dave: Will MetroNub exist in the yellow box? What are the yellow box debugging plans?

Lawrence You: From the point of view of the CodeWarrior developer, the debugging environment will be very similar, if not identical, to the environment hosted on other platforms. We will know that we did our job well if today's CodeWarrior user cranks up their copy of MW Debug on Rhapsody and says "hey, this looks exactly the same as what I'm used to." There is a growing emphasis on cross-platform development, making ease-of-use and consistency very important in debugging environments.

But, why stop at developing and debugging on only one platform at a time? A developer's needs are different than the customer. Why should a developer be required to use a different platform and often different development tools for every target they develop for? If they are comfortable using an environment on Rhapsody (or MacOS or WindowsNT) and want to use it to cross develop all their versions in one place, why should they have to learn how to use a new debugger? Consider just the number of Yellow Box implementations alone that a developer will have to use: to start, there will be native Yellow Box in PowerPC, native Yellow Box on Intel, and the Yellow Box API on Mac OS.

Considering all of the possibilities, our main goal is to evolve our existing debugging environment into one that can be used for many targets at the same time. Just as we've recognized that our CodeWarrior IDE needed to have the ability to create multiple "targets" which can be used to create fat or cross-developed applications, we also recognize that we have to provide a solution that will let a CodeWarrior user debug for those different targets.

You can see evidence of this strategy already. Just to give you an idea of the extent we believe in this, our Macintosh and Windows debuggers already support C/C++ on MacOS/68K, MacOS/PowerPC, Windows 95/NT/Intel, Sony PlayStation/MIPS, Motorola PowerPC EABI (embedded)/MPC821 and MPC860, PalmOS/68K, OS9/PowerPC not to mention Java and Pascal on the desktop platforms. So along those lines, the Rhapsody targeted debugger will "just" be another plugin; to the CodeWarrior user, MW Debug will look just about the same.

But, there are differences which we'll be addressing. Objective C is different than C and C++. Object file and symbolic information formats are different. MetroNub, which is just a low-level Macintosh INIT, will be replaced by a server. Multitasking and threading will be more prevelant; multiprocessor hardware will be less forgiving of errors in concurrent programs. These are just a few examples.

The Objective-C runtime will require we change the debugger to allow the user to inspect objects and polymorphic functions. Also, the exception handling mechanism is different from C++ but the user will still have the ability to catch exceptions with the debugger. We should also be able to maintain our feature of being able to debug across virtual machine boundaries, like you see with programs which use mixed 68000, PowerPC or JavaVM code.

The linker will generate Mach-O output for PowerPC and Intel, which is different from PEF and XCOFF files. Source-level debugging information will go into a separate debugging "section" of the file, although we may also give the user an option to split the symbolic info into a separate file, kind of like ".SYM"/".xSYM". We have been using DWARF for our MIPS and PowerPC embedded compilers and debuggers and have found it to be a more neutral and expressive debugging information format, not to mention that it is a standard. So we'll be using that instead of the Apple SYM format. To ensure a high level of interoperability, we're also working with Apple to help ensure that files created and used by gnu tools (gcc and gdb) can be used in a mix-and-match fashion.

MetroNub is fine for MacOS debugging, but since Mach differs so dramatically from MacOS, we're moving towards a debugging client/server architecture that can be used on not just Rhapsody, but also for other future systems. Some notable differences are that there is the notion of a single user using a host on MacOS. The Mach tasking model allows multiple users, and the new server will allow for that. The new debugger server can be used locally and remotely with little difference except for responsiveness, opening up possibilities for WAN-based graphical debugging.

Driver developers should find remote debugging with a microkernel useful. It's not clear to me yet what low-level code you won't be able to debug locally (or in some cases remotely), but it seems likely many drivers that were impossible to debug on a Mac with CodeWarrior should look similar to applications on Mach. At the very least, we'll make a strong effort to not preclude driver debugging.

Like other modern operating systems, Mach will allow multithreaded programs to run truly concurrently on mulitprocessor machines. This opens up some new opportunities and exposes errors. Many developers have seen "Heisenbug" effects (even without MP machines), whereby a debugger becomes intrusive, ever so-slightly, changing the events in a program. This is an effect that, in some cases, is impossible to avoid. Most debuggers on multithreaded systems, including gdb, allow the user to examine threads and set breakpoints, but we'll work hard to make sure the user has the most flexibility to debug concurrent programs on MP hardware.

Dave: How does PowerPlant play in all this?

Berardino Baratta: We have a large investment in PowerPlant and don't plan on throwing this away, but we are not planning on porting PowerPlant to Rhapsody as a native framework. These are many reasons for this but the simplest one is that PowerPlant was designed from the ground up to be a Mac OS framework, and as such would require a complete rewrite in order to be efficient under Rhapsody, meaning that users couldn't take advantage of their investment in PowerPlant without rewriting their code. We feel that if users are going to be rewriting their code, then they should target the Yellow Box API directly and take advantage of that API's object oriented design from the start.

We are still planning on providing our users with a path to Yellow Box through the use of our Latitude porting library. We ourselves are relying on this path in order to port our IDE native to Rhapsody. The combination of Latitude and PowerPlant allows users to maintain their current design and yet bypass both PowerPlant and Latitude in order to directly access the Yellow Box APIs in order to implement native functionality, thereby taking advantage of features that are only present in the Yellow Box.

Dave: What's the timeline for all this?

Berardino Baratta: As I write this, we've just recieved a version of Rhapsody on PowerPC, and don't know yet how stable this version is. That is one of the largest variables in our being able to deliver the above mentioned tools in our CodeWarrior Professional Release 2 delivery which is supposed to ship on October 15th. We have full support from Apple engineers so we feel that if it can be done, we will work together to make sure that it is done.

We are not putting all our eggs into the Rhapsody native basket though, in that we are planning on implementing cross development support from MacOS as a first step in our plan. We don't see any road blocks in that plan, so at the very least users will have access to these cross compilers, linker and debugger in Pro2 and we'll then invite users to participate in our beta testing program in order to access our native toolset. This is only Plan B, as I speak, we're still on track for Plan A.

The Pro 2 release of Rhapsody tools, will be of prerelease quality, but we'll patch them over time, in order to ship final releases of the tools, around the same time that Apple goes final on their first public release of Rhapsody. Very similar to our strategy in 1994, during the transition from 68K to PowerPC architecture for MacOS. During the interim, we plan to allow our users to work native on Rhapsody from Day One of their receipt of the first Developer release of the new Operating System.

Dave: By the time this issue hits the streets, developers will have had a chance to play with both the first developer's release of Rhapsody as well as a new version of Latitude for that release. What kinds of things will people be able to do with this new version of Latitude?

Dave Hempling: Our development of Latitude for Rhapsody has gone extremely well. We prepared for Rhapsody by doing initial development on the OpenStep 4.2 release on Intel while we awaited Apple's PowerPC Rhapsody Developer Release. All of Latitude's File and Resource Manager functionality was made endian neutral at that time so that we could open, read, and write Mac Resource Forks in OpenStep. Once the basic Graphical User Interface components were coded and in place, we were able to begin interpreting WIND, DITL, MENU, CNTL, and other resources and put up dialog boxes.

With working windows in place, we had canvases to accept drawing operations. All of our basic Quickdraw drawing, including Region support and some complex CopyBits operations like hilighting and patterned brush drawing have been mapped to DPS operations. Since color dithering is a feature of DPS, we didn't have to manually do it ourselves -- which was a welcome change from Latitude's X version.

All of these features have made their way smoothly to Apple's PowerPC Rhapsody Developer Release. We're successfully mapping windows, controls, menus, and graphical and textual rendering to Rhapsody's GUI and DPS. Some of the Latitude implementations may not be as efficient as we'd like but I know we'll have these cleaned up once Apple releases the Premiere Rhapsody release slated for January.

Developers experimenting the Latitude now should be able to access their resources, put up their windows and dialogs, and see a majority of their application's features working well. Features developers will see missing are those that hadn't made it into the Apple Rhapsody Developer release such as Blue/Yellow Box file sharing and AppleEvents.

One void I know developers will see now is a means to get Mac files into their Rhapsody environments. Simply ftp-ing won't do since apps depend on the Mac File Manager to report various Finder attributes, like file types and owners, and this information is lost by simple ftp. Latitude's File Manager will report all this info if it is included with the files in one of several popular formats that encode Finder information into the file, including AppleDouble, AppleSingle, EtherShare, K-AShare, and uShare. As it happens, Jeff Matthews' Fetch 3.0.1 can write AppleSingle files. Until Helios brings EtherShare to Rhapsody, as they've promised, Fetch 3.0.1 is the only way I know at this time to safely transfer Mac files directly to Rhapsody so that they are fully understood by apps ported with Latitude.

This birth of Rhapsody is much like other new UNIX operating system releases that I've witnessed over the years. Not so much cutting edge but rather bleeding edge development. While the Apple engineers rework and fine tune their new operating system, developers like us are attempting to bring out the best tools possible under constantly shifting conditions. Latitude has been through this kind of development before when operating systems like IRIX 4.0 and Solaris 1 were in early releases. As the Rhapsody releases become more stable, so will Latitude's support.

If you've spent any amount of time teaching yourself PowerPlant, chances are you've heard of the PowerPlant Dream Team, a group of folks dedicated to learning about PowerPlant and interacting and collaborating with each other online.

The founders of the PowerPlant Dream Team created a non-profit organization called WarriorWorld, the official CodeWarrior users' group. Now, WarriorWorld has a new home on the web at http://www.codewarrior.org/.

WarriorWorld is ramping up now and, by the time you read this, the site should be complete, offering a range of technical info and services. According to the WarriorWorld FAQ, the site will soon offer a series of free courses in Java, C++, and PowerPlant. Each course will organize a corresponding Dream Team to make the learning process more effective.

To me, this site has huge potential. Check it out...