Channels ▼
RSS

Open Source

Cross-Platform Database Programming

Source Code Accompanies This Article. Download It Now.


Here's how one developer supports more than 100 platforms

How many different combinations of operating systems and hardware platforms are used today? Fifty, a hundred--does anyone really know? How many are in the mainstream? DOS, Windows, NT, OS/2, Solaris, UNIX--Intel, Motorola, DEC, SunSPARC, IBM. With all of these choices, how are you to develop truly portable applications?

The good news is that if an application is approached correctly and with foresight, writing portable code does not have to be a chore. In this article, we'll discuss coding strategies for developing truly portable database applications. In doing so, we'll focus on the strategies you can implement to ease the movement of code and data between computer platforms. The topics include code portability, function wrappers, size and alignment of data objects, binary word order, and true multiplatform portability. All of the techniques we'll cover here are real world--they're what FairCom uses to make its c-tree Plus File Handler highly portable. c-tree Plus is a C-function library of database calls designed from the ground up with portability in mind. The c-tree family has been ported to well over 100 platforms ranging from Cray supercomputers to embedded systems and virtually all machines in between.

Code Portability

The way you organize modules which comprise your application can greatly affect the time required to port it. We suggest explicitly organizing your application modules into two sets: one that is system independent and one that is system dependent. For example, in c-tree Plus, about 98 percent of the code resides in system-independent modules which are not changed when we port from platform to platform. Not one line of code in these modules has to be touched. The remaining code--the system-dependent modules--contains those aspects of c-tree Plus which depend on system specifics. For c-tree, virtually all the system-specific code relates to low-level file operations.

To achieve this degree of separation, certain sections of a system-independent module may depend on a configuration setting in a system-dependent header file. However, these dependencies should reflect generic concepts, not platform-specific issues. In c-tree Plus for instance, there are #ifdefs in the system-independent modules which depend on the word order of binary values. Each system-dependent configuration header specifies the type of word order found on that platform; then the system-independent code need only have #ifdefs for the word-order choices, not for each platform.

To minimize unexpected problems when moving your C source code from one platform to another, it is advisable to utilize a well-defined set of typedefs for the basic computational objects as well as for application-specific objects. For example, in c-tree Plus we use three different typedefs for integers: COUNT, LONG, and NINT. They are, respectively, 2-byte integers, 4-byte integers, and the platform's natural integer. (Of course, we also support unsigned versions of these integers.) Then on any platform, c-tree can always rely on a COUNT to be two bytes and a LONG to be four bytes. This is implemented in a manner typical of our portability strategy: Default typedefs are supplied in a system-independent header module, and an optional entry in a system-dependent module can override the default. For example, default typedefs like Example 1 are found in a system-independent header file. In those few platforms where a short int is not two bytes or a long int is not four bytes, these typedefs can be specifically coded in the system-dependent header file, and the #ifndef will be false in the system-independent module.

Example 1: Default typedefs like this are found in a system-independent header file.

#ifndef INTEGER_OVERRIDE
  typedef short int COUNT;
  typedef long  int LONG;
#endif


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video