Developing For Multiple Platforms

Businesses expect software to run on Macintosh, DOS, Windows, and Unix. Moving an application to another platform is a daunting task that can change a developer's approach to writing software.

Douglas K. Olson

Businesses today expect the same applications to be available for Windows, DOS, and Macintosh computers. Consequently, engineers are finding ways to sustain and codify cross-platform development efforts. Their strategies are varied, and the process remains highly subjective, but new tools and techniques are gradually beginning to speed and simplify cross-platform development.

One simplification has come with ANSI C and C++, which freed developers from compiler-specific design. By adhering to ANSI C syntax, for example, developers can create code that comes closer than ever before to being compatible with compilers for multiple platforms. In effect, applications are moving toward real portability.

Toward Compiler Independence

Many issues still stand in the way of compiler independence. For one thing, despite the ANSI standard, various compilers interpret C syntax differently. The reality is that developers must still write C code for specific, individual compilers.

For example, ANSI C does not define the size of all data types. Integer size can be either 16 or 32 bits--whichever is optimal for a given platform. Developers often make the mistake of depending on the size of this variable in their code. And compilers on the same platform implement this data type differently.

Developers also need to be aware of processor-based restrictions. For example, compilers must align data structures on short- or long-word boundaries, according to the memory-addressing rules of various processors. Trouble can result when code makes different assumptions about such alignment.

Platform conventions also define compilers. For example, the Mac environment groups and identifies resources by four-character constants, such as ICON for an icon resource or PICT for a picture resource. Most Mac compilers let you assign these four-character constants to 32-bit variables. But this is not strictly legal ANSI C behavior and will fail on platforms that don't observe this convention.

The ANSI standard offers a mechanism for deviating from its imposed uniformity. For example, to tell a compiler to generate code for a specific processor, developers use #pragmas, C words that govern platform- and compiler-specific directives.

When groups of people program together, source code management tools are essential. The danger is that two people will modify the same code at the same time, destroying each other's changes. Also, it is often necessary to track code changes and store iterations. Unfortunately, until recently, most vendors of version-control software built their products for one line of platforms.

One common solution is to establish a system that acts as a neutral third party. For example, teams targeting Windows and the Mac could choose a source code control package on a Unix machine. Another strategy is to standardize on a version-control system for a given platform, such as Projector, part of the MPW. Here, the entire cross-platform team would have access to Mac machines and would check their code in and out of the Mac.

This picture is changing as vendors design source code management products for multiple platforms. One Tree Software's (Raleigh, NC) SourceSafe maintains compatible tools and source code database files that run on the Mac, Windows, and Unix. Intersolv's (Rockville, MD) PVCS Version Manager is a version-control product for Windows, NT, DOS, OS/2, and Unix.

Debugging is an inherently low-level, platform-dependent task. Now, no debuggers work the same way or present the same interface from platform to platfor m. The idiosyncratic nature of debuggers makes it a challenge for developers to acquire expertise in more than one platform.

Object-oriented frameworks, such as Apple's MacApp and Microsoft's Foundation Classes, provide a generic application to which developers need only add specific behavior. For example, MacApp has a class library that implements a standard Mac application--it handles menu commands, updates windows, dispatches events, deals with the Clipboard, and so on. The class library handles all the general items, and the developer provides the application-specific behavior.

Such frameworks can be a boon to development but, unless they target multiple platforms, can seriously hamper future ports. For example, Adobe originally developed Photoshop for the Mac using the MacApp framework and then decided to port the product to Windows. There was no abstracted, portable API into MacApp--and certainly no corresponding Windows version--so developers faced an unusual challenge (see the text box " Porting Adobe Photoshop: A Case Study").

Code Issues

To gain performance, virtually all commercial developers write key portions of application code in assembly language. By hand-assembling performance-sensitive components, the developer will generate more efficient code than the compiler and selectively give a boost to important operations. For example, painting with a mouse in a Photoshop document is a well-defined, highly performance-sensitive task. Because Adobe didn't want to compromise performance here, it wrote the inner loops of that function in assembly language.

The problem is that processor-specific assembly code is inherently not portable; to facilitate the porting process, developers have learned to maintain high-level language analogs of assembly language components. Now, when developers rewrite critical C code in assembly, they retain the original C code as well. With these C analogs, engineers can quickly move a package from one platform to the next. They can get a C version r unning on the new platform and only then decide whether to again rewrite specific sections of code in the new platform's assembler.

As RISC-based systems account for a larger share of the desktop market, future applications will use less assembly language. With RISC, assembling code by hand is dauntingly complex, and a compiler can almost always do a better job.

The move to RISC processors will present other challenges as well. Because it relies on a small and relatively simple instruction set, a RISC machine needs many more instructions than a CISC processor to represent a high-level function. For example, some Mac applications may double in size as they move from 680x0- to PowerPC-based platforms.

Like a Family Reunion

Historically, porting strategies can be compared to certain aspects of a family reunion. A defining moment of either is a family portrait--a snapshot documenting the state of application code for a particular platform at a given moment. In a real family, once the photo has been taken, members begin to move around; similarly, having recorded the code at an instant in time, developers begin changing it.

On the one hand, the application code for the original platform is modified as it is maintained and upgraded. At the same time, another team of developers is migrating the code, as recorded in the snapshot, to a new platform. So at a definable instant in time, one set of code begins heading in two directions, changing in various ways for different reasons.

Typically, once the port is completed, developers return to the first platform and begin planning the next major revision. But what should they upgrade? The original snapshot version has changed a lot, and in porting to the second platform, developers invariably add new features and functions. So where do developers start?

The usual answer lies in the family reunion. The latest versions for both platforms must somehow be reunited and reconciled to provide a basis for the revision. Like family members wh o have not seen one another for many years, the two sets of code do not easily recombine. Developers do their best to re-create a common code base that incorporates desirable features from both versions. But this process can become so difficult that it is often easier to port just the application in reverse order, from the second platform to the first.

Virtual APIs

One improvement over the family-snapshot approach is to emulate the original platform's API on the new platform. This is the next logical evolutionary step in development strategy.

Products are offering these emulated APIs and cross-platform code libraries. Examples are Quorum Software Systems' (Menlo Park, CA) Latitude, a Mac-to-Unix product, and Altura Software's (Pacific Grove, CA) Mac2Win, a Mac-to-Windows product. In theory, about 80 percent of the source code in a standard high-level language should compile.

However, emulated APIs and their libraries invariably trade performance for speed of development. One problem is that different APIs do not map precisely to one another. The extra code required to compile disparate operations from one graphics model to another can significantly slow application performance. One answer is to write platform-specific code here, reaching through the emulation and writing directly to the target API. This effectively trades portability for efficiency.

One way around fundamental differences is to create a virtual API that represents no single platform but embraces standard functions of many. This generic API runs on many platform APIs. When a developer builds a window, for example, this virtual API would call NewWindow() on the Mac side and CreateWindow() on the Windows side. One commercial product of this type is XVT (Extendable Virtual Toolkit) from XVT Software (Boulder, CO).

Unfortunately, these generic APIs often produce bland software. Such applications are unlikely to consistently leverage Windows or Mac GUIs in ways that users like. For this reason, virtual APIs are less attractive to commercial developers. These APIs are more practical for, say, vertical-market software developers or MIS departments that need to target an in-house application to multiple systems.

Successful Approaches

Today, one popular way to speed the porting process is to separate core code from edge code. Core code includes the basic operations that are common across all platforms. A spreadsheet performs calculations and manages data in cells; a word processor formats text; and image-processing software blurs and sharpens--these operations run more or less the same on all platforms. Edge code includes those parts of a program that deal with platform-specific issues, such as human-interface functions.

Engineering platform-independent code in one large effort and optimizing platform specifics in parallel, smaller efforts produces major efficiencies. This approach is popular with many commercial developers because it does not compromise the product's "platform flavor." Microsoft estimated that 90 percent of the then-unreleased Microsoft Word 6.0 would be based on common code.

Today's most widely used object-oriented development environments take advantage of core-/edge-code separation. One new cross-platform development framework from Borland is OWL (Object Windows Library). Another object-oriented framework, Bedrock, is being developed by Apple and Symantec. Bedrock will give developers a somewhat abstracted API that controls two separate frameworks: one for Windows and one for the Mac. This provides some of the benefits of a virtual API while letting developers separately refine edge code for each platform.

Trade-Offs

Today, market realities dictate that major applications must run on all mainstream platforms. Developers are reluctant to invest in technologies and feature sets that exist on only one platform. This is why Microsoft is eager to introduce the newest version of OLE to the Mac, and why Apple has made its QuickTime video technology available to Windows. Developers want to know about a feature's cross-platform potential before they incorporate it.

On the other hand, if developers decide not to target single-platform technologies, their applications tend to reflect the lowest common denominator. Such software may be workgroup-friendly, but if it lacks platform flavor, it can disappoint individual customers. Developers face an ongoing challenge to maintain a balance of features between platforms without compromising the unique flavor of each.

Developers must also decide just how much alike the same application should look on different platforms. They know that users tend to have a favorite platform and expect applications to reflect certain platform characteristics. Again, in striving for middle-of-the-road commonality, an application can fail to leverage the best attributes of either platform.

A related issue is the timing of releases. However methodical and even-handed engineers try to be in cross-platform development, they usually favor one platfo rm over another, so the second version tends to lag. A company determined to release versions for different platforms at the same time invariably compromises performance, features, or time-to-market in one version.

Managing cross-platform development teams involves different trade-offs. The challenge is to sustain work on two platforms, while challenging the imaginations of all developers. It's important to ensure that no one team gets stuck with too much drudgery for too long. One solution is to assign platform experts to developing edge code and put generalists to work on core code. Another is to have one team working on new features for one platform, while a different team ports a "snapshot" from that first platform to a second.

This latter approach can be effective in bringing software to market, but it really isn't sustainable for long, because it fails to efficiently leverage the teams' overall effort. This means products will be slow to market, and companies will incur high engineering ex penses.

Here to Stay

New operating systems are becoming increasingly portable. Users will soon be able to choose hardware and system software independently of each other. As a consequence, cross-platform development is here to stay. For developers, the ability to write portable code using techniques such as core-/edge-code segregation and object-oriented methodologies is becoming a key competitive advantage.

---

Douglas K. Olson is manager of engineering for imaging and video applications, Application Products Division, Adobe Systems. You can reach him on the Internet at dolson@mv.us.adobe.com or on BIX c/o "editors."