Contact Site Map


[Engineering Discipline]
[Software Porting Primer]


Search For:

The Software Porting Primer

By Jeff Moskow, Ready-to-Run Software, Inc.

  This paper gives the reader a basic understanding of software porting.  In it we review the significant issues involved in the development of portable software and in porting existing software to new platforms and computing environments.


 Market Profile

In order for any company to achieve its objectives, it is critical that it fully comprehend the composition and the potential of the target market.  The computing marketplace has a number of distinct segments. It is difficult for most software providers to sell to the broad marketplace without acknowledging and addressing the heterogeneous nature of that marketplace.

 For the purpose of this paper, we divide the marketplace into four segments:

1.)      Desktop Computing Systems (dominated by Microsoft Windows)

2.)      Server Platforms (includes Unix, Linux, Windows/NT, Windows/2000, Netware, AS/400, etc.)

3.)      Personal Digital Assistants or PDAs (includes Palm Pilot, Windows/CE, Newton, etc.)

4.)      Embedded systems

 Some might also argue that web-based devices and the Internet comprise another major segment.  For the purposes of this paper, however, it is more useful to view the Internet and Web as a heterogeneous collection of various clients and servers.  In the context of porting, our concern is the migration of applications and databases across the four segments whether or not the facilitation or user interface is web-based.

 Few software providers will have to accommodate all four segments.  In fact, many will only need to address a single segment. Venturing into new segments requires a review of the providerís capabilities and infrastructure and can necessitate significant investment.  However, we project that as the industry matures, customers will begin to demand functionality on a variety of computing platforms and many vendors will be forced to respond Ė of course, the more proactive vendors will lead the expansion into these markets. 

 Today, more than ever, we are seeing software companies faced with the dilemma of how to satisfy a growing demand for multiple interfaces, that is, the customer requirement to execute applications or aggregate data for their desktop, their wireless handheld, their servers, and across the internet. The question of how best to address multiple platforms naturally leads to a discussion of porting. Porting is often the most viable path, and is sometimes the only path, available for software companies to adapt to the diversity of the computing environment. 


The Porting Framework

These days, almost all software is written in a "high level language". Some of the more common ones are JAVA, C, C++ and Visual Basic (sometimes referred simply as VB).  In this paper we won't begin to venture into the religious wars surrounding the merits of each language except to say that the choice of a language does have an impact on portability.  The four languages above are listed in approximate order of portability, but keep in mind that this in no way guarantees that every JAVA program will be more portable than every C, C++ or even VB program.  While many of the issues are generic, this paper will focus on porting in the context of software written in C and C++.

 First, letís examine the most elementary question: What is software porting?  Software porting is the engineering process of transforming an existing application so that the resulting software will execute properly on a new platform. The process involves the careful analysis, build, debug and test of the existing software to make sure that it will run reliably on the target.  Depending on the nature of the software and the source and destination platforms, this can be as simple as recompiling the code on a new system and verifying that everything works properly, or as complex as rewriting large sections of the application to accommodate the new platform.

 At the beginning of a port, a number of critical decisions must be made (or at least communicated), starting with the destination platform(s) and the overall goals.  For example, if the objective is simply to run a piece of software once (maybe you just need to run a conversion utility one time) then the performance and error handling will probably not be as critical. If, however, the goal is to ship thousands (if not millions) of copies of the software then special attention must be paid to issues such as performance, reliability, functional regression, etc.  The following questions are appropriate for consideration before starting a porting effort:

1.)      Who is the ultimate user of this software? Is this for production purposes?

2.)      Are there specific performance requirements?

3.)      Will we be continuing to support and enhance the software for the original platform?

4.)      Is the current user interface appropriate for the new platform?

5.)      Are the current installation kit and procedure appropriate for the new platform?

6.)      Are there any other platform specific functionality issues which will need to be addressed by the port (e.g. use of system error logging facilities, GUI libraries, etc.)?

7.)      What tools are available?  What tools will be used on the target platform?

8.)      Does the new platform have special features that we should exploit?

9.)      What is the timeframe for the project?

10.)  What test procedures are in place?  How will we know when the port is complete?

 Based on our experience, a "single source" methodology is almost always best.  In other words, the version of the source code that is built for platform "A" is the same source code that is used to build platform "B".  By writing portable code and using conditional compilation where necessary, this is often a very achievable goal that will make long-term maintenance and enhancement of the product much more practical.

 Once the target destination(s) have been determined and the goals have been specified, a porting project generally requires the following steps:

1.)      Analysis of existing code and/or architecture (scope definition)

2.)      Evaluation of available tool options (e.g. conversion libraries, emulators)

3.)      Design work for UI/functional changes

4.)      Implementation work for UI/functional changes

5.)      Build the software for the target platform

6.)      Debug on the target platform

7.)      Perform final test and Quality Assurance (QA) functions on the target platform

8.)      Integration of source patches back into the main build tree for archiving and revision control

9.)      Upgrade of documentation relative to the new platform


 Potential Porting Problems

No overview of porting would be complete without a discussion of the types of problems typically encountered in the porting process:

 1.)      There are invariably platform differences which are driven by the hardware.  Examples of these include word size (8/16/32/64 bit) and BIG ENDIAN/LITTLE ENDIAN (little endian is when the least significant byte is stored in the lowest address, big endian is when the most significant byte is stored in the lowest address).  Software engineers can get into all kinds of portability trouble when they make assumptions about ENDIAN-ness and word size.

 2.)      Most differences are Operating System (OS) dependent and can be as minor as having to use flock instead of lockf for file locking (note that they are not 100% interchangeable).  They can also be as major as having to rewrite an entire section of code that relies on shared memory for inter-process communication for an OS platform that does not support shared memory (or where its use has been rejected for political, performance, security, or other reasons).

 3.)      Differences in tools can sometimes contribute to the thrill of a porting project.  For example, switching from a compiler that "word aligns structure elements" to one that "byte aligns structure elements" might lead to a number of bugs as described below.  Or, switching to a compiler that now treats as a fatal error some code section which "only" generated a warning with the compiler on the original platform. 

4.)      BUGS!! There are many porting projects that have come to a screeching halt because of what we refer to as the "benign/malignant bug syndrome".  This is a situation in which a bug in the original source code is benign on the original platform(s) and yet is malignant on the destination platform(s). Consider, for example, the use of an un-initialized pointer which happens to point at an unused buffer on the original machine and points at the runtime stack on the target machine. 

5.)      Performance differences can be a real surprise.  In some situations, apparently identical services in two different operating systems services may be functionally equivalent but very different in performance or resource usage.  For example, the fork function on one system may use a copy-on-write algorithm, while on another it may immediately reserve swap space that might be needed later.



Porting your software to a new platform can be a cost effective way to expand market share.  Depending on the software in question and the destination platform(s), the process may be one that will take just a short time or can involve person-years of effort.  In either case, understanding the goals, the overall process and the possible pitfalls will help you to make informed decisions and set reasonable expectations. Donít undertake a porting project without a solid understanding of these management components or you could find yourself well behind schedule and beyond budget.  It is important to recognize that, fundamentally, software porting is as much an engineering process as any other software development effort.  By paying attention to these principles, you can increase your chances for success.


Jeff Moskow is the President of Ready-to-Run Software, the industry leader in software application and database porting.


©  April 2001.  All rights reserved.  Material cannot be reproduced without permission of Ready-to-Run Software, Inc.  Any reproduction, representation or use of the material provided herein without the prior knowledge and expressed written approval of Ready-to-Run Software, Inc. is prohibited.



Ready-to-Run Software, Inc. Privacy Statement

Email addresses listed on this site may  NOT be used for unsolicited commercial email.

© Ready-to-Run Software, Inc. 1996-2016