Eligible Applications must meet the following guidelines for source code Compatibility:

What do we guarantee to the developers?

1. General Source Code Guidelines for Eligible Applications:
   • must be written to comply with the standards as listed in standards(5)
   • must not be converting 32 bit applications to 64 bit applications— or vice versa.
   • must not include Makefiles for building object files from compiled applications to run on specific platforms
   • must not include 3rd party software libraries (binaries) or other programming interfaces
   • must not include address space incompatibilities in application file headers. (e.g. use of 1K address descriptors instead of 16K address descriptors)
   • must not include Assembler code in any form.


2. Compiler Guidelines for Eligible Applications:
   • must be C and C++ applications.
   • must have been compiled with the same compiler and compiler version on both the Originating Platform and the Target Platform
   • must have been compiled using one of the following compilers: Sun Studio compiler version 9 or 10.
   • 3^rd Party applications, including header files, need to be compiled with the same version of the compiler as the application itself.
   • The use of Compiler flags and pragmas (e.g. Compiler overrides and controls ) must be compatible with the Instruction Set Architecture that you are using. See http://developers.sun.com/solaris/articles/x86_compiler_diffs.html for a list of compiler flag issues. (e.g., if your application has been optimized for the SPARC Platform using back-end compiler flags, some flags may be incompatible for the x86 platform, and you will need to delete these flags or replace them with the flags that are valid on the x86 platform and used for optimization for the x86 platform).
   • Applications with platform-specific definitions (for example, #ifdef __SPARC), may require your intervention before porting between platforms.
   • Performance-sensitive applications generally use platform-specific optimization flags to achieve good performance. These flags are architecture dependent and are different for the SPARC and x86 platforms. Certain compiler options work only for the SPARC platform and should not be used on the x86 platform.
   • The Interfaces to I/O devices on the Solaris 10 x86 platforms must be compliant with the interfaces defined in the man pages for special file (section 7).


3. Floating Point Operation Differences - Guidelines for Eligible Applications
   In x86 systems, the floating-point registers are 80-bits wide, while in the SPARC systems, the floating point registers are 64-bits wide. Due to this, the computation results can differ because intermediate results of arithmetic computations can be in extended precision. Please refer to the Numerical Computation Guide for further detail.


4. Big Endian/Little Endian Guidelines for Eligible Applications
   The Solaris Operating System can be used both in big-endian mode (SPARC version) and in little-endian mode (x86 version). Endianness is mandated by the hardware platform used. One of the strengths of the Solaris OS is that it handles the endianness issue, so that ISVs or developers do not need to be concerned about how quickly their applications will be available on x86 platforms. Sun's software architecture allows big-endian applications for the Solaris SPARC Platform Edition to run on the little-endian Solaris x86 Platform when they are recompiled. In general, no re-engineering is needed. However, the endianness difference can cause problems, particularly if an application uses low-level code that takes optimal advantage of the hardware capabilities.
   
   Shared Memory Implementation
   Sharing memory with opposite-endian devices or processors constitutes data import and export. Access to shared data must take endianness issues into account. Some peripheral buses lend themselves to shared memory approaches to interprocessor communication. In general, some means of translating the data must be provided if the processors are not of the same endianness.
   
   Application Data Storage
   File systems are neutral to endianness in general, and swapping files between Solaris SPARC and x86 is not an issue. But applications storing raw data that can be shared between platforms would be an issue. For example, if an application on the Solaris SPARC platform writes the data structures in a raw format to the files, then the data stored in these files would be endian-dependent. Reading or writing these data files from an x86 processor-based machine can create problems regarding the endianness of the data. In short, the binary data (raw data) stored on a file is not transferable between the SPARC and x86 platforms.
   
   Storage Order Differences
   The order of storage of the data varies between platforms; therefore, code written assuming a particular storage order is not portable.
   
   Accessing the Individual Bytes of the Numeric Data Using Pointers
   If an application uses individual bytes of a numeric data type to store and retrieve values, then you might get different results due to the endianness of the underlying platform. In this case the code would not be portable from Solaris SPARC to x86.
   
   Sending Data Over the Network
   Applications running on Solaris systems interoperate with other systems over the network using standard network protocols that have enabled communication between big-endian and little-endian systems. However, if the applications transfer data (numeric data) over the network directly without any protocol, then an issue might arise.


5. Platform Guidelines for Eligible Applications:
   • I/O Architecture
     Unlike the x86 family, which uses special IN/OUT instructions to access the PCI I/O space, the SPARC chip family treats access to the PCI I/O space the same as it treats access to the memory space. Communication with I/O devices in the SPARC platform is accomplished through memory; a range of memory locations is logically replaced by device registers.
     
     The x86 platform accesses I/O ports through the I/O address space by means of a set of I/O instructions and a special I/O protection mechanism. Accessing I/O ports through memory-mapped I/O is handled with the processor's general-purpose move and string instructions, with protection provided through segmentation or paging. I/O ports can be mapped so that they appear in the I/O address space or the physical-memory address space (memory-mapped I/O) or both.
     
     The SPARC platform assumes that input/output registers are accessed by means of load/store alternate instructions, normal load/store instructions, coprocessor instructions, or read/write ancillary state register instructions (RDASR, WRASR). In the load/store alternate instructions case, the I/O registers can only be accessed by the supervisor. If normal load/store instructions, coprocessor instructions, or read/write Ancillary State Register instructions are used, then whether the I/O registers can be accessed outside of supervisor code or not depends on the implementation.
   
   
   • Must Not Use ISA-specific pathnames - must not use the instruction set architecture name in a pathname used by the Eligible Application
   
   
   • Must Not Use ISA-specific interfaces - Use of SPARC specific interfaces have no equivalent in x86 or x64 architectures and will not compile. (e.g. SPARC registers , SPARC traps, etc.)

Solaris 10 features with New API's that require a recompile of the applications

New APIs

Event Ports—The Event Ports Framework provides a mechanism to generate and collect notifications about completed asynchronous transactions. Transactions are asynchronous reads and writes as well as interactions between application and kernel which require an asynchronous completion notification. It is a scalable and unified way to serve multiple clients, waiting on multiple objects simultaneously and without degrading overall performance.

SUSv3 Advanced Real Time Features—This project implements optional features specified by the new SUSv3 standard.

User-Level Atomic Operations—atomic operation functions for use by user-level threads programming.

LDF: Layered Driver Framework—A set of kernel APIs for accessing devices from within the kernel and enhancements in libdevinfo(3DEVINFO) for retrieving device usage information inside the kernel.

File System Driven Device Configuration—A new device file system, devfs, is implemented to drive device autoconfiguration.

uDAPL: User Direct Access Programming Library—The uDAPL defines a single set of user APIs for all RDMA-capable Transports.

Solaris Containers—A virtualized operating system environment allowing one or more processes to run in isolation from other activities on the system.

Dynamic Tracing—An infrastructure for dynamic instrumentation and tracing to applications and kernel.

Process Rights Management—Process Rights Management adds support for fine-grained process privileges to Solaris.

Predictive Self Healing—Predictive Self Healing introduces a new software architecture and methodology for fault detection, diagnostics, logging, and system service management across Sun's product line.

Memory Placement Optimization (MPO)—MPO allows applications optimization on machines with asymmetric hardware memory configurations.

Network File System version 4 (NFS v.4)—Solaris supports for NFS v4.

Solaris Cryptographic Framework—A high performance developer's framework for adding encryption of data within an application and for encryption transactions on the Internet. Based on defacto PKCS#11 standard.

KMDB(Kernel Debugger)—KMDB is based on mdb. It provides all of the services of kadb, in addition to providing virtually all of the services introduced by mdb.