Tools for OpenDoc Development

Apple Computer, Inc. Contents

Component Software and OpenDoc...... 1 Software Developer Segments ...... 2 Application developers...... 2 Solution developers...... 2 Content developers ...... 3 Client/server developers...... 3 OpenDoc: A solution for diverse developer needs...... 3 Apple’s OpenDoc Tools Strategy: Five Strategic Initiatives...... 4 Strategic Initiative #1: Provide Enabling Technologies for Macintosh OpenDoc Development ...... 5 Code Fragment Manager (CFM) ...... 5 System Object Model (SOM) ...... 5 Availability...... 6 Strategic Initiative #2: Enhance Macintosh Development Environments to Support OpenDoc ...... 7 Apple products ...... 7 Third-party products ...... 8 Strategic Initiative #3: Leverage Existing Applications with OpenDoc Migration Tools...... 12 The procedural approach to OpenDoc migration...... 12 The framework approach to OpenDoc migration ...... 13 Strategic Initiative #4: Create Cross-Platform OpenDoc Development Tools ...... 15 OpenDoc Development Framework ...... 15 OpenDoc builders...... 16 Strategic Initiative #5: Foster the Creation of Third-Party OpenDoc Tools...... 17 AppWare...... 17 Oracle Power Objects ...... 17 Possible future Apple and IBM OpenDoc investigations...... 18 Developing OpenDoc Component Software for Macintosh Systems: How to Start Today...... 19 Why You Should Develop for OpenDoc ...... 20 Contact Information ...... 21 Component Software and OpenDoc

Over the few years, the software industry will undergo a dramatic transformation as monolithic applications give way to component software based on object computing. The traditional software development approach, together with the increased functionality required by incremental market segments, has led to monolithic applications that become more and more complex every day. The transformation to a component software industry is being fueled by the need to develop customized software solutions through the use of modular building blocks. Such a modular approach will reduce the overall complexity and code size of the software. It will also enable developers to use many code components again and again in different applications—and in some cases, to market their components to other developers. In all these ways, the component approach will help developers be more competitive. Software development based on components offers these business and technical benefits: ¥ Reduced cost of developing and maintaining applications ¥ Faster time to market ¥ Ability to reuse code (a previously unfulfilled promise of software development) ¥ Quicker response to customer needs, including the ability to easily customize software to satisfy different market segments ¥ Higher-quality and more reliable systems that can grow with business needs ¥ Development of less-complex, self-contained modules that are easier to test and debug, resulting in higher customer satisfaction ¥ Easier software integration and creation of compound documents To respond to industry needs and enable the development of a true component software industry, Apple Computer, Inc. created the OpenDoc architecture in cooperation with IBM Corporation and Novell, Inc.—a partnership known as Component Integration Laboratories (CI Labs). OpenDoc is an industry standard for software integration that enables the development of cross-platform component software. Vendors who intend to offer products based on OpenDoc include Apple for Mac OS, IBM for OS/2 and AIX, and Novell for Windows. The Macintosh implementation will include the OpenDoc Standard Interchange Format (Bento), the Open Scripting Architecture (OSA), OpenDoc Services, and OpenDoc Component Services from Apple; the System Object Model (SOM) technology from IBM; and the Component Glue technology (for interoperability between OLE and OpenDoc components) from Novell. This document provides an overview of Apple’s OpenDoc tools strategy. It describes the different tools that developers can use to develop OpenDoc components not only for the Macintosh platform, but also for cross-platform deployment.

Tools for OpenDoc Development Page 1 First, however, we will take a brief look at the types of developers who can most benefit from OpenDoc.

Tools for OpenDoc Development Page 2 Software Developer Segments

There are many types of developers and there is no simple way to characterize each type’s use of and requirements for development tools. For the purposes of this paper, we will consider the needs of four major developer segments: ¥ Application developers ¥ Solution developers ¥ Content developers ¥ Client/server developers

Application developers Application developers consist of traditional software developers: commercial developers, in-house developers, system integrators, VARs, and independent consultants. These developers typically use languages such as Pascal, C, and C++, and integrated development environments that offer compilers, debuggers, linkers, and a variety of low-level, high- performance tools. Application developers need to get the most out of a platform to keep pace with the ever more complex requirements of their customers. Today, they face technical and economic challenges that force them to: ¥ Create larger, more feature-rich, and therefore more complex applications to meet increasingly ambitious and changeable customer requirements ¥ Work with more complex and numerous system software in order to incorporate the latest technologies in their applications ¥ Create products that will run on multiple platforms with minimal additional investment ¥ Develop this complex, cross-platform software quickly and easily

Solution developers Solution developers deliver innovation and benefits to end users by integrating applications and components into seamless solutions. These developers must: ¥ Rapidly prototype new solutions ¥ Quickly and easily develop solutions that are inexpensive and yet can grow with their customers’ needs ¥ Develop solutions without extensive programming so that they can focus on understanding business needs rather than computers ¥ Quickly and easily customize a solution developed for one customer to another customer’s specific needs

Tools for OpenDoc Development Page 3 Content developers Content developers create compelling interactive experiences for their customers by integrating media developed using specialized tools for sound, video, animations, graphics, and/or images. They need to: ¥ Integrate content developed with different tools ¥ Make multimedia content that is compelling and performs well without having to deal with complex programming languages (such as C or C++) ¥ Ensure that even the most naive computer users (including kids) can take advantage of the content they develop ¥ Deliver content that will play on any platform or configuration

Client/server developers Client/server (C/S) developers build applications that must scale to the variable resources of an organization while tapping into the growing body of corporate information and systems. C/S developers must be able to: ¥ Scale their applications for distributed environments ¥ Integrate a growing body of legacy code into new solutions ¥ Master code reuse and repurposing ¥ Create interoperability between heterogeneous systems

OpenDoc: A solution for diverse developer needs Developer needs are truly diverse, but all developers need to do more with less, to cope in a multiple-platform world, and to have access to new technologies that provide the solutions their customers need. OpenDoc addresses all of these needs. For developers to enhance their current applications as well as to create new applications and components around OpenDoc, a new generation of development tools is required. This new generation will include both enhanced versions of current tools and entirely new ones. Such tools will ease the transition to component-based software and foster the development of individual components. This paper addresses how Apple plans to respond to developers’ needs by ensuring the availability of a wide variety of tools to support OpenDoc component development, and by helping Macintosh developers obtain a leadership position in the emerging component software industry.

Tools for OpenDoc Development Page 4 Apple’s OpenDoc Tools Strategy: Five Strategic Initiatives

Apple’s OpenDoc Tools Strategy is based around five major initiatives that will create a portfolio of development tools for the different developer segments. The initiatives are to: ¥ Provide enabling technologies (a runtime software infrastructure) to facilitate OpenDoc development for the Macintosh platform ¥ Enhance existing Macintosh development environments to support OpenDoc development ¥ Leverage existing applications by delivering OpenDoc migration tools ¥ Create a new generation of cross-platform OpenDoc development tools ¥ Work with CI Labs members and evangelize third-party tool vendors to foster the creation of a broad suite of OpenDoc tools The remainder of this white paper will discuss each of these strategic initiatives in more detail, identifying the particular developer segment that will benefit from each initiative.

Tools for OpenDoc Development Page 5 Strategic Initiative #1 Provide Enabling Technologies for Macintosh OpenDoc Development

Developer segment: Application developers

To develop and run OpenDoc based applications, developers need technologies for shared code, shared objects, and dynamic linked libraries. Two key products provide these fundamental capabilities for the Macintosh implementation of OpenDoc: ¥ Apple’s Code Fragment Manager ¥ IBM’s System Object Model Apple believes that these enabling technologies are required to ensure the success of OpenDoc among developers and to facilitate the development of higher-level OpenDoc tools by both Apple and third-party vendors.

Code Fragment Manager (CFM) As a vital step in supporting OpenDoc, Apple has developed the Code Fragment Manager. CFM enables the development of shared libraries, drop-in code modules, and dynamic linking on Macintosh systems. It will be supported by other Macintosh development tools. CFM runtime software is already a core part of the system software on Power Macintosh systems; a version is also under development for 680x0-based Macintosh models.

System Object Model (SOM) Apple has licensed IBM’s System Object Model technology and is in the process of porting it to the Macintosh platform. SOM is an object-oriented programming technology for building, packaging, and manipulating binary class libraries. It provides a language- independent run-time mechanism for dynamic object linking. Traditionally, it has been difficult with an object-oriented C++ interface to produce shared libraries that provide binary compatibility from release to release. SOM removes these limitations and so is an ideal choice when developing such an interface to a shared . The use of SOM as the underlying object model for OpenDoc provides the benefits of: ¥ Language-neutral components, which allow developers to build components in one language, subclass them in another language, and include them in an application that was developed in yet another language. ¥ Component inheritance and subclassing, which solves the “fragile base class” problem, avoiding the need for client libraries to be recompiled when the base class they inherit from is in a different library and is changed. (This capability is called “release-to-release binary compatibility,” or RRBC.) With SOM, developers do not need to supply source

Tools for OpenDoc Development Page 6 code to allow their components to be subclassed, and a component can be modified or enhanced without the need to recompile existing applications that use that component. To offer the benefits of multiplatform support and base-class resolution, SOM requires the use of the Interface Definition Language (IDL) as a first step in the development process. SOM is a foundation technology for OpenDoc. On the Macintosh platform SOM runs on top of CFM. Therefore, SOM will be available on both 680x0-based and PowerPC processor-based Macintosh systems. (The Macintosh SOM implementation is already a “fat binary” containing both the Power Macintosh and 680x0 versions.)

Availability CFM has been available on Power Macintosh systems since March 1994. Prerelease versions of CFM-68K and SOM for Macintosh have been made available to Macintosh developers since late 1994 via the ETO (Essentials¥Tools¥Objects) and MPW Pro products sold through the APDA catalog, and in the OpenDoc DR1 release. New versions will be available via future ETO, MPW Pro, and OpenDoc developer releases. Final versions of both products are expected during the second half of 1995, before the OpenDoc SDK is made available to developers.

Tools for OpenDoc Development Page 7 Strategic Initiative #2 Enhance Macintosh Development Environments to Support OpenDoc

Developer segment: Application developers

During the last couple of years, Apple has worked both internally and with third-party vendors to ensure the availability of new development environments and tools to facilitate application development for the Power Macintosh platform. A parallel effort was started to ensure support for OpenDoc in Macintosh development environments. Here is an overview of that effort.

Apple products

680X0 COMPILERS Apple is phasing out its old 680x0 MPW C and MPW C++ (CFront) compilers and moving to Symantec’s two MPW compilers, SC and SCpp. These compilers are being updated to provide precompiled headers (which will result in better compilation speed), support for CFM-68K, and templates. With CFM-68K support, the compilers will allow developers to create applications that use the CFM and SOM runtimes, thus allowing the use of the shared libraries needed for OpenDoc development. Prerelease versions of SC and SCpp supporting CFM-68K have been available to developers since late 1994 via the ETO and MPW Pro products. New versions will be available via future ETO and MPW Pro releases. Final versions are expected during the second half of 1995, before the OpenDoc SDK becomes available to developers.

POWER MACINTOSH COMPILERS As part of ETO and MPW Pro, Apple ships PPCC, a native Power Macintosh C and C++ compiler that is recommended for current development projects. On a Power Macintosh 8100, this compiler is approximately two to three times faster than the same compiler running in emulation mode on the same system. PPCC can be used today to develop OpenDoc applications. Apple is currently developing its next generation C and C++ compilers (called MrC and MrCpp) to replace the PPCC compiler. These new products are based on the same back- end code generator as PPCC, but they use the Symantec C/C++ front end. They will operate up to four times faster than the native PPCC, will support precompiled headers and other language features such as templates and , and will produce high- quality code comparable to any produced by other current PowerPC compilers. MrC and MrCpp will have all the functionality required to support development of OpenDoc components. Regardless of the development environment and compiler used

Tools for OpenDoc Development Page 8 during the development process, these will be the production compilers that Apple recommends to Macintosh developers. Prerelease versions of MrC and MrCpp have been available to developers since late 1994 via the ETO and MPW Pro products. Final versions are expected in the first half of 1995.

DEBUGGERS Apple is developing both a new 680x0 Macintosh debugger and a new Power Macintosh debugger. These new products have a better user interface, can be used to debug locally or remotely (via an AppleTalk network system or serial connection), and support CFM and SOM (and thus OpenDoc). Prerelease versions of both debuggers have been available to developers since August 1994 via the ETO and MPW Pro products. New versions will be available via future ETO and MPW Pro releases. The final version of the Power Macintosh debugger is expected during the first half of 1995, while the final version of the 680x0 debugger is expected during the second half of 1995, before the OpenDoc SDK is made available to developers. Both debuggers have also been licensed to Symantec Corp., and prerelease versions are currently available with the Symantec C++ 8.0 product.

LINKERS AND OTHER TOOLS In addition to the new compilers and debuggers, Apple will provide new linkers, libraries, and MPW tools that incorporate support for CFM and hence for OpenDoc. The ILink 680x0 linker has been modified to build applications and shared libraries for the CFM-68K runtime. Apple continues to improve its MPW based linker (called PPCLink) for developing Power Macintosh applications. The current version is a native Power Macintosh tool and therefore runs very fast on these machines. It can also generate executable applications directly.

Third-party products In parallel to its internal tools development efforts, Apple has been working closely with third-party tool vendors to ensure that new development tools as well as existing 680x0 and Power Macintosh development environments incorporate the necessary features to support OpenDoc development. Contact information for all of these companies can be found at the end of this paper.

HEIZER SOFTWARE Heizer Software has announced ODTools, a collection of tools for Macintosh OpenDoc developers that supports the inspection, creation, editing, and general manipulation and programming of OpenDoc documents at the OpenDoc Standard Interchange Format (Bento) level. According to Heizer, ODTools could be considered as a ResEdit for OpenDoc. ODTools can be used to: ¥ Understand the structure of an OpenDoc document

Tools for OpenDoc Development Page 9 ¥ View and adjust the configuration and connections of parts ¥ Validate and test parts ¥ Develop and test families of plug-ins ¥ Configure and connect parts with plug-ins ¥ Extract parts and data ¥ Edit draft properties, windows, frames, and storage units ¥ Build and update documents ¥ Decompile documents to, or recompile them from, a structured text format The initial release of ODTools will include several programs, including: ¥ ODInspector, which displays a hierarchical view of containers, objects, properties, types, and values. Users can choose between an OpenDoc Standard Interchange Format (Bento) view or an OpenDoc view. They can also inspect private Bento objects and data. ¥ ODEdit, which allows the creation and editing of OpenDoc documents. The main display in ODEdit is a graphical network of OpenDoc objects in the document. Users can cut, copy, paste, drag, and delete selected objects. New objects and properties can be defined and inserted. OpenDoc objects can be connected and unconnected. ¥ ODDecompile, which decompiles an OpenDoc document into a structured text format that can be edited and recompiled later. ¥ ODCompile, which compiles a structured text program created with ODDecompile or written from scratch in a text editor into an OpenDoc document. ODTools 1.0 is expected to ship at the same time as Apple ships OpenDoc 1.0 for the Macintosh. A preliminary version of ODTools with limited documentation and support is available directly from Heizer Software.

METROWERKS Metrowerks is aggressively pursuing OpenDoc support on both the 680x0 and Power Macintosh platforms as well as on 32-bit Windows systems. Metrowerks’ development environment is CodeWarrior. On the 680x0 front, Metrowerks is in the process of implementing CFM-68K support in CodeWarrior, which will enable OpenDoc development. Metrowerks will introduce these tools as a developer release at Apple’s Worldwide Developers Conference in May 1995. For Power Macintosh systems, Metrowerks is shipping a PowerPC version of CodeWarrior that supports OpenDoc development. A “lite” version of this product was included as part of the latest OpenDoc DR1 release in January 1995. Metrowerks’ PowerPlant application framework supports OpenDoc parts development. Metrowerks is working on implementing stronger support for OpenDoc within PowerPlant in mid-1995. PowerPlant Constructor, Metrowerks’ view editor, can already be used to modify parts views dynamically.

Tools for OpenDoc Development Page 10 Metrowerks debuggers currently support the debugging of OpenDoc parts and Metrowerks is investigating new avenues of development in order to support more in- depth support for parts debugging.

PICTORIUS INCORPORATED Pictorius Incorporated announced that it plans to begin intensive development of OpenDoc support for the company’s line of development tools by the end of this year. Prograph CPX, the visual programming environment, will support OpenDoc on Macintosh and Windows NT and ‘95 by means of an interface to SOM. Initially CPX will allow creation of applications that are OpenDoc “containers”. Support for OpenDoc “part” creation will follow in a later phase. Support for SOM in CPX will have the added benefit of allowing developers to take advantage of any third party class libraries written in C++.

SYMANTEC Symantec’s C and C++ compilers for MPW (SC and SCpp) are being updated to support CFM-68K and, as a result, OpenDoc. Prerelease versions of SC and SCpp with CFM-68K support have been available to developers since late 1994 via the ETO and MPW Pro products. New versions will be available via future ETO and MPW Pro releases. Final versions are expected during the second half of 1995, before the OpenDoc SDK becomes available to developers. In February 1995, Symantec introduced its new Power Macintosh development environment, Symantec C++ 8.0 for Power Macintosh. This product is the result of a joint effort between Apple and Symantec to create a development environment that combines the ease of use and speed of Symantec’s Think products with the flexibility and configurability of Apple’s MPW. Symantec C++ for Power Macintosh includes project model and library support for OpenDoc and SOM, so users can easily build and debug SOM and OpenDoc components. Both Metrowerks and Symantec are investigating other possible OpenDoc products such as application frameworks, visual interface builders, and cross-platform development tools.

QUASAR KNOWLEDGE SYSTEMS (QKS) QKS is working to support OpenDoc development across its three key products: Agents Object System, VisualAgents, and SmalltalkAgents. Agents Object System (AO/S) is a collection of components and services designed to be shared among multiple applications in a real-time multithreaded object environment, enabling high-performance collaboration between the applications and their objects and components. AO/S components and services implement various task frameworks and services such as a Cyberspace engine, scriptable database access, a local database, a hypermedia engine, and miscellaneous functions and services. VisualAgents is an entry-level version of SmalltalkAgents that is oriented towards the consumer and enthusiast marketplaces. It provides a rich set of useful applications and commonly desired services designed to be managed and used via the OpenDoc metaphor. These applications are all network aware. They are managed via a shared database engine to

Tools for OpenDoc Development Page 11 combine internetwork services, rich document processing, time and task management, and electronic mail and communication. VisualAgents also includes a high-powered interface builder and a software authoring environment for combining existing components into custom solutions. VisualAgents provides a wide range of users with access to visual authoring tools in combination with both AppleScript and a modern implementation of the language. SmalltalkAgents is a professional software development environment based on a next generation of the Smalltalk language, QKS Smalltalk. SmalltalkAgents provides a rich set of task frameworks and allows live manipulation of objects and classes, enabling high performance and productivity when developing sophisticated applications. Because of the unique technology of its underlying Agents Object System architecture, SmalltalkAgents is well suited to the development and delivery of complete applications, as well as of components that need to function in both a static world and in a dynamically changing world of services and requirements such as OpenDoc. QKS is planning to deliver a Windows version of SmalltalkAgents to provide critical cross-platform application support while ensuring that each platform’s unique features are clearly accessible through AO/S technology. Although Smalltalk is best known as a popular object-oriented language for the corporate marketplace (having grown to a number one status), SmalltalkAgents is unique because of its focus on supporting host functionality and high-performance interaction with frameworks and services—capabilities that have traditionally been accessed effectively only through languages such as C, C++, Pascal, and assembly language. QKS has also focused on the scripting and composition side of the authoring problem to bring Smalltalk to a much broader audience, opening up wider access to the rich functionality embodied in the Macintosh .

OTHER THIRD-PARTY PRODUCTS There are many other tools vendors providing a variety of products ranging from Pascal and Fortran compilers to Smalltalk development environments, application generators, visual programming environments, class browsers, debuggers, and many other tools. Apple is working with many of these vendors to ensure the availability of a broad variety of OpenDoc development tools.

Tools for OpenDoc Development Page 12 Strategic Initiative #3 Leverage Existing Applications with OpenDoc Migration Tools

Developer segment: Application developers

During the last decade, developers and their customers have invested a lot of time and money in Macintosh and Windows applications. Those applications are crucial to meeting everyday business needs. Neither developers nor customers will accept a new development paradigm unless this legacy code can be enhanced, adapted, or converted with minimum disruption to their businesses. Therefore, access to migration tools that enable current applications to acquire OpenDoc functionality is a key developer requirement for adopting OpenDoc. Apple’s initiative for supporting OpenDoc migration addresses both major approaches to traditional Macintosh application development: procedural development and object-oriented framework development.

The procedural approach to OpenDoc migration In a procedural environment, the developer writes an application by making a series of calls to library routines provided by the system (the Toolbox on Macintosh systems), as well as to routines written by the developer. The developer code sits on top of the system code, and the developer is responsible for providing the behavior and flow control of the application. During the last decade, a variety of tools for procedural Macintosh application programming have been available. Some of them—including Apple MPW, Symantec C and C++, and Metrowerks CodeWarrior— have already been mentioned in this document. A key part of Apple’s OpenDoc Tools strategy is to provide procedural developers with a way to incorporate OpenDoc functionality into existing applications. Apple’s tool for this is called Container Application Library (CA Lib). CA Lib is a library of routines that developers can use to take existing applications and make them OpenDoc “containers.” The basic purpose of CA Lib is to provide some of the functionality of the OpenDoc Shell and of a root OpenDoc part so that an application can contain OpenDoc parts (and OLE parts through the OLE interoperability provided by OpenDoc). Prerelease versions of CA Lib will be available to developers in future developer releases of the OpenDoc SDK. The final version is expected during the second half of 1995, before the final OpenDoc SDK becomes available. CA Lib will be distributed using the same distribution mechanisms as OpenDoc.

Tools for OpenDoc Development Page 13 The framework approach to OpenDoc migration The procedural software development approach has produced major improvements in the quality of software over the last 20 years, but its limitations have been painfully apparent to developers. These limitations include difficulty in extending application functionality, difficulty in factoring out common functionality, and large maintenance overhead. To overcome these limitations, developers have adopted object-oriented programming (OOP) technologies, and, in particular, application frameworks. OOP can significantly increase developer productivity and encourage innovation. By automating the development of the generic content of an application through the use of a framework, system providers make it possible for developers to concentrate on the specific areas of expertise of their applications. An application framework can be defined as a collection of software libraries with rich functionality and interconnections that provide an infrastructure for applications. In other words, a framework is a template that provides a foundation for the default behavior required in an application (windows, scroll bars, menus, other system-level services, printing, and so on). Using a framework can dramatically decrease the amount of code that a developer has to program, test, and debug. This translates not only into faster development, but also into applications that are better structured and more reliable. The overall benefit of frameworks is that they enable a higher level of code and design reuse than is practical with other approaches. By providing support for new technologies and APIs in a framework, system vendors can help developers more quickly deliver applications that integrate the new functionality provided by those APIs. Frameworks: ¥ Reduce coding, testing, and debugging. By virtue of the interconnections among class libraries, much of the needed functionality for each application already exists in the framework. ¥ Facilitate functionality extension and specialization in a reliable way. Developers only need to write relatively small amounts of code to modify or extend a framework for the needs of a specific application. Because the underlying code remains the same from program to program, a high degree of reliability is established in applications built on the framework. ¥ Reduce maintenance. Due to inheritance, when a framework bug is fixed or a new feature is added, the benefits of those changes become available more quickly to the derived classes. Changes are made only in one place, so the chance of introducing additional errors in the code is minimized. Apple’s flagship object-oriented software framework for developing Macintosh applications is MacApp. Although initially distributed as Object Pascal code, MacApp has had several transitions since its introduction in 1988, and the current version (3.1.3) is written in and distributed as C++ source code. MacApp: ¥ Makes it easier for developers to write stable and robust applications ¥ Includes a failure-handling system that provides a relatively easy way to catch errors when they occur

Tools for OpenDoc Development Page 14 ¥ Provides a memory-management system that sets up reserves so that an application can still report errors and perform vital functions even when memory is critically low ¥ Offers many utility functions that make using the Toolbox safer and more convenient ¥ Helps developers organize code into well-structured modules and classes—a capability that is especially important for team programming and for large applications ¥ Offers a good framework for prototyping and incremental development ¥ Provides a view system with a 32-bit coordinate for applications that must deal with large coordinates, and standard solutions for features such as scrolling and printing ¥ Includes built-in support for the Apple Human Interface guidelines (including support for Undo, keeping menus up to date, and providing standard alerts and dialogs). MacApp has been and continues to be popular with a large community of Macintosh developers, not only when used with Apple’s MPW but also with development environments from Symantec and Metrowerks. An upcoming version of the product, MacApp 3.5, will extend the life of today’s MacApp based applications by helping developers move to OpenDoc. It will have container support built into the framework so that developers who want to add new functionality to their existing programs can do so by embedding OpenDoc part editors into them. Prerelease versions of MacApp 3.5 will be available to developers during 1995 in future releases of ETO and MPW Pro, as well as through a MacApp developer seeding program. The final version is expected to be released soon after the OpenDoc SDK becomes available. For procedural-based as well as MacApp based applications, new part editors can be created using any OpenDoc part editor development method (programming directly to the OpenDoc API using traditional C or C++ development environments, using the OpenDoc Development Framework, and so on).

Tools for OpenDoc Development Page 15 Strategic Initiative #4 Create Cross-Platform OpenDoc Development Tools

Developer segments: Application, solution, content developers

OpenDoc is one of the most important system technologies introduced in the ’90s. Apple’s priority is to support OpenDoc not only in traditional Macintosh development tools such as MPW and MacApp, but also in a new generation of cross-platform OpenDoc development tools. These tools will be targeted for solution, content, and client/server developers as well as for application developers.

Developer segment: Application developers

OpenDoc Development Framework The OpenDoc Development Framework (ODF) is an object-oriented framework written in C++ that is targeted for building cross-platform (Macintosh and Windows) OpenDoc components. Like MacApp, ODF makes the process of creating software easier by implementing a lot of default behavior in the framework. Although the OpenDoc architecture itself is cross platform, when developers want to implement components on different platforms, those platforms’ different user interfaces and graphic models need to be considered. While most cross-platform OpenDoc components share a large percentage of code, some code remains platform specific—in particular, user-interface code. ODF deals with this by providing a platform-independent interface to common services, thus empowering developers to expedite cross-platform development and deliver native look-and-feel components. In addition, ODF provides a cross-platform resource-description language and an associated compiler called ODFRC (OpenDoc Development Framework Resource Compiler). ODFRC is a C-like language that allows developers to define the resources needed by OpenDoc components. After compiling the code, the developer has Macintosh or Windows resources that are ready to be used by the OpenDoc component. By using ODF, developers will be able to: ¥ Quickly develop applications that leverage development resources to provide multiplatform operability ¥ Lower their maintenance effort on applications, which reduces revision costs ¥ Provide product updates and integrate new OS functionality more easily ¥ Ensure correct behavior and interoperability between parts

Tools for OpenDoc Development Page 16 Apple is working to ensure that the most prominent development environments and compilers for both the Macintosh and Windows platforms support ODF so that developers will be able to use their preferred environment and tools. Prerelease versions of ODF have been made available to developers since December 1994 through a developer seeding program. New ODF developer releases will be available close to the time of new OpenDoc developer releases. The final version of ODF is expected to be available soon after the OpenDoc SDK. Apple’s frameworks offerings give developers two options for OpenDoc migration. For existing MacApp based code, developers can use MacApp 3.5 to turn an application into an OpenDoc container. To add new functionality to container applications using components, and to develop new OpenDoc components, Apple recommends the OpenDoc Development Framework (ODF).

Developer segments: Solution and Content developers

OpenDoc builders OpenDoc brings the value of object-oriented technology much closer to the desktop. Consultants, VARs, system integrators, and software installers will deliver this value to end users by assembling OpenDoc components into custom solutions. Customers will receive software that meets their needs both in function and behavior. The creation of custom solutions from OpenDoc components increases the value of software for customers, but it requires the right tools. Today, HyperCard and AppleScript provide environments to integrate applications and automate tasks. As precursors of tools planned for OpenDoc, they act as prototypes for OpenDoc solution tools. When OpenDoc ships, Apple’s solution tools will enable the automation of OpenDoc components to create full-scale custom solutions. AppleScript will be used to control components and HyperCard will evolve to support OpenDoc. New tools designed specifically to ease the effort of OpenDoc solution building are being developed in parallel with the creation of the OpenDoc architecture. OpenDoc offers new power to integrate different media, and Apple’s media tools will move to OpenDoc very quickly. With these tools, media development time will decrease as media and scripts become modifiable objects. Media tools will be combined with business management tools to provide asset tracking tied to the creative process. Apple’s suite of OpenDoc solution tools—enhanced versions of existing products plus new tools—will help drive the use of OpenDoc and components. The demand for custom software will help build a solid business for components and custom solutions. This will change the software industry and help developers increase their business.

Tools for OpenDoc Development Page 17 Strategic Initiative #5 Foster the Creation of Third-Party OpenDoc Tools

Developer segments: Solution and client/server developers

In parallel with the effort to develop OpenDoc, Apple is investigating possible collaborations with CI Labs members and other third-party tool vendors to ensure that a broad variety of OpenDoc development tools is available for Macintosh and other platforms. Third-party development environments for application developers from Heizer Software, Metrowerks, and Symantec were discussed earlier in this document. This section describes current and upcoming OpenDoc tools for solution integration and client/server development.

Developer segment: Solution developers

Novell AppWare In April 1995, Novell Inc. announced that its AppWare visual builder will support OpenDoc as a cross-platform development tool for Macintosh and Windows systems. AppWare will evolve to OpenDoc compatibility in three stages. First, it will gain the ability to compile AppWare Loadable Modules (ALMs) into OpenDoc components. According to Novell, this capability will be included with AppWare 2.0 on the Macintosh by late 1995 and on Windows by mid-1996. Phase two will allow AppWare to accept OpenDoc components in its building environment. At that point, ALMs and OpenDoc components will be interchangeable. In phase three, AppWare itself will become an OpenDoc component. For more information about AppWare support for OpenDoc, contact Novell Inc. directly.

Developer segment: Client/server developers

Oracle Power Objects Oracle Corp. plans to add support for OpenDoc to Oracle Power Objects, the company's next-generation tool for building workgroup client/server applications. OpenDoc support will make Oracle Power Objects even more powerful because an application can incorporate information from any application. This flexibility is good for

Tools for OpenDoc Development Page 18 developers. And because the Oracle Power Objects platforms, Macintosh System 7, Windows, and OS/2, all will support OpenDoc as well, the product will maintain complete portability. This is the first announcement from a vendor regarding client/server tools for OpenDoc. Apple is working with other vendors to make additional tools available for this market segment.

Developer segment: Application developers

Possible future Apple and IBM OpenDoc investigations Apple and IBM are investigating the possibility of creating cross-platform class libraries, frameworks, and visual builders for OpenDoc development on Macintosh and OS/2 systems. As part of this effort, the two companies are assessing the feasibility of developing a version of Apple’s OpenDoc Development Framework for the OS/2 platform, and of porting the IBM Open Class to the Macintosh platform. There are many other third-party tool vendors in the Macintosh market, including Absoft Corporation, ACI, Bowers Development, Language Systems Corporation, Mainstay, Pictorius International, and Software Designs Unlimited. Apple is working aggressively with them to ensure that new tools for OpenDoc development are available for the Macintosh platform.

Tools for OpenDoc Development Page 19 Developing OpenDoc Component Software for Macintosh Systems: How to Start Today

Developers interested in starting OpenDoc development on the Macintosh platform can immediately choose either of two paths: ¥ Programming directly to the OpenDoc API, or ¥ Using an object-oriented framework that hides most of the OpenDoc API details These options are similar to those that developers face when creating traditional Macintosh or Windows applications. They can program directly to the platform API (Macintosh Toolbox or Windows API) or they can use a framework (MacApp for Macintosh or Foundation Class Library for Windows). Even when developers use a framework, it is important for them to know the basics of the platform API in order to understand what is happening behind the scenes. For example, in the case of Macintosh programming, developers who want to use MacApp should spend some time understanding how functions such as the Event Loop, the Event Manager, and the Menu Manager work so that they can use MacApp more effectively. In the case of OpenDoc, Apple suggests that developers start by programming to the OpenDoc API. This can be done by taking one of the sample components provided as part of the OpenDoc DR releases and experimenting with it (looking at the code, navigating through it, compiling and running it to see its behavior). Once the basics of OpenDoc development are understood, developers can start creating their own components. At this point there are a few options: ¥ Use a framework such as ODF ¥ Use CA Lib or MacApp 3.5 to add container capabilities to existing applications ¥ Continue developing components by programming directly to the OpenDoc API Each option has its advantages, and the final decision depends on developer preferences, company policies, the needs of specific applications, and so on. For developers who plan to develop a cross-platform Macintosh and Windows part, the best option is ODF. This document has described a number of tools available today for OpenDoc development. Apple and other Macintosh development tool vendors are working quickly to release the OpenDoc tools that all types of developers need.

Tools for OpenDoc Development Page 20 Why You Should Develop for OpenDoc

¥ OpenDoc is a cross-platform standard for software integration that enables the development of cross-platform component software. ¥ OpenDoc has strong industry support from companies such as Apple, IBM, Novell, and other CI Labs members. ¥ OpenDoc exists, it is stable, and you can start development with it today. ¥ OpenDoc provides interoperability with OLE. ¥ OpenDoc tools are available from many different vendors to satisfy the needs of different developer and customer segments. ¥ OpenDoc changes and redefines the dynamics and economics of software development. It will result in better solutions developed and deployed in less time, benefiting developers and users alike. For developers, OpenDoc presents a strong business opportunity.

Tools for OpenDoc Development Page 21 Contact Information

APPLE COMPUTER, INC. 1 Infinite Loop, MS 303-2E Cupertino, CA 95014, USA Internet: @applelink.apple.com

COMPONENT INTEGRATION LABORATORIES, INC. (CI LABS) P.O. Box 61747 Sunnyvale, CA 94088-1747, USA Internet: [email protected]

HEIZER SOFTWARE PO Box 232019 Pleasant Hill, CA 94523, USA Internet: [email protected]

IBM CORP. 11400 Burnett Road, MS 1002 Austin, TX 78758, USA Internet: opendoc@austin..com

METROWERKS, INC. 8920 Business Park Dr., Suite 315 Austin, TX 78759, USA Internet: [email protected]

NOVELL INC. 122 East 1700 South Provo, UT 84606, USA Internet: opendoc@.com

ORACLE CORP. 500 Oracle Pkwy. Redwood Shores, CA 94065, USA

PICTORIUS INCORPORATED 2745 Dutch Village Road Halifax, Novia Scotia V3C 4G7 Canada Internet: [email protected]

QUASAR KNOWLEDGE SYSTEMS 9818 Parkwood Drive Bethesda, MA 20814, USA Internet: [email protected]

Tools for OpenDoc Development Page 22 SYMANTEC CORP. 10201 Torre Ave. Cupertino, CA 95014, USA

Tools for OpenDoc Development Page 23  1995 Apple Computer, Inc. All rights reserved. Apple, the Apple logo, APDA, AppleTalk, HyperCard, Mac, MacApp, MPW, and Macintosh are registered trademarks of Apple Computer, Inc. AppleScript, Bento, Mac OS, OpenDoc, Power Macintosh, and ResEdit are trademarks of Apple Computer, Inc. PowerPC is a trademark of International Business Machines Corporation, used under license therefrom. All other trademarks are the property of their respective owners. Mention of non-Apple products in for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these products. All understandings, agreements or warranties, if any, take place between the vendors and the prospective users. April 1995.