Using one source code base to target multiple platforms is possible, but not ideal
David S. Linthicum
The four programmers draw their épées and simultaneously raise them to the sky. "All for one," they exclaim, "and one for all!" Such is the way of multiplatform development.
The ability to move an application from OS to OS, from GUI to GUI, and from processor to processor is a desirable, if elusive, goal. But the various environments in which we deploy applications have little in common, and environment-neutral development tools must create an additional layer to accommodate their differences. With this kind of architecture, it's difficult to expect excellence from a multiplatform application in all environments. Multiplatform applications are never a native, always a tourist.
"The problem
with portable tools is that they never look native in any environment," says Robert Holmes, computer technology research analyst with the Southern California Gas Company (Los Angeles, CA). "They [tools vendors] simply can't be all things to all environments." Simply put, you pay your money and you make your choice: separate development for each platform, or multiplatform development only once.
As the cost of applications development rises, it makes sense to develop applications that run on a multitude of platforms. This allows companies to leverage their investment in code and more easily adjust to the inevitable technological changes. In addition, if you're marketing your applications, the more platforms they run on, the merrier your accountants will be.
Many tools vendors, including Compuware, Intersolv, Neuron Data, Unify, and Zinc Software, provide facilities for multiplatform development. When using these tools, developers can write an application once and then deploy it into many environment
s without modifying the programming code.
The trick for the developer is to find a tool that makes the application look at home no matter where it is. Some of the issues surrounding multiplatform development include approaches to portability, business justifications, pitfalls, tools, and how to win the portability game.
Desperately Seeking Portability
The idea of portability is conceptually simple: Keep the environment-specific code in its own layer. Then, when you move an application from platform to platform, simply swap out the old environment layer and swap in a new one.
For example, when developing a C++ application for portability, the developer places all the native GUI- and OS-specific code in its own object or group of objects. Then, when moving the application from platform to platform, the developer must replace just the native-object layer to redeploy the application in a new environment.
Most developers find that achieving true portability using tr
aditional programming techniques is an arduous task. But a number of portable class libraries (e.g., C++ Views from Intersolv, zApp from Inmark Development, and Zinc from Zinc Software) and fourth-generation-language (4GL) tools (e.g., C/S Elements from Neuron Data, Uniface from Compuware,
Unify Vision from Unify
, and VisualWorks from Digitalk/ParcPlace) are available to make the job much easier.
These tools provide a layered API framework. At some layer of this framework, the tools maintain the environment-specific code. Developers then build applications on top of the environment-specific layer.
By using proprietary API calls from third-generation-language (3GL) code, developers don't have to deal with the differences between native environments. The API provides a consistent set of available functions from compiler to compiler and from platform to platform to enable normal applications operations. It's the job of the tool, not the programmer, to handle the presentation of the
application in the various environments supported by the portable development tool.
Although the basic concepts remain the same, there are many ways in which portable development tools approach the portability problem. These include lowest common denominator (LCD) and emulation. LCD tools (e.g., XVT from XVT Software) support those features found within all environments.
Yet to maintain portability, you have to give up some native application features. For example, LCD does not support nonportable features, such as Multiple Document Interface (MDI) for Windows applications or the geometry management found in Motif applications.
And while LCD provides the same look and feel across platforms, it doesn't consistently provide their
native
look and feel. For example, a Windows application built with an LCD tool looks out of place. But this can be an advantage. For instance, system administrators who manage many different types of systems may appreciate system-administration applications
that look the same across all platforms.
In contrast, portable development tools that use emulation (e.g., C/S Elements) draw their own GUI controls for each environment. These tools go directly to the graphics subsystems of each specific environment, avoiding the native APIs. Again, these applications never really look at home, and bypassing the native API can cause other problems.
For example, by the time this article sees print, many people will have already upgraded to Windows 95. But portable applications built with emulation-based tools in the Windows 3.1 environment probably won't find a happy home with Windows 95: These applications rudely bypass its Win16 and Win32 native APIs. Or, even if the application does run, it will have a Windows 3.1 look and feel in the Windows 95 environment.
To correct this problem, the developer must rebuild the portable application using a new Windows 95 version of the portable development tool. The same is true for other platforms as well.
So, w
hat's the best approach? It's no big surprise that the situation is not simply black and white. There are no clear differences between the LCD and emulation approaches to portable applications development when you consider the purchase of a portable development tool. In fact, most tools fall somewhere between the two approaches (e.g., XVT is more LCD, while C/S Elements is more emulation), and the only way to determine the efficiency of a portable tool's approach is to test it in the environments where you wish to deploy it.
But don't abandon all hope. There could be good news on the horizon for portable applications developers. As portable-tools vendors, such as Intersolv, work to improve their products, there seems to be a movement toward using more of the native APIs when deploying portable applications. This will eliminate many of the drawbacks of using
portable development tools
by making portable applications indistinguishable from native applications.
Thus, many tools, su
ch as Intersolv's C++/Views, are moving to a
superset
approach to portability. Using this approach, portable tools build as many native functions as they can into portable applications. If any native functions are missing, the tools emulate the missing features. The resulting applications should provide all the native features you need while remaining completely portable. But using the native API makes a portable-tool vendor's job much more complicated, and it's going to take time before most tools move in the native direction.
Tools That Rule
Developers can divide portable tools into 3GLs and 4GLs. If you decide to go the 3GL route, you'll find a number of portable C++ libraries, including zApp, Zinc, and C++/Views. The basic idea behind these tools is that C++ developers will use these frameworks, which leverage the object-oriented aspects of C++, and place environment-specific code in their own libraries. Thus, when you switch platforms, you switch libraries as well.
Using portable C++ libraries, an application can
access all OS and GUI services
using the proprietary API of the tool, which in turn implements the proprietary API call using environment-specific calls. Since the tool API never changes from platform to platform, the applications are portable. You can, as an option, put environment-specific calls in your application using these portable frameworks. However, you'll have to either remove or work around those calls to make your application portable to other platforms.
As with any 3GL, developing portable applications using C++ takes a great deal of time and patience. To build portable applications in less time, you should consider portable 4GL development environments. Instead of using a proprietary API, 4GL tools provide a high-level language across platforms.
Examples of portable 4GL tools include C/S Elements, Uniface, and Unify. These tools use proprietary 4GL languages that sit on top of the environment-specific featur
es of the tool. Uniface, for example, can deploy its 4GL applications on Windows, OS/2, Windows NT, Unix, and the Mac.
When selecting a portable 4GL tool, you should consider its ability to handle other application services, such as database-server connections, and its ability to assist in the development of a database schema. Many of these tools, such as Uniface and Unify, make good rapid-application-development (RAD) tools as well.
One drawback of portable 4GL tools is that they almost always use an interpreter, and therefore their performance is usually lackluster. With 3GL and 4GL tools, you need to check with the applications vendor to see if they support all the environments you plan to deploy applications on. Many tools support only a select few, or they support only one or two very well, while supporting others poorly.
Portable Traps
Despite the drawbacks, the allure of portability is just too strong for many organizations to resist. Most companies run a wide
range of processors, OSes, and GUIs, and having to write an application just once for all those environments solves many problems. However, portability creates other problems. Failed portable applications development projects outnumber successful implementations, and it's clear that the honeymoon with portable applications development tools is over.
The problem with building portable applications is traceable to the differences among platforms. Like "one-size-fits-none" gloves, portable development tools can't be all things to all platforms; therefore, they don't work exceptionally well on any of them. Most users can instantly discern a portable application from a native one and reject it as seemingly out of place.
For example, zApp, a useful portable C++ library that allows developers to deploy applications on Windows, Unix, Windows NT, OS/2, and Macintosh environments, looks a lot like a native Windows application no matter what platform you deploy it on. A developer may get away with this with
Windows users, but not with anyone else.
Look and feel aside, when you use portable tools you have to give up other native goodies as well. Portable development tools that support Windows, for instance, might not have the mechanisms to use OLE 2.0 objects, Visual Basic custom controls (VBXes), or MDI. Moreover, they might make it difficult -- or impossible -- to use other third-party development tools and libraries.
Other issues are cost and performance. Most portable applications don't run as fast as native applications do, because of the overhead of using a native layer. In addition, portable development tools add significant cost to development projects, usually doubling the tool cost. You also need to consider staffing costs as well. Portable applications, especially in the 3GL world, take more time to develop, and their learning curve is steep.
Unarrested Development
Before jumping into portable applications development, take a deep breath and consider whether
you really need to do so. Although vendors' sales pitches are compelling, if you don't have an immediate need to deploy applications on multiple environments, just say no. Multiplatform development adds both cost and trouble to the development life cycle. It's much easier to build native applications, and users are happier with them.
What if you decide to go native and get an unexpected demand to run your application on a different platform? The good news is that you can rebuild your application around a portable tool that handles the new platform. The bad news is that it requires a lot of additional work.
If portable applications development makes sense for your application, you need to consider the type of tools to use. While multiplatform development frameworks for C++ are flexible, they're difficult to learn and use. Moreover, it takes more time to build an application using a 3GL, such as C++, than it does with a 4GL.
Portable tools that use 4GLs offer an easier development environment,
but -- in support of the you-can't-have-everything theory -- you might run into performance problems. For each type of tool, you always need to consider the OSes and GUIs that each works on. You probably want to set up pilot applications on all the platforms you're supporting as well. Never assume that your portable application will work the same across all platforms. Developers are often unpleasantly surprised at how widely tools-vendor support varies from platform to platform.
If you want to put advanced GUI features in your portable application, such as MDI, OLE, DDE, and Motif geometry, then make sure the tools support them. If you plan to use graphics, make sure the tools can display and print the graphics for your application on each platform.
You need to look at other details as well. For example, some portable applications development tools don't use the native help systems or the native help file; others don't use native fonts or bit maps. As always, it's caveat emptor.
Finally, wh
en considering getting into the portable applications development game, use common sense. Determine your application requirements and platform requirements up front. Next, research the different portable development tools and select the ones that meet your requirements. From there, test each tool to determine its viability. Don't be afraid to dump a tool if it doesn't meet your expectations.
While portable applications development has many advantages in today's heterogeneous world, there are many trade-offs to consider when selecting a portable development environment. As tools vendors become better at building portable development environments, someday maybe all development tools will provide portability, settling all the problems once and for all.
WHERE TO FIND
Compuware Corp.
Farmington Hills, MI
(800) 368-4326
(810) 737-7300
fax: (810) 737-7199
Digitalk/ParcPlace
(companies are mergi
ng)
Santa Ana, CA
(800) 759-7272
(408) 773-7514
fax: (408) 481-9095
sales@parcplace.com
http://www.parcplace.com
Inmark Development Corp.
Mountain View, CA
(800) 346-6275
(415) 691-9000
fax: (415) 691-9099
Intersolv, Inc.
Rockville, MD
(800) 547-4000
(301) 838-5000
fax: (301) 838-5432
http://www.intersolv.com
JYACC, Inc.
New York, NY
(800) 458-3313
(212) 267-7722
fax: (212) 608-6753
jazzin@jyacc.com
http://www.jyacc.com
Neuron Data, Inc.
Palo Alto, CA
(800) 876-4900
(415) 321-4488
fax: (415) 321-3728
Unify Corp.
Sacramento, CA
(800) 864-3948
(916) 928-6400
fax: (916) 928-6406
XVT Software, Inc.
Boulder, CO
(800) 67
8-7988
(303) 443-4223
fax: (303) 443-0969
Zinc Software
Pleasant Grove, UT
(800) 683-8665
(801) 785-8900
fax: (801) 785-8996
info@zinc.com
http://www.zinc.com
illustration_link (12 Kbytes)
In one style of access (left), the development tool translates 4GL references into native calls. In another style, the tool supplies a proprietary API to which developers write code.
screen_link (71 Kbytes)
Unify's Vision provides multiplatform rapid application development for the
Macintosh (a)
,
Windows NT (b)
,
Windows (c)
, and
Unix (d)
. Vision's automated application-partitioning feature allows developers to partition applications across various applications servers.
screen_link (43 Kbytes)
JYACC's Jam 7 is a multiplatform client/server applications development tool. Jam 7 applications are portable to (from top to bottom) the Mac, Windows, and Unix, plus other OSes.
David S. Linthicum is a technical manager with EDS in Falls Church, Virginia. You can reach him at
70742.3165@compuserve.com
or on BIX c/o "editors."
And One for All
