Volume Number: 15 (1999)
Issue Number: 2
Column Tag: From The Factory Floor

Universal Interfaces Today

by Nick Kledzik and Dave Mark, ©1999 by Metrowerks, Inc., all rights reserved.

This month, the Factory Floor visits with Nick Kledzik, Apple's Universal Interface-meister. With our upcoming move to Carbon and MacOS X, the time seems right for an update and Nick was kind enough to give us one.

Nick Kledzik <kledzik@apple.com> has been a software engineer at Apple for over 11 years working on various toolbox managers. In '93 he wrote an internal coding style document called "Building Code" which lead him to his current work of managing the Mac OS API's. Recently he has been working on MRJ (Apple's Java VM), developing JDirect 2.0 which enables java code direct access to the Mac OS toolbox. When not working he's probably pampering his new wife or their cats: Catbert and Hobbes.

Dave: How did the Universal Interfaces get started?

Nick: Back in '93 the PowerMac team was working on the software to enable Macintoshes to use the PowerPC processor instead of the 68k family. The team quickly realized that the existing 68k headers were riddled with 68k-isms and could not be compiled by xlc, the only PowerPC compiler at the time. The first approach was a one shot tool to munge the headers to be compatible with xlc. But, alas, the rest of Apple's software teams continued to use and modify the 68k based headers, and the PowerPC headers were so different that merging and synchronizing changes proved to be an immense time sink.

The solution that evolved was to have a central repository called MasterInterfaces in which all headers were stored. The headers were an augmented form of the 68k headers with their names changed to end in .i instead of .h to ease build rules. A tool called Interfacer was developed which could read the .i files and generate "universal" C headers. The name "universal" was coined because they could be read by both 68k compilers and the PowerPC compiler.

This model proved to be very powerful. The Interfacer was enhanced to generate MixedMode glue for all the System APIs. When we discovered that a #pragma needed to be added to all .h files, all it took was one change to the Interfacer tool and all generated .h files were updated.

In early '94 I headed up a group to fully implement this model. We merged all Apple's public and private headers into MasterInterfaces and updated the Interfacer tool to also emit assembly and Pascal interfaces. The result was the 2.0 Universal Interfaces. Then I started getting serious about being "universal". My goal for the 3.0 Interfaces was that they would "just work" with every compiler on the planet. To do so, every compiler dependent aspect of the headers had to be conditionalized and the core file ConditionalMacros.h had to be able to recognize and auto-configure itself.

Dave: What's the difference between Universal Interfaces and Universal Headers?

Nick: Apple uses the term "interfaces" in the generic sense of the interface between an application and the OS. That's the "I" in API. Metrowerks organized their CodeWarrior CD by naming files for Pascal as "Interfaces" and for C as "Headers". The result was that the term "Universal Headers" was born to describe Apple's Universal Interfaces for C.

Dave: What process do you go through to generate each new batch of Universal Interfaces?

Nick: The overriding question is when to release. For this, I look for either a milestone release from Apple (such as Mac OS 8.1 or 8.5) or a tempting release vehicle such as a CodeWarrior CD release. Once the ship date is locked down, I review the bugs that developers have reported and work with the various engineering teams at Apple to make sure that all changes have been checked into MasterInterfaces. The build part is easy. The Interfacer tool now runs in a batch mode, which means the Interfacer tool is only run once and it emits the C, Pascal, Asm, and Rez files in parallel. The entire build of 750+ files takes under 3 minutes!

Dave: With each new release of the Universal Interfaces, most everyone's code breaks. What is Apple doing to address this problem?

Nick: I review changes in MasterInterfaces and categorize them as to their effect on developers:

1. Transparent.
2. Source compatible because of grandfathering of old names or types.
3. Source compatible if developer changes #includes.
4. Binary but not source compatible.
5. Source but not binary compatible.
6. Neither source nor binary compatible.

Over 95% of the changes are type 1 and are never noticed by developers. For the rest, I work with the engineering teams to make them type 2 by using #defines or typedefs inside of OLDROUTINENAMES so that a developer can make the changes at his leisure. But a few, like moving SysBeep from OSUtils.h to Sound.h, could not be changed to type 1 or 2 because Sound.h already included OSUtils.h and you can't have circular includes.

But, the detection and flagging of these changes is still a manual process and some still slip by me. In the future, Interfacer will become smarter and automatically issue warnings or errors when a source incompatible change is made to a .i file.

Dave: What exactly is Carbon?

Nick: Carbon refers to the subset of Mac OS APIs (functions) in Universal Interfaces that will be supported on Mac OS 8.1 through Mac OS X. In addition, the only clients of Carbon APIs should be application-level code (apps, plugins, shared libraries, etc.) In Mac OS X, drivers will be built using different headers and APIs than applications.

Dave: How will Carbon affect the Universal Interfaces?

Nick: The plan is for a future release of Universal Interfaces to support Carbon development. That is, we will be adding #if statements to the Universal Interfaces so that a developer can assert that he is targeting Carbon (as opposed to System 7 or Mac OS 8.x) and get compile time errors if his code calls any Mac OS function that is not in Carbon. Note, even if he does not assert he is targeting Carbon, he will still get a link time error because you link against different stub libraries when building applications for Carbon.

Dave: Does this mean we are going to have even more Stub Libraries?

Nick: At this time, the plan for Mac OS X is to have one CarbonLib stub library. I'm considering making a similar MacOS8Lib stub library which contains fragments for InterfaceLib, DragLib, SoundLib, etc. This will make it much easier for developers to figure out which stub libraries to use. The problem is there are enough cases where developers want or need a finer level of control (e.g. BlockZero from InterfaceLib vs DriverServicesLib), that I will probably need to ship both the high level conglomerate stub libraries (e.g. MacOS8Lib) and the low level individual stub libraries (e.g. InterfaceLib).

Dave: What changes do you see coming down the pike for programmers who want to call the Mac Toolbox directly from their Java programs?

Nick: Java has and will continue to become faster and easier to use on Macs. But, there is a fundamental impedance mismatch between Java and the Mac OS toolbox. Java is an object oriented language with garbage collection and a theoretically uncrashable runtime. The Mac OS toolbox is none of those things.

Java programmers have a couple of options for easy access to the Mac OS toolbox:

• Use the standard Java classes such as java.io.File - The implementation of those standard classes on MRJ will "do the right thing" on the Mac OS, such as setting file types and creators via Internet Config.
• Use packages written specifically for java clients who want to access toolbox functionality such as QuickTime for Java or MRJToolkit.
• MRJ 2.1 contains a feature called JDirect which allows Java code to easily call into Mac OS shared libraries and the MRJ 2.1 SDK contains java bindings generated by the Interfacer tool. The combination allows developers to call any Mac OS API directly from Java. But, the developer still has to write Java code to handle things like Pascal strings, memory allocation and deallocation, etc.

As time goes on, Apple and third parties will continue to write more Java packages which make it easier to use Mac OS specific functionality from Java. It is an open question whether anyone will write a Mac OS only framework in Java (a la MacApp).

Dave: In a similar vein, what changes do you see for C++ and Pascal programmers?

Nick: The Mac OS toolbox has standardized on procedural ABIs (application binary interfaces). This has enabled applications to be written in most any language. It is unlikely that any non-procedural features (e.g. C++ objects) will be added to the Mac OS APIs. These sorts of things should be layered onto the Universal Interfaces as is done with PowerPlant.

There are a few C++ things which do make sense in the Universal Interfaces such as inlined functions instead of parameterized macros and the use of name spaces. These are both on my to-do list.

Pascal Interfaces will continue to be generated from MasterInterfaces. But, because Pascal has not been standardized the way C has, developers using different Pascal compilers have needed to modify Apple's Universal Interfaces for Pascal to work with their compiler. Since Pascal does not have a preprocessor, there really is no way to make truly universal interfaces.

I think the long term solution for Pascal and other language support (e.g. Lisp, Fortran, Basic, etc.) is to open up the Interfacer tool. A current project of mine is researching how to deliver a "Universal Interfaces Kit" which contains the data and a framework for developers to generate their own interfaces.