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.
Conclusion
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.
|
