Portability

The objective of this section is to describe the problems which can arise in writing portable high-level language programs and suggest how non-portable parts of a program may be isolated. The section is also concerned with software reuse. The advantages and disadvantages of reuse are discussed and guidelines given as to how reusable abstract data types can be designed.

Software portability
([Brown 1977], [Tanenbaum et al. 1978], [Wallis 1982], [Nissen 1985]).

• Can be achieved by one machine on another using microcode, compiling a program into some abstract machine language then implementing that abstract machine on a variety of computers, and using preprocessors to translate from one dialect of a programming language to another.
• A characteristic of a portable program is that it is self-contained. The program should not rely on the existence of external agents to supply required functions.
• In practice, complete self-containment is almost impossible to achieve and the programmer intending to produce a portable program must compromise by isolating necessary references to the external environment. When that external environment is changed those dependent parts of the program can be identified and modified.
• Even when a standard, widely implemented, high-level language is used for programming, it is difficult to construct a program of any size without some machine dependencies. These dependencies arise because feature of the machine and its operating system. Even the character set available on different machines may not be identical, with the result that programs written using one character set must be edited to reflect the alternative character set.
• Portability problems that arise when a standard high-level language is used can be classified under two headings:

1. problems caused by language features influenced by the machine architecture, and
2. problems caused by operating system dependencies.

These problems can be minimized, however, by making use of abstract data types and by ensuring that real-world entities are always modelled using such types rather than inbuilt program types.

• The general approach which should be adopted in building a portable system is to isolate those parts of the system which depend on the machine architecture and the operating system in a portability interface. All operations which make use of non-portable characteristics should go through this interface.
• The portability interface should be a set of abstract data types or objects which encapsulate the non-portable features and which hide any representation characteristics from the client software. When the system is moved to some other hardware or operating system, only the portability interface need be rewritten to reimplement the software.
• The rate of change of computer hardware technology is so fast that computers become obsolete long before the programs that execute on these machines. It is therefore importanct that programs should be written so that they may be implemented under more than one computer operating system configuration. This is doubly important if a programming system is widely marketed as a product. The more machines on which a system is implemented, the greater the potential market for it.