The goal of binary compatibility is to allow applications created on earlier releases or technology levels to run unchanged and without recompilation on later releases or technology levels. The ability to run applications created on earlier versions of an operating system on a later level of the operating system is known in the IT industry as backward compatibility. Binary compatibility on any platform requires that the application use only portable programming techniques. A list of some non-portable programming techniques is detailed below.
AIX binary compatibility
AIX 6 is designed so that applications created on AIX 5L™ V5.1, V5.2, and V5.3 operating systems can be executed on AIX V6.1 without recompilation. AIX 6 is designed to support POWER4™, POWER5™, POWER6™, POWER7™ and PPC970 processor systems that implement the Power Architecture platform reference architecture.
Any program that must run in all processor environments supported by AIX 6 must be compiled using the common mode or PowerPC® option of the compiler. Programs that were compiled using the original POWER mode do not need to be recompiled to operate on the supported AIX 6 processors.
Historically, few clients or ISVs have reported binary compatibility issues when moving from one release of AIX 5L to the next. We anticipate similar results for the move to AIX 6.
All statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
Restrictions on AIX binary compatibility
As stated earlier, binary compatibility on any platform requires that application use only portable programming techniques such as only using published interfaces and avoiding programming techniques that are processor or AIX release specific.
AIX does not support the execution of binaries created on later releases or technology levels of AIX on an earlier release or technology level of AIX. For example, execution of binaries created on AIX V5.3 OS would not be supported on a system running AIX V5.1 OS.
Non-portable programming techniques
Some examples of non-portable programming techniques that may affect binary compatibility include:
- Applications compiled using a processor-specific compiler option but executed on models other than that processor
- Non-shared compiles of AIX-shared libraries
- Features explicitly described as non-portable by IBM in the AIX reference manuals
- 32-bit kernel extensions, or binaries which explicitly depend on a 32-bit kernel
- Undocumented AIX internal features
- X11R5 Server Extensions
- Locales based on IBM-850 code sets
- Legacy security library interfaces executing on AIX 6 systems with long usernames enabled
Applications running on AIX releases with long usernames enabled
The AIX 5.3 and AIX 6 operating systems can be configured to accommodate user and group names exceeding 8 characters. Applications which have not been specifically structured to handle long user and group names and which use legacy security library interfaces with 8-character name limits or which depend on user and group names not exceeding 8 characters in length may not work correctly on systems which have been enabled for long user and group names. AIX 5.3 and AIX 6 commands which display user and group names will truncate user and group names to 8 characters to accommodate existing use unless command-specific options are used to display long user and group names.
| Legacy Security Library Interface Long | Username-Enabled Alternative |
|---|---|
| ckuserID() | authenticatex() |
| cuserid() | getpwuid() |
| getuinfo() | getuinfox() |
| getuinfo_r() | getuinfox() |
| getuserpw() | getuserpwx() |
| newpass() | newpassx() |
| putuserpw() | putuserpwx() |
| putuserwhist() | putuserpwxhist() |
Systems running the AIX 5.3 or AIX 6 operating systems should not be configured for long usernames if those systems are running applications that use security library interfaces unless the applications have been tested for long username support.
X11R5/X11R6 compatibility issues on AIX Version 6
The AIX V6 X-server uses the X-Consortium release 6 of X (commonly known as X11R6). The libraries shipped by IBM with X11R6 are backward compatible and the client applications that access these libraries work as on AIX V4 and V5. As on AIX V4 and V5, IBM will also ship X11R3, X11R4, X11R5 compatibility installation options for maximum flexibility.
The majority of applications using X fall into this category and will not cause any difficulty. However, a small number of X-applications use the loadable extension facility provided by the X-server.
The X-server allows for the addition of new functionality through its extension mechanism. For each extension, part of the extension is loaded into the X-server before it can be executed. X11R6 has modified how this mechanism works in the course of improvements to X, and it is this part of the extension that must be made compatible with X11R6 to execute properly. All extensions supplied by IBM have been made compatible. In some circumstances, you may have an extension that does not work with X11R6; for example:
- Sample extension downloaded from the X-Consortium FTP site
- End user-developed extension
- Third-party extension
In these cases, the extension needs to be made compatible with X11R6 before it executes properly. End user-developed extensions and sample X consortium extensions need to be recompiled with the X11R6 environment. For third-party extensions, contact the vendor for a X11R6-compatible update.
If you use non-IBM display adapters, you may also be using vendor supplied software specific to those devices that uses X11R6 server capabilities. If so, this software must be compatible with X11R6 to operate properly. Contact the vendor of the display adapter for this software.
IBM plans to provide a porting guide with AIX V6 to assist clients and vendors who develop adapters or extensions for AIX.
32-bit device drivers and kernel extensions
Beginning with AIX 6, the AIX operating system will simplify its kernel environment by providing only the 64-bit kernel. AIX 6 will maintain application binary compatibility with previous AIX versions as specified above, but device drivers and kernel extensions that are 32-bit only will not be supported on AIX 6. Dual-mode (32/64 bit) kernel extensions built on AIX 5 will continue to run on AIX 6 but only in 64-bit mode.
Application binary compatibility for specific prior AIX releases
Applications from AIX 5L releases
AIX 6 is designed so that 32-bit and 64-bit applications created on the AIX 5L OS V5.1, V5.2, and V5.3 can be executed on AIX 6 without recompilation as long as those applications do not use non-portable programming techniques such as are listed above.
32-bit applications from AIX Version 4 releases
32-bit applications compiled on the AIX V4 OS can be executed on AIX 6 as long as those applications do not use non-portable programming techniques such as are listed above.
64-bit applications from AIX Version 4 releases
Any 64-bit applications compiled on the AIX V4 OS are not binary compatible with the AIX V5 or AIX 6 operating systems. AIX 5 and AIX 6 are source compatible with for 64-bit applications created on AIX V4. These applications need to be recompiled on a system running the AIX V5 or AIX 6 OS.
Applications from AIX Versions 3
32-bit applications created on AIX V3.2 or later AIX 3 releases can be executed on AIX 6 without recompilation.
Application binary compatibility for IBM i releases
IBM i maintains binary compatibility between its conversion releases. There have been three conversion releases in the system's history: V1R1M0 (1988), V3R6M0 (1995) and 6.1 (2008). For i 6.1, programs with constituent modules created for releases V5R1M0 and later can be converted automatically by the system. Programs created for releases V4R5M0 and earlier can also be converted unless their creation data has been removed. Programs that cannot be converted must be recompiled from source.
Beginning with 6.1, IBM i supports Adaptive Code Generation (ACG), which allows the latest hardware features to be utilized without recompilation and without loss of efficiency on older processors. Programs created or converted on a system with a POWER6 or POWER7 processor will automatically use certain new hardware features. If those programs are moved to a system running a POWER5 processor, they are automatically converted before they are run, so that they use only hardware features available on all supported processors.
Application binary compatibility for Linux releases
SLES10 SP3 supports POWER7 systems in POWER6 (compatibility) mode. SLES 11 supports POWER7 systems natively by default (POWER7 mode). Partitions migrating from POWER6 systems to POWER7 systems will migrate in POWER6 (compatibility) mode. When restarted, the partitions will negotiate POWER7 mode if running SLES 11. POWER7 partitions must be in POWER6 (compatibility) mode to migrate to POWER6 systems.
Further guidelines on Linux application compatibility can be found at (links reside outside of ibm.com):