Operating System Compatibility

Operating System Compatibility

What OS releases (OpenSolaris,Solaris, Windows NT, etc.) must the project run on or work with? If an unbundled product must run on down-rev releases (as well as up-rev), back-porting dependencies (or choosing alternatives) are important areas for concern.

Might the project need any extra adaptation to work successfully with future (i.e., later) releases of the OS or any other product? with patches? If so, that would indicate dependencies on interfaces with a lower stability classification than is desirable. (If the dependency is unavoidable, it will need ARC discussion and approval.)

Does the project use any system interfaces, commands, or features not in X/Open CAE, Issue 4, Version 2 (informally known as "Spec 1170" and XPG4.2)]? Such use would be possibly unstable dependencies. ABI Tools (appcert...) enable detection of such dependencies. Pointing out known nonstandard interfaces on which you depend allows you and your ARC case owner to search for a commitment level for them.

Developers of projects using system (or another project's) interfaces that are neither Standard nor Stable should explain to the ARC why the risks of being broken by an incompatible change are sufficiently low, and how that risk will be managed.

Assure that any dependency on kernel features not in the Solaris default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules) are necessary and appropriate.

To be ready for 64-bit Solaris, most Solaris projects should at least be 64-bit "clean". For C, you can use DevPro SC4.2 lint with -errchk=longptr64.

For Microsoft Windows libraries, identify for each component (EXE, DLL or VxD) the name of the component and the module identifier (EXE/DLL) or VxD ID (VxD). If a module provides a plug-compatible replacement for a standard system component, identify the component and its version. VxD IDs should be officially registered.