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

Greg Galanos and the Mac Developer's Roadmap

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

This month is, perhaps, one of the most important in Apple's history. Although Apple has shown some spark in recent months with the release of some top notch products, the key to their success clearly lies in the timely release of Rhapsody and Rhapsody related tools. With that in mind, this month's interview is with Greg Galanos, Metrowerks' founder, President, and Chief Technology Officer. Greg presents his views of Macintosh development à la CodeWarrior as we make our way into Rhapsody.

Dave: Let's start off with an overview. What changes do you see coming down the pike for CodeWarrior? Will the versions of CodeWarrior retain a unified look on different hosts?

Greg: No matter where you program, you will have essentially the same set of tools to do your work. The host platforms that we are committing to and their order of importance (for our Mac users) are: MacOS, Rhapsody, Windows95, WindowsNT, BeOS, Solaris, SGI and HP. We are striving to create one powerful, integrated development platform regardless of the host.

We're targeting the creation and deployment of a complete development platform that includes project management, project builds, editing, view editing, resource editing and codegen.

The new project manager is ready for prime-time and incorporates many new features including sub-projects, multi-target builds, a new build system, new searching algorithms and the new CodeWarrior look and feel. The CodeWarrior VCS plug-in for plugging alternative source-code control systems is now being supported by CodeManager from Metrowerks, Voodoo from Uni Software Plus, and various shareware and freeware versions of Projector.

We intend to move ahead with a tools driver architecture that will make support of multiple tools plug-ins to be better maintainable from our own internal engineering perspective. We will be deploying a new generation of the CodeWarrior plug-in API that allows us to take into account endian issues between different host platforms (necessary to account for little-endian NT and little-endian Rhapsody), and simplifies the task of porting command-line tools to be CodeWarrior plug-ins.

As far as RAD is concerned, the objective for the RAD part of CodeWarrior will be to support PowerPlant for C++ on MacOS, MFC for C++ on Windows, the OPENSTEP and Rhapsody APIs with Objective-C on Rhapsody, and the conglomerate of APIs for Java (AWT, IFC, JavaBeans, AFC) on all platforms. We will implement fine-grained code-generation to support these technologies.

On Debugging, the debugger will be integrated into CodeWarrior and incorporate a plug-in architecture that allows multi-target and two-machine debugging from within CodeWarrior.

The upside to all this is that all the components of CodeWarrior will be integrated - you will be able to manage your work flow much more efficiently, and transitions between CodeWarrior components will be much smoother from coding, to builds, to debugging, to browsing, to user interface design and back.

Dave: What's the time frame for these changes?

Greg: Our plan is to deploy these technologies within CodeWarrior over the next 3 to 6 releases of the CodeWarrior SDK, starting with the just released CW12.

Dave: You often speak about the "road to Rhapsody" and your desire to provide a road map for developers. Can you clarify that a bit?

Greg: The road to Rhapsody is more like a six-lane highway. This highway has to carry the CodeWarrior Platform and Tools as well as the entire Mac community from where we are now across to Rhapsody. Different technologies need to be implemented in each lane and not all technologies move at the same speed. I see the lanes as:

1. CodeWarrior compilers and linkers.

2. Current NeXT compilers and linkers.

3. CodeWarrior Debugger technology.

4. CodeWarrior Environment.

5. CodeWarrior Latitude.

6. Metrowerks PowerPlant.

Dave: How do you see the evolution of the CodeWarrior compilers and linkers?

Greg: The CodeWarrior compilers and linkers will be modified to allow our customers to use their language of choice, and to use the current system-preferred language, Objective-C.

In order to do this, we're essentially taking a path analogous to the path chosen for SOM. When we implemented support for direct to SOM in the CodeWarrior C++ compiler, you would essentially derive from a SOM object in your standard C++ source code and the compiler front-end would take care of generating the correct runtime bindings so that the SOM object could converse with the system-level SOM runtime. This was called direct to SOM or dtS and it allowed us to bypass using SOM IDL (Interface Definition Language).

We'll be taking the same approach to implement Objective-C runtime support. This means you will derive from an Objective-C object in your C++ or Object Pascal program and the compilers will generate the proper runtime bindings for the Objective-C runtime.

In the above case, Apple will need to provide the C++ and Pascal headers for Rhapsody that contain the entry point in the Objective-C system runtime for this to work, but at this time it is our understanding that either Apple or Metrowerks will find a way to make this happen.

The conclusion here: use your current language of choice and bind to the Rhapsody system APIs.

We also want to provide people with the possibility of adding Objective-C syntax to either their C or their C++ code. This will be done through the use of a front-end language extension switch that will tell the compiler to accept the proper Objective-C syntax construct and generate the proper code for it.

So, that is what we're doing from the compiler standpoint. It's interesting to point out that this work will be used by both the PowerPC and Intel back-ends which will allow us to also implement support for Rhapsody running on Intel as this seems to be a direction that Apple will continue to support.

Changing the compilers is great and fills up half the lane but we need to go further and generate the system executable format. On Rhapsody, the underpinning is the Mach operating system version 2.5 or higher, so we need to implement support for native linking of this format. In order to do this, we need to support Mach-o, the native executable format on Rhapsody. This is well defined on Intel where the Mach kernel is already operational (under OPENSTEP). By the time you read this, it will also have been well defined on PowerPC as we work closely with Apple to make this happen.

Oh, I forgot to mention the symbolic debugging format... It looks like we are going to standardize on DWARF (Debug With Arbitrary Records Format). DWARF is an industry accepted standard debugging format used extensively on SVR4, BSD4.3 and embedded operating systems. It is a processor and platform independent data format, rich enough to define all symbolic necessary for full source-level debugging. It is also language independent.

Now, let's complicate matters some. What about OPENSTEP running on NT? Well, it uses the standard Microsoft COFF format executable, and this is essentially fixed up at runtime by the OPENSTEP Objective-C runtime loader so that the executable can run and connect into the OPENSTEP runtime. Don't ask me how they do it, those NeXT guys made magic. However, given that our Windows95/NT compilers/linkers support Microsoft COFF, then the NeXT magic should work with our NT compilers too, which means that with the CodeWarrior toolset, you should be able to build binaries not only for Rhapsody on PowerPC and Intel running on top of the Mach kernel, but also for OPENSTEP running on top of NT. I'm not even going to start talking about OPENSTEP on Solaris because it's starting to make my head spin like Meryl Streep's in Death Becomes Her.

Dave: How do the current NeXT compilers and linkers fit into all this?

Greg: OPENSTEP's current tools architecture leverages the important work done by the Free Software Foundation in their support of the GNU compiler and linker tool set. The GNU compilers and linkers are well known for the quality of their generated code albeit in the form of compilers and linkers that are definitely not on par with CodeWarrior compilers from a strict ‘time to market' (read high speed) standpoint. Nevertheless, these compilers, which form the basis of the Objective-C compiler technology used on OPENSTEP, are used today by most if not all OPENSTEP developers. They build the code that runs on the platform today. We at Metrowerks run into the GNU compiler architecture all over the place. For example, whenever first silicon for a new processor is brought up, someone usually retargets a GNU compiler to support the chip. This allows early users to quickly approach the new silicon.

Because they are being used for the current incarnation of Rhapsody and also for silicon bring up, it is in Metrowerks' best interests to make sure that these compilers and linkers can work properly within the CodeWarrior Platform. For these reasons, we've decided to fund the development of GNU compiler and linker plug-ins to the CodeWarrior IDE. Once the plug-ins are developed, the plug-in code, based on the CodeWarrior Plug-in Tools API, will be given back to the Free Software Foundation so that anyone using the GNU technology can build a GNU compiler or linker as a CodeWarrior plug-in.

This meets three objectives; First, it allows current CodeWarrior customers to use the current Rhapsody compilers and Rhapsody linker to support seed versions of Rhapsody or current versions of OPENSTEP from within the CodeWarrior environment;

Second, as we move the CodeWarrior Platform to Rhapsody, it will allow OPENSTEP developers to use the CodeWarrior Development Environment as the back-end build system to Interface Builder as an optional build system to NeXT's (er, I mean Apple's) Project Builder on OPENSTEP. This allows the merging of two state of the art technologies - CodeWarrior for builds, Interface Builder for RAD - to interoperate seamlessly (or that's the plan).

Finally, it allows us to transition GNU technology users to CodeWarrior in the embedded systems market as chip volume for new silicon increases and customers start looking for high-volume, low-cost, off-the-shelf development tools in order to support a new or existing ISV developer base on a new device.

By the time you read this we may have figured out what we're going to do regarding debugging for GNU, but our game plan right now is to figure out how to use our own source-level debugging technology with the GNU compiler technology.

Finally, with respect to current OPENSTEP tools, one thing missing is to build the OPENSTEP/Rhapsody linker as a CodeWarrior plug-in. We're working closely with Apple to achieve this goal. By the time you read this, I assume we'll also have figured out how to get the Apple technology such as the Linker to you efficiently.

Dave: What are your plans for Java?

Greg: Java clearly is here to stay and Metrowerks is investing aggressively in the areas of Java technology that require world-class tools: JITs, Java compiler, RAD, and VMs.

Metrowerks JIT technology is based on a retargetable compiler technology that allows us to retarget the JIT for different processors. Currently, Metrowerks has JITs available for PowerPC and 68K MacOS. The fact that these JITs are developed and tested on mklinux also means that they are quite platform independent and can be used both for Rhapsody and for embedded 68K and PowerPC targets with some modifications. Our first objective with respect to JITs was to create a robust implementation and we have done so.

Our follow-up objective is to provide better optimizations as we are doing this. Every iteration of a CodeWarrior JIT has seen increased performance. We are weighing optimizations versus real-time performance as optimizations are clearly a two-edged sword when you're JITing code. The more optimizations you put into the JIT, the slower it JITs the applet. It's very important to balance optimizations with runtime performance and we're making sure we don't optimize our JIT to the point where it takes longer to translate the code than it does to interpret the code.

Additionally, we are building JITs for embedded targets. One of the first is for NEC Electronics V-800 series processor, a RISC processor with approximately 20 times the performance of the 68k series from Motorola, but at around the same price point. The V800 processor is the building block for NEC's systems-level offering for digital television (satellite receivers, Internet-ready television, digital audio/video sub-systems).

We're also working closely with Sun Microsystems, Apple and Microsoft to implement and support the JIT APIs from these companies, so that JITs can be interoperated with different VMs.

Dave: How about a native Java compiler?

Greg: Java is a real interesting beast in that even though it is platform and processor neutral, different technologies need to be implemented in order for it to be efficient in both execution and memory footprint. It challenges the developer of tools in that a wide variety of options are necessary depending on the runtime characteristics of the target. For instance, if the target is a desktop machine with loads of RAM, either JIT or native binary compilation is an option. However, both of the above solutions increase memory usage dramatically (an order of magnitude) for the final executable, compared to just interpreting the code with the VM interpreter.

We're making sure our customers have all the options available in CodeWarrior. One of the things we'll be doing this year is developing our own fully integrated Java compiler. This compiler, comprised of a front-end and a back-end, will be fully merged into the CodeWarrior compiler technology base. The front-end will generate code to the CodeWarrior IR (intermediate memory resident representation). The Java back-end will generate the bytecodes. The advantage of generating for the IR is two-fold. First, it allows us to leverage the optimizers used by current compilers (C/C++ and Pascal) on the IR. This in turn allows the Java back-end to generate a ‘better' byte-code sequence. Look at this as generating better Java byte-codes, whether they are JITed or run on the VM, their optimized generation will make them run more efficiently (at least that's the objective).

Of course, the fact that the compiler will be written in ANSI C, as all of the CodeWarrior compilers are today, will also give customers a screaming implementation of the Java compiler as fast if not faster, given that it's a simpler language, than our C/C++ compiler.

Secondly, given that we are generating the CodeWarrior IR, we will also be able to use Metrowerks back-end technology for specific processors (PowerPC,68K,x86,MIPS,V800) to generate a pure native binary, one that will not require JITing and will run on the target processor. The caveat here is that we still need to figure out how to provide system services provided by the VM (such as garbage collection, etc.) to the native binary. We're working out the details of this with Apple and Microsoft for the two desktop platforms we support. For the time being, we'll be calling the VM for the service where necessary, until a standard "VM-native services" library is implemented by Apple and Microsoft.

We're also continuing to invest in the Sun Java compiler as the currently shipping compiler for CodeWarrior. Currently, the compiler has already been J2Ced. This essentially takes the current compiler, translates it to a C representation, then the CodeWarrior C compiler compiles it. It gives us a "native" compiler that generates byte-code, but that is still a cousin of the original Sun compiler. Of course, we've also gone to great lengths to architect the Sun compiler so that it looks and acts like a normal CodeWarrior plug-in. We'll be implementing an IR-generating pass in the Sun compiler that will allow us to generate the CodeWarrior IT directly, in order to start solving the runtime issues that arise from native code generation while we build the full CodeWarrior Java compiler.

So, in conclusion on Java compiler technology (JIT and Static compilation), we are implementing dynamic compilation (JIT), better more optimized compilation (Java compiler), static compilation (Java front-end to processor-target back-ends) and enhanced static compilation (other language front-ends to PicoJava processor target). Interesting, important stuff - the baseline for our tools infrastructure for Java, critical in the years to come as Java moves from early adoption to widespread use.

Dave: What about Java VM support?

Greg: We got into the VM business early in 1995 when it was clear that we needed a VM, and we needed it for our customers earlier than Apple was going to provide a VM. The Metrowerks VM, a derivative of the Sun VM, developed under license, is used today in Internet Explorer on MacOS and we've just relaxed our licensing restrictions in our CodeWarrior software license so that any of our customers can ship the VM bundled with their Java applications. We developed two optimized byte-code interpreters, one for PPC the other for 68K. The interpreters essentially accelerate about 150 byte-codes, and translate into a VM that is about 60% faster than a standard VM without JITs. We've just licensed this technology to Apple Computer for incorporation into Apple's VM. We'll also be shipping Apple's VM as an option to the Metrowerks VM as part of any CodeWarrior Java toolkit (Gold, Academic, Discover Java).

As soon as Apple and Microsoft agree on support for COM in Apple VMs, we will move to transition our customers to one VM on MacOS, provided to all customers by Apple as a baseline system service. Clearly, our goal is to exit the VM business as this is really a system vendor area where we do not provide clear, added value long-term. On Windows95 and WindowsNT, we will essentially ship the Microsoft VM and x86 JIT. I'm assuming that there will be a standardization effort on MacOS and Rhapsody that will allow us to do the same thing on Apple platforms.

We'll be happy to work with Apple on providing the JIT technology as we have provided the OBCI technology and are working towards this goal with Apple and Microsoft.

Dave: And Java RAD?

Greg: Clearly, our first efforts to support Java from within Constructor have been quite successful, but we believe we definitely need to go much further in the support of visual development in Java. As such, as part of our RAD implementation in CodeWarrior, we will be implementing complete support for Java visual development from within CodeWarrior, support for the development of the user interface in a visual fashion, with fine-grained code-generation, object wiring, and ‘instant run' to provide immediate feedback to the developer of a Java application. Coupling this with a world-class development environment and build system that supports multiple languages will provide a world-class, very powerful solution regardless of platform. The RAD for Java support features will be rolled out in CodeWarrior in a stepwise fashion as part of each CodeWarrior SDK release as other technologies for C/C++ and Pascal have been rolled out over the last 12 releases. (12 releases in 4 years, I must be getting old.)

Dave: What's the story with CodeWarrior's debugging technology?

Greg: As I said, we are working on a merger of the IDE and the host debugger technology to make the development experience continuous. The current CodeWarrior debugger will be integrated into the development environment, so you will be able to edit, compile, and debug all within the same environment. This means all the functionality of the IDE will be available when you are debugging, and vice versa. For example, you will be able to set breakpoints in your code while you are editing, and you will be able to click on a symbol in the source you are debugging and make use of the pop-up that appears (jump to a symbol's definition, for example).

We are also adding support for two machine debugging in CodeWarrior 12. The CW 12 MetroNub now supports both single machine debugging and two machine debugging via TCP/IP. Now, you can debug your Mac applications with the debugger running on the same machine, on a second Mac, or from your Windows box. You can also use the same debugger to debug 68K, PowerPC, x86 and Java, all simultaneously.

Supporting Rhapsody debugging is an interesting beast because essentially we're talking about a multi-tasking, preemptive, memory-protected kernel and (you guessed it!) a new range of services to support on that kernel.

Trivia-start - we did do some of this work for Copland (you remember that thing, dimly in the past, like last May). Actually, all humor aside, some of you may recall that Metrowerks shipped the DR1 of a CodeWarrior debugger that actually debugged code running on Copland, back in May 1996. That piece of code was probably the only piece of commercial software ever shipped for Copland - Trivia-end.

Rhapsody uses the Mach kernel, which is well implemented as originally defined by Carnegie-Mellon. We are taking a different approach to debugging on this new operating system, actually peering into Apple's past and bringing some very interesting technology to bear on the problem. From where you might ask? Well, from the work done on Hoops by Taligent.

A very neat debug server architecture was developed back then to run on top of AIX and to provide debug services to the Hoops environment. As part of our relationship and development agreements with Apple, we have licensed that technology and are porting it to Mach. This debug server will allow both full, one machine debugging as well as two-machine debugging. Then we need to change the host debugger to support two machine debugging, but a lot of this original work was already done to support target debugging (MacOS hosted CW to NT, MacOS-hosted CW to PlayStation).

So hopefully, you'll see a very clean, modern architecture for Rhapsody debugging that will work for pretty well any platform on which Rhapsody runs. Of course, MetroNub will continue to support MacOS multi-language debugging and the Hoops nub will do so for the new OS. CodeWarrior's host debuggers, whether hosted on MacOS, Rhapsody, Win95 or WinNT or a unix platform will also be able to talk to this new debug server via TCP/IP.

Dave: How will Latitude and Equal fit into the picture?

Greg: Metrowerks recently acquired the assets of the Latitude Group which was essentially two products: Latitude, a well-architected porting library and Equal, a 68K emulator, linked with the Latitude library. We may use the 68K emulator in our embedded products at some later date, but right now, our immediate focus is on Latitude.

The really interesting thing about Latitude is that it was architected from the ground up to support the emulator. As such, it has a distinct design and has proven very robust in porting applications to unix systems, specifically Solaris, SGI and HP. In particular, Adobe used Latitude to port and run Premiere on SGI and Photoshop on Solaris. So we're talking about some very robust technology that is in current commercial use with two very demanding applications. Currently, The Latitude Cross-Platform Development Kit runs on the following unix RISC workstations:

• Sun Microsystems SPARC, or compatible, running Solaris 2.3 or higher.

• Silicon Graphics Indigo or Indy workstations, running IRIX 5.2 or higher.

• Hewlett Packard Series 700 workstations, running HPUX 9.03 or higher.

Latitude is a portable implementation of Macintosh System 7 application programming interfaces (APIs), as documented in Apple's Inside Macintosh. The Latitude Technology forms the core of the Latitude Cross-Platform Development Kit. The Kit is a virtual porting system that allows source code for a Macintosh application to be compiled with little or no modification on a unix platform, resulting in a native unix application.

All applications created with Latitude adopt the look and feel of the destination platform's GUI. The target GUI (such as OPEN LOOK or Motif) provides menus, dialog boxes, icons, scroll bars, and the like, but the application's content region retains the look and feel of the original Macintosh program. Special Latitude provided functions allow developers to tailor the content regions so that they too can have the target GUI look and feel. Latitude uses industry-standard interfaces including ANSI C, PostScript, and POSIX.

The Latitude technology performs the functions of the Macintosh API through a shareable set of program libraries. Developed for accuracy and portability, these libraries accurately reflect the behavior of most of the Macintosh System 7 toolbox. Well-behaved Macintosh applications built with Latitude run with little to no unix porting or customization.

Written in ANSI C for POSIX-compliant platforms that support X11, the Latitude technology is more that 95% independent of the specific unix implementation, X11 libraries, and GUI under consideration.

Dave: How about the Latitude bridge to Rhapsody?

Greg: As a result of the unique architecture of the Latitude library, support of a new target like Rhapsody requires the retargeting of around 100 Latitude calls, about 50 user interface calls and about 50 imaging calls. The reason why we can move 2000 or so Mac calls to a new target so quickly is that the 2000 calls all first target the Latitude portability layer which abstracts out a lot of the target support and only requires a subset of calls to be implemented for a new target.

Given this, we believe that Latitude can provide a very strong portability solution for getting Mac apps up on Rhapsody (or other supported unix platforms) quickly, providing the Mac developer with the opportunity to execute a quick port to Rhapsody of their current application, call it a point release, and then to subsequently add in native service support for the target operating system.

A Macintosh application that binds to Latitude will acquire the look and feel of a Rhapsody application as well as protected-memory. Additional features, such as multi-tasking, can then be added through direct mixing of calls, some handled by the Latitude library, others directly by the native Rhapsody APIs.

As usual, it's only when we finish the implementation of the Rhapsody target and use it ourselves that we'll know if it's a hit or not. We think it will be, given our discussions with Adobe and Apple engineering. So, the first thing we'll do is eat our own dog food: port CodeWarrior using Latitude. Hopefully, by the time you read this we'll have something to show you.

We're hopeful we can ship the CodeWarrior Latitude SDK later this year, around the same time we ship the early releases of our Rhapsody tools.

Dave: How efficient will this approach be?

Greg: The best way to answer that is to look at apps that use a porting library. First, we use the Mac2Win library from Altura software to port CodeWarrior to Windows 95 and Windows NT. Given that the underlying file systems are native, and that the window, menu and dialog DLLs on Windows 95 and Windows NT are pretty efficient, we see no material slowdown in the Windows-hosted version of CodeWarrior. Given that the current Mac file system is emulated on Power Macintosh, we actually see a faster response time on CodeWarrior for Windows and no apparent performance difference between CodeWarrior using the Mac2Win library and native Windows apps.

As far as the Adobe products are concerned, they run much faster on SGI and Solaris workstations, the result both on the underlying unix kernels and the power of the workstations. So, we see no immediate need for concern here. Additionally, given that you can mix Latitude and native calls, if you experience a slowdown in a time-critical routine, you can just call the native API for that specific routine. So, instead of rewriting it all, you fine tune the parts that need fine tuning once you're up and running on Rhapsody.

Of course, we view Latitude as a transitional technology. It should be used for bring up on Rhapsody, and will not necessarily track all new Rhapsody APIs as they become available from Apple. It will certainly be worthwhile for a developer to implement the second generation products for Rhapsody directly to the native APIs or to write directly to Rhapsody for a new product.

Dave: How will Latitude be packaged?

Greg: The Latitude SDK, which will include all the sources to the Latitude library as well as all the supported targets (Rhapsody, Solaris, SGI, HP) in source will carry a retail price of $399. It will follow the CodeWarrior subscription model and be updated three times a year. Current CodeWarrior Academic discounts will also apply.

The new Rhapsody tools (CodeWarrior IDE and all the tools) will be rolled directly into the CodeWarrior Gold and Academic SDKs, so that all current subscribers will get the tools when they are available at no additional cost.

So, the Mac developer, armed with CodeWarrior Gold or Academic and CodeWarrior Latitude, with a little sweat equity (i.e. about thirty ‘burning the midnight oil' nights) can move to Rhapsody fast, and we mean fast, without completely rewriting their application.

CodeWarrior Rhapsody will use the Latitude technology to leap to the new platform and be rolled into the CodeWarrior SDK. Once CodeWarrior is up and running on the platform, we'll continue adding new features in the product that take advantage of the native APIs. We're also taking a real hard look at InterfaceBuilder to see what we need in the environment to offer comparable features. Of course, developers will also be able to use InterfaceBuilder, because we aim to interoperate with ProjectBuilder and InterfaceBuilder on Rhapsody.

Dave: Have you firmed up plans for your sixth lane, PowerPlant?

Greg: What to do with PowerPlant is a very interesting question. Should we write a new version for Rhapsody? What should it be written in? Should we write it in Java? What about the MacOS version? A lot of questions, many unknowns. Here's what we've decided to do, given the dual operating system strategy at Apple and the current state of Java APIs.

One, we will continue to enhance PowerPlant for MacOS for the duration. Two, the transition of PowerPlant-based apps to Rhapsody will be achieved by linking with the Latitude library. We will achieve proof of concept of this by porting CodeWarrior, which is all PowerPlant code, using Latitude ourselves. Three, where Apple provides cross-platform APIs between MacOS and Rhapsody, support for these APIs will be rolled into PowerPlant where it is feasible and necessary.

Rhapsody already contains a very rich set of frameworks for desktop and Internet development. As such, it is not currently planned to build a new version of PowerPlant for Rhapsody, but rather to support Apple in its deployment of the Rhapsody APIs.

As far as doing a version of PowerPlant for Java, right now, we're talking about a pretty crowded field from AWT (JavaSoft), IFC (Netscape), AFC (Microsoft), JavaBeans (JavaSoft), and most likely a Rhapsody derivative from Apple. A conglomerate of Java APIs. Even if we did write a version of PowerPlant in Java, would it take hold? Would it be accepted as an industry standard as most of the systems vendors vie for leadership in the Java API space? The answer right now is no, so we're going to concentrate on the tools infrastructure for Java, but will not field a Java framework directly. We will, however, implement necessary Java class technology in order to support our Java RAD tools development. It's still too early to tell if it makes sense to make these Java classes available as a "framework". We'll have to wait and see.

Dave: Tell me about CW12. What's new in this release?

Greg: We'll have a final release of the 2.0 IDE (new project manager, multithreaded, multi-target, etc.) along with a pre-release of the 2.1 IDE which contains the integrated debugger (allowing users to set breakpoints directly from their source files).

We'll have a final release of the PPC JIT (Just In Time compiler), which gives greatly improved performance over previous versions, a beta release of the 68K JIT, a final release of the native Java compiler (i.e., not an interpreted Java compiler), and a release of the completely integrated VM containing the OBCI (Optimized Byte Code Interpreter) and JIT in a single binary. This is the same VM with which Microsoft's Internet Explorer ships, and will be our new redistributable VM version.

We'll ship a single Debugger application for C/C++/Java/Pascal targeting MacOS (68K and PPC) and x86 cross debugging.

ANSI C++ support will be enhanced (explicit, mutable and improved default template arguments). We'll ship a prerelease of our Objective-C compilers and linkers for PPC and x86, allowing users to start developing for OPENSTEP and Rhapsody today from MacOS. We'll ship a prerelease of IR optimizing 68K compiler, with greatly improved codegen (10-15% better ByteMark scores) as well as a prerelease of improved MSL C++ libraries, which along with the new prerelease ANSI C++ compiler, generates much smaller executables and improves compile speed.

Dave: In the same vein, what's on tap for CW13?

Greg: We'll ship the release version of the 2.1 IDE, which contains the integrated debugger, new text engine, and portable project format (single project file will work on all supported platforms). There will be a prerelease of the 2.2 IDE (with contains a "sneak peak" at our integrated RAD support) and a prerelease of the native Rhapsody IDE, which will run as a full fledged Yellow Box application, allowing users to develop and debug Rhapsody applications from within Rhapsody itself.

We'll see continued Java VM/JIT performance improvements, as well as reducing size overhead. We'll add native Java codegen support allowing use of Java to target PowerPC native executables, giving greatly improved performance without the use of a JIT. We'll also ship a prerelease of a completely native Java compiler written in C++, allowing users to use Java to generate native executables for all Code Generators which are supported by Metrowerks (currently 68K, PPC, x86, and MIPS)

CW13 will see improved Java debugging support and two machine debugging, allowing users to debug between any two machines running MacOS, Rhapsody, and Windows.

We'll add name-spaces support in the ANSI C++ compiler, along with other C++ improvements and a prerelease of Direct to Objective-C support in the ANSI C++ compiler.

Finally, we'll ship both Constructor for Windows (allowing users to generate Windows resource files visually from MacOS) along with a prerelease of Constructor for MFC, which allows users to create their MFC views from within Constructor, and then have Constructor generate all the source needed to instantiate the views.