• Apple developer site
• MacOS X

TNC: Hello Ken, welcome to the program.

KB: Hello, Philippe.

KB: Yes, in the Worldwide Product Marketing Group here.

I've been at Apple about eight and a half, nine years, in a variety of roles in various technology groups. For the Worldwide Product Marketing Organization I'm responsible for our OS technologies, primarily Mac OS X, Carbon and our Rhapsody engineering or development unit.

KB: Certainly. And before joining Apple, I actually spent five years as a senior Mac programmer, doing a bunch of development in the toolbox, so seeing the whole Carbon strategy come together really completes a cycle for me in many respects.

KB: Well, we certainly announced a couple of things at a very high level. We shared the fact that there are three priorities for Apple from a software perspective. Mac OS was clearly the most important thing to Apple from a software perspective. It's our crown jewel and it's the center of all things that we do.

Java is also exceptionally important, and we understand the huge interest expressed by our customers, by the developer community, and we're doing a number of great things with Java, as well.

And certainly third on the list is QuickTime and our very strong leadership position in terms of multimedia architectures and technologies, both from an authoring and playback perspective.

KB: Well, overall, obviously, we see more efforts being delivered towards content. It's not necessarily just about applications anymore. Obviously, this conversation of ours is a great example of multimedia being communicated and distributed in ways that were not possible a couple years ago. And we believe that a number of the foundation technologies and quick time have enabled us and can push greater media integration into all kinds of different uses.

KB: Exactly. What we told the developer community is that their investment in the Mac OS and Mac OS applications over the last 15 years or so is exceptionally valuable to Apple, that people love the tool box, they have evolved as the tool box has evolved. They've enhanced it in ways that are important to everybody. And Mac OS X, by implementing a very significant subset of the toolbox, validates that investment and moves it forward for another decade of growth.

KB: Absolutely. What we did was, we analyzed all the tool box API's in the system over the 14 or 15 years that the tool box has been enhanced. It's grown to about 8,000 different entry points. We looked at application usage of the toolbox and we found that there are a number of services that are no longer in use.

We also took a look at some of the technical challenges in moving some of the older tool box API's into a more modern operating environment, and it was clear that some APIs by their very design would prevent us from being successful in our goals of having Mac applications run pre-emptively scheduled in protected address spaces.

We made some difficult decisions and we're evaluating still a number of API's. But we found that about three quarters of the 8,000 we felt that we could move forward as part of Mac OS X.

KB: There's actually two issues in here. The first is that the Carbon APIs themselves, the subset that is moving forward, will be implemented natively on top of the new mach-based core Mac OS X. No emulation. The APIs moving forward on top of a modern underpinning.

At the same time, Mac OS X as an operating system will run existing unmodified, potentially non-carbon compliant applications. We have a technology that is evolving from the Rhapsody project called the blue box, which actually has the full implementation of the existing Mac OS API's contained in its own address space.

KB: Correct.

KB: We're actually looking at the whole issue around binaries. Certainly the native runtime format for Mac OS X is based on the Mach-0 format. But we intend to have good support for the Mac OS primary run time of today known as CFM, the Code Fragment Manager.

KB: There are the two extremes of APIs that are fully supported or not supported at all, and that's probably the majority of all the API's in the system. And then there's a couple grades below supported.

There are some APIs that will be in fact supported, but that we would prefer developers not use. We understand that in some cases they're necessary, but these are API's that we will plan on removing support in subsequent releases down the road. But from a transition perspective, they have to be there.

There are another collection of APIs that are primarily the same as they are in Mac OS today, but we will need to change maybe a parameter or maybe a usage behavior, and we're listing those as supported but modified.

KB: Well, I think we'll be careful. And if we change parameters, they'll probably be changed in such a way that they just won't compile clean. I need to get one of the engineers involved in that, but we certainly are aware of the potential.

KB: That may be the approach that we take.

KB: Well, we actually expect that most applications will need a little bit of work in order to become Carbon-compliant. But the changes are small and modest and we expect that it will just take developers on average five or ten days to get the basic changes in place for their source.

KB: The changes are exceptionally well documented and as we all know everybody's always working on the next version of their products to add new features. So we think that Carbon support or Carbon compliance is really just like a minor feature that a developer would add as part of the standard development process.

KB: Our primary tool, above and beyond our documentation and our carbon specification, is what we're referring to as the Carbon Dating Tool. It's actually a very exceptional tool, in that it satisfies a number of goals. It allows the developer to see how their application fits in terms of carbon compliance. But we do so in a Web and e-mail based architecture, such that as the carbon implementation and specification is taking final form, we can update the information and developers can just retest their application again through the Internet and get the latest information on an ongoing basis.

This is how it works: Go to our developer area Web sites on the Apple developer connection at www.developer.com. You'll notice there's a large button on our home page called Developer. And then there's a Mac OS X section in there, and you'll see the link to the Carbon dating tool. And you download a very small application to your local development system and, just as simple as a drag and drop. You take your application binary, drop it on top of the carbon dating tool, and what it does is it performs an analysis of all of the toolbox in ports required by that application. And we produce a text file as a result of that process, which just iterates and lists all of the tool box dependencies for a given power PC binary.

That text file is e-mailed to a special e-mail address, carbondating@apple.com. And we've got an application at the other end that takes that enclosure, performs a very detailed analysis against the latest and greatest Carbon specification that we have internally here at Apple, and generates a really complete and visually easy to read, graphically oriented report with lots of hypertext references. The report shows all of the API's that will have to change and all the API's that are supported. We also insert in developer recommendations and work rounds for areas that need to be changed.

So within anywhere from five to 20 minutes this full process completes. It's been accepted by the developer community incredibly well.

KB: The response has been great. In the first 24 hours when the tool went up about a month ago, we were getting an application submitted about every three and a half minutes. After about a month we've had over 2,500 applications that have been submitted for Carbon dating.

KB: Well, certainly we are eager to get feedback from the developer community. And these reports certainly help us a great deal.

What we've seen so far that surprised us a little bit in that the average compliance to Carbon is even a little bit higher than we thought we would find. When we did or own internal studies, we used some very large, complex applications and we expect the Carbon compliance of an average application to be around 90 percent.

The running total on all the submissions so far is around 92 or 93 percent.

KB: Certainly. Rhapsody represents a number of technologies. And, in fact, most of these technologies play a very important role within Mac OS X, at least the evolution of those technologies.

Mac OS X and Rhapsody share a common heritage in terms of the micro-kernel architecture and the basic framework for our file system, approach to file system and now working. Those are all very, very shared in common.

KB: Well, Rhapsody is based on BSD 4.4. So down in the kernel level there are the POSIX-like APIs that UNIX and most modern operating system environments present.

We also include in Rhapsody the full "user environment for BSD." So we have a built-in terminal command line environment with a standard UNIX commands and man pages.

KB: On top of BSD, Rhapsody presents a very advanced object-oriented development environment with tight integration with Java, the technology that we refer to as the yellow box development tools.

KB: No, these are not C++ interfaces --

KB: -- based on, initially based on the Objective C runtime, but it has very tight integration with Java. In fact, as a Java programmer, you can access all of the frameworks and all of the bindings of the yellow box as if they were made of Java methods.

KB: Well, on the core operating system front we're evolving the core technologies. Rhapsody is based on mach 2.5, and we're taking a look at mach 3.0 as the potential kernel for Mac OS X. We'll be evolving the file systems that will have support in the same basic VFS oriented file system but will embrace the new Apple extended volume format that Mac OS 8.1 introduced, and that will be our primary volume format. It will still have all the important characteristics of the Rhapsody core file system architecture.

So those technologies are certainly evolving. There's a variety of network administration and management technologies that will play an important role within Mac OS X.

KB: Under Rhapsody they're more UNIX like in terms of their API implementation. You'll notice, if you use a Rhapsody system, that all of the administration tools are very rich, graphically oriented applications that allow you to manage the system very, very effectively without ever having to drop down into a UNIX command line.

Mac OS X is an operating system that's designed for millions and millions of Mac customers, existing ones and new ones. So our focus is absolutely to make sure that this is not perceived to be a UNIX system. In fact, it's a system that can be managed by an average user of technology that doesn't consider himself or herself a technologist.

KB: That type of functionality. Now, one of the exciting capabilities that Rhapsody delivered, inherited from the Next Step operating system, is the notion of a virtual desktop across a network infrastructure. I have Rhapsody on my main system here at Apple, and I can basically walk up to any Macintosh running Rhapsody and sign into the system as Ken Bereskin, and all of my desktop preferences, all of my e-mail, all of the applications and file permissions that I expect are presented there for me. Because we have this very strong networking architecture within the Rhapsody system.

KB: And this isn't even really terminal like services, because I'm harnessing the full power of my desktop machine. But it has the notion of, the sense of a network about it so that it can follow you along from your user data perspective and application preferences.

KB: Right.

KB: Exactly.

KB: Java is certainly very important to Apple. Just on the Mac OS 8 front we have a technology that we call the Mac OS runtime for Java --MRJ. And we're working very, very aggressively to release what we believe will be the highest performing Java VM, due this fall. [We're comparing this Macintosh version] against the fastest VM available under Windows --IE40 is our probably our target. We've licensed the Symantec Just In Time Compiler. It is doing exceptionally well in our labs.

On the Rhapsody front, we also include robust support for the Java platform defined by Sun, certainly 100 percent pure certified environment when we ship later this fall. And developers that are using AWT and 100 percent pure applications will certainly run well within Rhapsody as well as Mac OS. We certainly support that.

KB: We're certainly planning to have Wwing support in the MRJ release.

KB: We've got very good support for beans in both architectures.

KB: It's clear that Java is very important. We think there are many, many developers, though, that are looking for technologies above and beyond what Java can deliver today. And certainly any of the applications that are centered around some of the key market and technology initiatives from Apple are focused on design and publishing, are focused on education. Certainly our multimedia capabilities, they're looking for Apple to provide some technologies that are valuable in that space.

And we certainly have those. We have been talking for several months about Java wrappers for QuickTime that would make it possible to build a Java application, but it counts on the native and cross-platform implementation as QuickTime that delivers very, very significant capabilities and values.

Also on the developer framework front, we believe that the Yellow Box provides some capabilities that the Java platform lacks, as well. We've got a fantastic text subsystem that has great support for full internationalization, full localization. In fact, there's a great model for localization. But also very advanced typography, scaling and effectively resolution independent --

KB: Certainly.

KB: Absolutely. Metroworks is a fantastic partner of ours. They've supported all our important technology initiatives, and we've got a great spirit of cooperation as it relates to Mac OS X and Carbon.

KB: I guess that's not a huge surprise. We certainly believe that you need the right set of tools for the right types of applications for the right types of product that you're targeting. Visual Basic is an exceptionally popular environment for people that want to do quick applications to be used within an IS organization or a corporate environment. That's outside of the primary domain where Apple resides.

KB: I think it's much more important for us to have a strong presence in the Java base and it will be interesting to see the trends of Java development for those types of applications, rapid applications that are developed in an Internet or Intranet-centric Web environment versus VB.

I'd be surprised if Java wasn't approaching it in terms of size and importance.

KB: Partially. The fact of the matter is that the Macintosh has enabled, and the Mac OS in particular has enabled multithreaded applications for quite a few releases and years. The model has been one of cooperative scheduling versus pre-emptive scheduling, but it still has caused a good Macintosh developer to understand that parallelization is good --

KB: It hasn't had formal support for that, no. And that's certainly something that Mac OS X provides.

KB: Right.

Now, Apple has had a thread manager in previous systems and a multi-processing API for asymmetric multi-processing that certainly delivered events and semaphores and required synchronization. It wasn't a mainstream API, but developers have been exploiting those capabilities and benefits for a long time.

KB: It is likely that most device drivers will need to be rewritten for Mac OS X. As you're probably aware, the driver model is exceptionally closely related to the specifics of the core OS and the kernel in particular. And Mac OS X will be providing a new and distinct driver model.

That said, there are classes of devices for which the models between Mac OS X and Mac OS 8 may be very, very similar. And as we look towards new IO architectures and new I/O technologies, such as the USB and FireWire and IRDA and others, just understanding where we can commonize our driver model is something that we're certainly looking at for the longer term.

KB: Certainly, drivers and the driver model and the driver transition is critically important to us. We're putting a lot of effort in that internally and we'll have, we'll certainly have more to say about the driver model and our plans for a driver development kit in early 1999.

KB: Right. Mac OS X certainly supports all of "standard, modern buzz words". Applications will live in their fully protected address bases that are managed by the mach kernel. As we know, all execution system is scheduled in a pre-emptive fashion. The virtual memory subsystem is integrated directly into the core, so applications will have complete dynamic memory references of support for memory mapped file I/O, certainly very, very important.

Many of what you would consider to be traditional, modern OS capabilities will be delivered to Mac OS applications and Mac developers, and, therefore, our customers.

KB: Yes, applications that don't get modified to be Carbon applications will live in their own single address space, and within that address space will continue to use cooperative scheduling and multi-tasking.

That process that contains all those applications in and of itself is pre-emptively scheduled against other carbon applications, but we are not extending the new features of the OS to unmodified applications.

KB: Right. It shouldn't affect any other running applications.

KB: Well, there certainly are things that we're playing which we're not talking about. But we have the ability at Apple to do something that few, maybe no other companies are able to do, which is to tightly integrate and optimize our hardware designs with our system software designs. By working very closely, for example, with the next generation Power Macintosh, we are able to do things in the core OS to really distinguish the capabilities of our combined product. [We can make] one plus one equal to much more than two because we're able to synergize amongst ourselves.

There certainly are some things we're looking at in the longer term that will distinguish ourselves.

TNC: Any plans for Intel support? KB: We're completely focused on making the most out of the Power PC and, in particular, our current G3 designs. You know, certainly long, long term, having independence is important, but there are no plans to have anything except for Mac OS X running on Power Macintosh G3 systems and beyond.

KB: Certainly Mac OS X is primarily a desktop system that has very industrial strength and robust capabilities. And that as a base, it is certainly going to be a very, very popular and important server for desktop, for work group or department level uses, especially in our core customer bases.

KB: It's been my pleasure. Hope to do this again.