d, you must grapple with a host of new cross-platform-development problems, such as how to maintain code and resolve word- and bit-ordering issues.
If you develop applications that straddle the Unix and Windows wall, you face challenges and opportunities in spades. But the problems are by no means insurmountable. You have two main roads to take: Follow the roll-your-own approach, or take advantage of one of the many development tools designed for producing portable applications. Each alternative has its trade-offs. Here's how to make your choice.
Roll Your Own?
The courageous programmer may eschew commercial development tools when writing portable Unix and Windows applications because it looks like a way to save money. Also, you can in effect write your own applications-development environment by establishing common support routines across both platforms and writing to them. You gain control over the cross-platform layer
, which is important if you have stringent requirements that can't be met by a cross-platform-development tool.
But think long and hard before going the roll-your-own route. It's a rare occasion when you need such stringent control over the cross-platform layer that you need to create your own development environment. Also, almost all programs grow beyond their initial intended use and environment. What was eminently doable for the accounting department may quickly become insupportable when the CEO tells you to deploy it across the entire corporation.
What deployment problems might you face? Most important, there's scalability. The design choices you make for a low-volume server will probably be different when you expand the program for a high-volume server. You can often use third-party tools to deal with these divergent requirements. But if you've rolled your own application, you may have to start the development process from scratch before you redeploy the application. In addition, most third
-party tools support nearly every OS and hardware platform you can imagine.
This laundry list of problems may quickly convince you to invest in a third-party tool. But your decisions don't stop there. There are dozens of tools to choose from. The following three scenarios will put your choices into perspective.
SCENARIO #1: Down and dirty.
Problem: You need to develop cross-platform applications under a tight tool budget, and you have few programming resources to spare.
Solutions: Platform emulators require the least effort for programmers because emulators don't involve development. Emulators mirror the environment of one OS on another platform. Examples include Insignia Solutions' SoftWindows ($499) and SunSoft's Wabi ($225).
While programmers don't have to spend any development resources, they do have to accept some significant trade-offs with emulators. Performance often takes a substantial hit. The extent is hard to gauge because you're running on differen
t hardware, but the hit can range from almost nil (if you're running Solaris on an Intel box) to up to 16 times as slow (if you're running Solaris on a SparcStation). In addition, Unix users have to accept using Windows applications with a non-Motif appearance and behavior.
Another simple approach is to deploy X Window System server software on Windows desktops. This works if all you need to do is run X client applications over a network. In common with using emulators, this alternative keeps you from having to write code, but you're limited to running in the X environment.
SCENARIO #2: Built for speed, not for comfort.
Problem: Your need for fast, quickly developed applications overrides concerns about code maintenance and user-interface (UI) transparency.
Solutions: You can create applications with native performance by running the source code through a translator to prepare it for the target platform. One example of a translator is Thomson Software Products' TeleUs
e/Win16. It takes C source code that uses the Motif GUI on Unix and translates it to C++ code using Microsoft Foundation Classes (MFC), which you can then compile under Visual C++ on the Windows platform.
The primary drawback of such a tool is that once you've translated your Motif source, you now have two sets of source code to maintain. That's because a translator literally takes your source code and modifies the calls to the API to use a new set of calls. But you've still got your original source code using the other API.
TeleUse/Win16's translation is also less than perfect; the resulting Windows application still has a lingering Motif look and feel. Thomson's companion product, TeleUse/Win32, takes a Motif application that you developed with Thomson's TeleUse UI management system and generates a Windows NT executable file. However, this makes software maintenance a problem from that point on.
Other types of products provide an API that you can write to, or they provide emulation of a
n existing API (e.g., a Windows API). Willows Software offers the Twin XPDK, a cross-platform developers kit with libraries, header files, and the like, to support the Windows API on Unix platforms. The company's strategy -- like that of many other companies -- is that Microsoft is so influential we should all be writing to the Windows API, no matter what platform we're on.
Bristol Technology takes a similar approach. The most recent version of
its Wind/U toolkit for
porting Windows applications to Unix systems includes support for MFC 4.0, OLE 2.0 objects, and Windows 95. The OLE support is only partial, however, and currently accommodates only the OLE Common Object Model (COM). Support for OLE automation and OLE custom controls (OCXes) should appear in this quarter.
Mainsoft's MainWin Cross-Development Kit is in the same vein as the Willows and Bristol products. It lets you compile Windows applications on Unix platforms, and the resulting Unix application can run with eithe
r the original Windows look and feel or the Motif look and feel. End users can choose the look at run time.
SCENARIO #3: Point me uptown.
Problem: You need fast, low-maintenance code within a client/server foundation -- at any cost.
Solutions: The most complex class of tools, cross-platform-development environments can help you design a GUI application and, in some cases, compile and test the software for you. These development tools have the advantage of leaving you with a single set of source code to compile for each target platform. If you decide to use a third-party cross-platform-development tool or environment, select one that not only supports Windows and the Unix flavors you use today, but one that will work for the applications you might need to support in the future.
How do you make your decision? Be prepared to face many cross-platform applications-development environments and tools. They include XVT Development Solution for C++ from XVT Software, Forte Sof
tware's Forte, Zinc Software's Zinc Application Framework, WNDX's WNDX GUI Development System, Liant Software's C++/Views, and Inmark Development's zApp Developers Suite.
Also part of this
group is OpenUI.
One promising development is Open Software Associates' announcement of OpenWeb, an enhancement to OpenUI due this quarter. It will let you deploy client/server applications over the World Wide Web.
To make your decision even more difficult, most client/server applications-development environments provide rich cross-platform applications-building support within their charter of client/server development. Although such client/server tools require substantial investments of money, time, and expertise, most critical corporate applications will head down the client/server road at some point. Many client/server applications-development environments focus on database design and deployment. Examples include Compuware's Uniface, PowerBuilder from Powersoft, C/S Elements from Neuron
Data, and Oracle's Cooperative Development Environment.
JAM, from JYACC, and Blyth Software's Omnis 7 are also mainly directed at the development of database applications. They support a wide variety of DBMSes on both Windows and Unix.
Stumbling Blocks
Even the best tools don't automatically create super applications. That's because a custom application that is critical enough for you to deploy on multiple platforms will likely require significant interaction with a variety of windowing systems, databases, or other servers. Maintaining a single code base for a cross-platform application with such complex interactions will be one of your biggest challenges.
One of the most critical design steps you'll take centers on partitioning modules into platform-independent and platform-dependent entities. Platform-independent modules shouldn't require any changes to compile on the target platform. Note, of course, that platform-independent modules may still have separate section
s that are dependent on general characteristics of the target platform (e.g., word size or byte ordering).
Platform-dependent modules, on the other hand, directly call platform-specific services, such as file I/O, database access, and GUI control. In general, platform-independent modules will comprise the great majority of your code.
By building modules that provide platform-dependent services to platform-independent modules, you have created your own (and usually small) cross-platform applications-development environment.
You should also strongly consider using function wrappers to isolate your platform-independent code from platform-dependent code, even if you've created the code from scratch or by using a third-party tool. Wrappers save work when you make subsequent changes to your platform-dependent modules because you write your own API instead of writing directly to a third-party API.
Further complications when writing across Windows and Unix environments are data size, data
alignment, and word ordering. These issues come into play when you're porting an application between Windows and Unix or when you're developing client/server applications that must work on the two platforms.
You cannot make assumptions regarding data size on each target platform because, for example, an integer may well be 4 bytes on one hardware platform and 8 bytes on another platform. Assuming you're programming in C or C++, platform-independent modules need to rely on platform-dependent header files to set up correct data types.
Data alignment can be a problem if you make assumptions about data storage that fail to take into account hardware architecture alignment requirements and the padding that a compiler might insert to conform to those requirements.
Word (and bit) ordering is critical because the Windows/Intel platform is little-endian (i.e., lowest-order byte stored first), and many Unix platforms are big-endian (i.e., highest-order byte stored first).
Things go wrong if
you make incorrect assumptions about how values are stored internally. If you treat an integer only as an integer and don't try to cast it as something else (e.g., an array of bytes or an array of characters), you're fine. But if you try to use that same storage differently than you declared it and you make assumptions about how data is stored, you're in trouble. For example, assume a little-endian machine on which an integer is 4 bytes, and you stored x01020304 in an integer a and then a[0]=x04, a[1]=x03, and so forth. On a big-endian machine, it would be a[0]=x01, a[1]=x02, and so forth.
Keep in mind that you may need to write to the lowest common denominator for each platform to avoid some window controls in Windows that aren't available on a particular flavor of Unix. Similarly, you may use a less-than-ideal database because it's available on the platforms you need. Once again, this problem argues for the use of third-party tools, which have varying levels of support for platform-specific features.
However, end users will rightly expect the application to behave as a native application. Therefore, when you evaluate third-party tools, make sure that they can help you produce target-platform applications that not only look but behave like a native application developed solely for that platform.
Once you've ironed out the many development issues related to creating cross-platform applications, you'll face one more hurdle: how to test the program. It is awkward, inconvenient, and inefficient to use different software quality-assurance tools on Unix and Windows platforms. Fortunately, several products -- such as QA Partner from Segue Software and WinRunner and Xrunner from Mercury Interactive -- provide common services on both platforms. In fact, these products usually let you use the same test scripts across both Windows and Unix.
No Panaceas
There are many third-party tools and environments you can effectively leverage in a cross-platform-development effort. But n
o matter how sophisticated a tool is, it won't replace the most critical element of all: careful programming techniques.
WHERE TO FIND
Bristol Technology, Inc.
Ridgefield, CT
(203) 438-6969
fax: (203) 438-5013
http://www.bristol.com
Windows Without Walls
