James D. Mooney’s research while affiliated with West Virginia University and other places

Software portability is often cited as desirable, but rarely receives systematic attention in the software development process. With the growing diversity of computing platforms, it is increasingly likely that software of all types may need to migrate to a variety of environments and platforms over its lifetime. This tutorial is intended to show the reader how to design portability into software projects, and how to port software when required. Full Text at Springer, may require registration or fee

Portability is clearly a form of reusability, but the problem of enhancing and supporting portability raises problems which are not often addressed by reuse research. Portability is typically concerned with the reuse of complete applications on new platforms, while reuse research has typically concentrated on building and maintaining collections of reusable components or similar artifacts, and reusing them effectively in new applications. This paper reviews and compares current issues in reuse research and portability research. Although the dominant problems for the two research domains are distinct, the goal is to identify some common areas where both domains may benefit from continuing research. Several common areas are identified. These include classification, specification and measurement, validation and verification, software process issues, and management issues. The problem of integrating portability into the software development process is briefly considered. Benefits may be anticipated from integration of both portability and reuse. It appears, however, that integration of portability may be more easily accomplished, yet harder to justify to management.

This paper describes an experimental course on the topic of software portability, and initial experience in teaching this course. With the continuing proliferation of both applications and computing environments, the need for portability is being increasingly recognized. A large proportion of the software now being developed will eventually need to be ported to new environments. Yet this topic is missing from most computer science and software engineering curricula. The course described here was designed to explore practical issues in the development of portable software. Lectures and discussions on portability topics are combined with the ongoing development of a simple software project designed to expose a variety of portability problems. During the course the project is ported to several environments and redesigned to improve its portability. This course has been taught experimentally with encouraging results. Student assignments have used novel and effective methods to overcome portability barriers. Feedback from student indicates that they have become more aware of portability issues to be considered in software development, and have gained experience with system interface issues in several programming environments.

A range of system-design strategies that can be used to support portability and the ways in which these strategies have been employed by past and present systems are examined. The strategies are grouped into three categories: (1) strategies that maintain identical execution-time interfaces by porting system components that form the interface, (2) strategies that maintain identical or nearly identical interfaces for different system components by adhering to appropriate standards, and (3) strategies that assist in the adaptation of programs to a target environment. The principal emphasis is on operating-system issues. User interface portability, dynamic portability in a network, and international exchange of programs are briefly considered.< >

This paper considers some problems which may arise in the quest for software portability, especially those relating to the system interface, and evaluates the CTRON specification to determine if these problems may be avoided. The literature on portability is reviewed, especially case studies describing porting experience. The portability-related tasks performed by several classes of software developers and implementors are examined. These considerations lead to identification of four potential problem areas: subsets, specification level, range and performance guarantees, and language bindings. The CTRON specification is then examined in relation to these problem areas, and several recommendations are stated.

Unlike other TRON software components, CTRON is designed to run on various CPU architectures, including existing, large-scale computers as well as microprocessors. It is expected that various implementations of CTRON should provide common support for suitable applications in spite of differences in software and hardware architecture. Thus CTRON may be viewed as a standard for an interface between operating systems and applications, and between operating systems and CPU architectures. Such a standard must be robust, to be useable in many different environments. It also should be in harmony with other standards that may exist for similar or related elements of the distributed system which TRON envisions. This paper reviews some principal interfaces that exist in a typical computing system and significant formal and de facto standards for these interfaces, and examines CTRON’s role among these standards. The review is based on experience in the development of the IEEE MOSI standard, which has many similarities with CTRON, and on an ongoing study of CTRON itself. Based on this review, some suggestions are offered for the fine tuning and evolution of CTRON, which may help the specification to best fulfill its intended purposes.

Some lessons are derived from experience in the development of a software interface standard, IEEE Trial Use Std-855 for Microprocessor Operating System Interfaces (MOSI). This experience has led to the formulation of some useful guidelines which were not necessarily evident from the start. The major observation concerns the importance of careful consideration of the objectives, proper scope, existing models, and expected usage, of the planned standard. This process helps in making the right decisions on what should be standardized. A number of specific guidelines based on these principles are discussed.

This paper presents the design goals and architecture of the Modular Formatting System, currently being developed at West Virginia University. MFS applies to formatters the principles of separation of function used in many successful program systems. A small central kernel forms the basis for a family of formatting systems, tailored to specific applications and environments. MFS is intended to support a wide spectrum of applications drawn from the experience of commercial composition, word processing, and research systems. It does not rely on any specialized terminal or input source characteristics. Output devices from line printers through high resolution typesetters are handled in a uniform manner. Users can exercise detailed control over document appearance, or work exclusively with styles predefined through macros.

This paper proposes a control mechanism for the user interface. This mechanism provides two principal services of frequent importance in interactive systems: management of alternate file input, and log files. The mechanism is independent of the command language interpreter and thus its services are available to all programs.