What are porting, integration, and compatibility?

Compatibility in UnixWare 7

In UnixWare 7, compatibility issues are divided into three general categories: ``application compatibility'', ``source compatibility'', and ``user interface compatibility''.

NOTE: This section defines these terms and what they mean for UnixWare 7. For a review of SCO OpenServer Release 5 and SCO UnixWare 2.1.X compatibility support in UnixWare 7, see:

See also:

Also see ``UnixWare standards conformance'' for a review of UnixWare 7 standards compliance.

``Application compatibility'' refers to the ability of the UnixWare 7 system to install and run applications compiled and packaged for other operating systems, particularly from SCO OpenServer Release 5.

An application's compiled ``binary executable'' (or, ``binary'') in UnixWare refers to a compiled object in ELF or COFF format. Binaries call library routines, system calls, driver IOCTLs, and, to a lesser extent, commands and system data files.

Thus, ``binary compatibility'', a term often used in the computer industry, means to bring these binaries unchanged over to UnixWare 7 and have them install and run.

However, the common definition of binary compatibility is too narrow to include everything an application might expect to be provided by a compatible operating system. So, we use the term ``application compatibility'' to include binary compatibility and other things that applications might need to run properly, such as shell scripts (that might be quite command intensive) and packaging, installation, and internationalization tools.

The idea of application compatibility is to take third party applications, install them (or simply copy them from a legacy machine), run them -- and they work properly. Application compatibility concerns propagating run-time interfaces that can be called or accessed by applications, or read by the kernel.

The goal for UnixWare 7 application compatibility is to get out-of-the-box, ready-to-run, legacy SCO OpenServer and UnixWare applications to run on UnixWare 7, without the installer or user having to do anything special to run the application.

For UnixWare 7, application compatibility encompasses examining, on each legacy system, the following system services and how they are used by applications:

program execution environment
supported system calls and dynamic libraries
command compatibility for shell scripts
packaging scripts, installation media, and packaging standards
drivers and kernel functions for drivers
files and directories commonly used by applications and the system
user interface libraries
major APIs (such as XTI and terminfo)
standards compliance
major third-party software packages required by the application

For UnixWare the goal is to guarantee application compatibility for any application that conforms to the following binary standards:

OSR5.0 ABI: The SCO OpenServer de facto ABI, with the exception of XENIX and SecureWare compatibility, which will not be provided.
SVID3: System V Interface Definition, Issue 3
ABI: System V Application Binary Interface Specification, 3rd. Ed.
iABI: System V ABI Intel Processor Supplement, 3rd. Ed.
iABI+: ABI+ for Intel Architectures Specification 3.0
iBCS2: Intel Binary Compatibility Specification, Version 2
ICCCM: The X Consortium's Inter-Client Communication Conventions Manual
Drivers: Drivers conforming to DDI version 5 or greater, SDI version 2 or greater, PDI, and DLPI interfaces will be binary compatible with UnixWare (see ``Developing device drivers'' for more information)

In addition, installation tools will support installing legacy applications from either product on UnixWare. All filesystems from either product will be supported. DTFS file system can be mounted read/write; HTFS file systems will be mountable read-only.

Notable exceptions include the XENIX file system type which will not be supported. Mass storage IOCTL compatibility from SCO OpenServer to UnixWare will not be provided.

While application compatibility sounds pretty comprehensive, some things that fall outside the definition of run-time interfaces need to be brought forward. These fall under the definitions of source and user interface compatibility:

``Source compatibility''

Source compatibility is concerned with the implementation of specific interfaces in libraries, header files, and the compiler. While binary compatibility focuses on getting the application to load and run on a new system, source compatibility is concerned with the ability to take the source code of the application, re-compile it on the new system, and have it work properly.

For UnixWare, the goal is to provide source compatibility for any application that conforms to the following source standards:

POSIX: Portable Operating System for UNIX (POSIX.1, POSIX.2 and POSIX.4)
UNIX^®95: X/Open UNIX 95 Brand (Single UNIX Specification)
XPG4: X/Open Portability Guide, Issue 4 Version 2
SVID3: System V Interface Definition, Issue 3
MDI: SCO OpenServer Release 5 network drivers that use MDI will be, where feasible, source compatible
NFB: SCO OpenServer Release 5 video drivers that use NFB will, where feasible, be source compatible

``UI compatibility''

While applications may depend on the existence of a particular user interface API, or the existence of a particular command, it is generally not desirable to complicate the entire user interface by supporting all known command or GUI client behavior. Commands used frequently in user scripts are likely candidates for compatibility work so that user scripts do not break. Maintaining compatibility for less-used commands or commands that are typically used interactively, however, is not a goal.

For UnixWare, user interface compatibility is not guaranteed for all legacy interfaces. The SCO UnixWare 1 and 2 Desktop, for example, is not supported in UnixWare 7.