View source for IBM Developer API Extensions

''by [[David E. Reich]]''

At the IBM Technical Interchange in New Orleans in May, IBM announced the [[IBM Developer API Extensions for OS/2]]. It sounds pretty complex. It's not. In actuality, it is the first step towards what many developers crave: common source code for 32-bit OS/2 and Windows applications.

Traditionally, the biggest hurdle faced by developers is determining which platform(s) to support. Each requires its own business case as to why the company should invest its money in developing for a specific platform, whether it be OS/2, Windows in its various flavors, UNIX, Macintosh, or whatever other platform you might be contemplating. The picture becomes even more involved when you are your own small company, just trying to get off the ground. Wouldn't it be great if you could leverage that hard-earned code across more than one of these platforms?

There are, of course, objects as a choice. You could pick an object library and code to that, gaining that oft-mentioned reuse of object-oriented code, but alas, the tools to take you cross-platform are not quite there yet. This does not even take into account that most of the code out there today is procedural. Even if all the right tools were there, you might not be ready to completely rewrite for objects. What's a programmer to do?

Fear not, for here come the Developer API Extensions for OS/2. Well, they're not so grand as all that, but they are, nonetheless, significant in enabling multi-platform source code, and are a linchpin in the IBM strategy for multi-platform development.

==What Are These Extensions?==
Put simply, the Developer API Extensions for OS/2 are new APIs added to the operating system to provide, as the name implies, new programming interfaces. These interfaces are identical in interface to Win32 APIs. Over 700 APIs and 300 messages that correspond to those in the Win32 definition are being supported initially.

These APIs are not emulation. They are native OS/2 function, being built right into the operating system. Unlike previous attempts at "mapping" functions at run time, this is a source code solution that generates a native OS/2 application, with access to all of the features and functions afforded OS/2 applications, such as Workplace Shell functions and the [[System Object Model]] (SOM), among others.

The classes of APIs supported are:
* Common Dialogs such as Find and Replace, and Print
* Graphics Device Interface
* Window Management, including Multiple Document Interface (MDI) and Dynamic Data Exchange Management Library (DDEML)
* Other system services, including Date and Time, Environment, File Input/Output, Memory Management, Module Management, Printing, Processes and Threads, Registry, and Resource Management
You'll notice that there are functions here for threads, synchronization, DDEML, Registry, and many common dialogs, as well as commonly used system functions. The APIs being supported were derived by analyzing over 9 million lines of shipping Windows application code, along with input from ISVs, so the list is fairly well-rounded.

What these API extensions give you is the ability to compile Win32 code as native OS/2 code. In some cases, IBM just added a new entry point corresponding to Win32 syntax to an existing function where comparable function existed. In some cases, such as DDEML and common dialogs, IBM added new function. This benefits those who may be using the extensions to cross-compile Win32 code, as well as those writing native OS/2 code, as there are more functions now at your disposal.

[[Image:APIext-Fig-1.png|thumb|Figure 1. Common source code using Developer API Extensions]]
The way you use these API extensions is the same as any other API - you just call it. This approach presents some challenges in source code management, but after all, that is much cheaper than a rewrite. In ''Figure 1'', you can see the optimal way to structure your code, with the code common across platforms at the center, and the platform-specific code separate. By switching the headers and libraries, you can easily generate a functionally equivalent application on both platforms with little more than a recompile. Of course, there are some platform-specific functions that may not be duplicated from one application to the other, but the core of your application remains the same on both.

==Where's IBM Heading?==
As you can see, the Developer API Extensions are the common source code solution for procedural code. This is a solution that has two primary objectives (in no specific order):
*To get more applications onto OS/2. In the Win16 days, there was not much reason to write these API extensions because the API set was functionally deficient with respect to several of OS/2's main strengths, including multithreading and management of these threads. If developers can leverage their investment in Win32 code to create functionally equivalent native OS/2 applications at a small additional cost, OS/2 users will benefit.
*To help developers leverage application source code wherever they want to go. IBM is working to be an open systems provider and work with developers to create solutions that will work across a variety of products, both hardware and software. To that end, you have these APIs for procedural source code. IBM is also working with [[One Up Corporation]] to develop a User-Defined Migration Database (UDMD) for the [[Source Migration Analysis Reporting Toolset]] (SMART) that specifically covers the API extensions. Basically, when you run SMART against your code, you will have more API "hits" that are done for you by SMART than if the extensions were not there, making your movement to the various platforms even easier. (For more information on SMART, see the article titled "[[Migrating Your Source Code to OS/2 Warp, Part 2]]: User-Defined Migration Database Development" that appeared in Volume 7 of The Developer Connection News.)

No discussion of this ilk would be complete without talking about objects. This is the other part of the strategy, and also the answer to your OLE questions. If objects are your thing, the IBM [[Open Class Library]] (previously known as the IBM User Interface Class Libraries) is your common source code solution. The Open Class Library exists today for OS/2, and is on the horizon for Windows and other platforms. It offers a comprehensive set of classes - from basic input/output operations and string handling through abstract data types and user-interface support.

For application interoperability, you have [[OpenDoc]]. OpenDoc is available on OS/2, Windows, Macintosh, and other platforms. OpenDoc is technically more robust than OLE and has been made available to over 15,000 developers. It is also easier to code than OLE (many developers who've tried both already believe that). Best of all, OpenDoc runs on more than one platform! If it's the Windows 95 logo for the application that you're worried about, fear not. Microsoft has publicly stated that OpenDoc is acceptable for application interoperability to get the logo.

So if you want to maintain your investment in procedural code, the Developer API Extensions give you the multi-platform support you need. For those moving to or already into objects, IBM Open Class and OpenDoc are the answer. The goal is not to lock you in, but to free you to spend your development resources writing new functions that will make your product the best there is (rather than spend them on just getting to another platform and trying to keep the function consistent).

==We've Got You Covered==
These API extensions have some people concerned. I've heard, "Aren't you conceding the API to Microsoft now?" and, "You're lowering the cost of entry into the OS/2 market for my competitors," as well as, "I invested in OS/2 development all these years and only now you're doing this." As you might expect, there are answers for these concerns, and some may really open your eyes.

IBM is not conceding the API to Microsoft. It is a fact that currently there are more native Windows applications than OS/2 applications. Part of the reason (if not the primary reason) for the lack of native OS/2 development is not OS/2, but the fact that it is expensive to rewrite code. Even if you were to do that, multiple maintenance is also not a trivial issue. IBM analyzed the APIs developers were using and implemented them in OS/2 to significantly lower the cost of being a native application on OS/2.

Aside from lowering the programming costs, your product documentation costs can also be significantly lowered - if the applications use the same code and functions on multiple platforms, you only need to make minor changes to your books, if any at all. Taking this a step further, users will have an easier choice in establishing working environments if they already have your application but want to add systems with another operating platform (for example, if they have Windows systems and want to add OS/2 systems, but do not want to retrain users).

It is certainly true that with the extensions the entry cost for other vendors into the OS/2 market is lower. However, if OS/2 and your products are to thrive and survive, this is a necessary evil. You can draw many positive things from it. For example, if you have two source code bases already, it is now easier to merge them.

Another benefit of competition and IBM's desire to support developers is the new function being added to OS/2 as a result of the Developer API Extensions. New common dialogs, DDEML, and Registry functions are the most prominent. A complete list of the APIs, as well as the IBM common source code White Paper distributed at the Technical Interchange, is in the \PSCRIPT directory on disc 2 of your Developer Connection for OS/2 CD-ROMs.

In examining all of these issues, you must also consider that if you have been programming for OS/2, you are in a multitasking state of mind. You know threads and semaphores and have probably fallen into most of the traps people fall into when designing and writing multithreaded code. Developers just getting into Win32 and/or OS/2 with or without the API extensions have likely not dealt with any of this before - you have a significant head start on them in terms of experience, regardless of the platform for which you are developing.

==Conclusion==
The Developer API Extensions provide for cleaner code development, code leveraged across multiple platforms, and ultimately, a larger OS/2 and applications marketplace by making it easier and cheaper to create native OS/2 applications.

{{IBM-Reprint}}
[[Category:Developer Connection News Volume 8]]