This section describes areas in which incompatibilities remain when you use the Binary Compatibility Package. Applications using any of the items identified as incompatible can do any of simply fail, produce different results than when run under SunOS 4.x, or produce results inconsistent with those expected in SunOS 5.x.
SunOS 4.x has two sets of functions to look up information about users, hosts, groups, and so forth. One set of functions is described in the Reference Manual pages gethostent(3N), getnetent(3N), getnetgrent(3N), getprotoent(3N), getpublickey(3R), getrpcent(3N), getsecretkey(3R), getservent(3N), and yp_get_default_domain(3N). These functions first search the appropriate NIS map. They search the corresponding file in /etc only if NIS is not running. The second set of functions is described in the Reference Manual pages getpwent(3V) and getgrent(). These functions first search a file in /etc. If the data is not found and NIS is running, these functions then query NIS. For statically linked applications, each of these functions behaves in SunOS 5.x exactly as it does running under SunOS 4.x.
For SunOS 5.0, and subsequent releases, all of these functions are changed to perform their functions through the Name Service Switch. At run time, the contents of the configuration file /etc/nsswitch.conf determine the sources and the sequence of look ups.
When an application has been statically linked on SunOS 4.x and is run on SunOS 5.x with the Binary Compatibility Package, these functions behave exactly as they do on SunOS 4.x. If the Name Service Switch of the machine running SunOS 5.x is not configured to behave as described in the first paragraph of this section, these functions in statically linked 4.x applications can behave differently than they do in native 5.x applications. These functions in dynamically linked 4.x applications running on SunOS 5.x behave the same as they do in native 5.x applications.
The SunOS 4.x release uses the a.out object file format. The Solaris 2.x release uses the new Extensible Linking Format (ELF). Solaris 2.x programming tools (such as cc, ld, and ar) generate ELF files, and the default exec file format is ELF.
The Solaris 2.x exec identifies the executable file format (a.out or ELF) and uses the proper loading scheme.
The default core file format in SunOS 4.x is a.out and in the Solaris 2.x release it is ELF. When executing an a.out file in this release using the Binary Compatibility Package, the core files generated will be in a.out format. The compatibility mechanism is triggered only when loading and executing files with a.out binary format.
SunOS 4.x programs expecting an a.out executable file or core format will not work on files with other formats. For example, an application (such as the SunOS 4.x nm(1) command) expecting to access a file with the a.out format will not work when the file is in ELF format.
Programming tools and utilities in the Solaris 2.x release will not work as expected on binaries and core files in a.out format.
There are major discrepancies between SunOS 4.x and Solaris 2.x system calls, such as different system call numbers and different interfaces or behaviors. Most of the differences between system calls in the two versions are handled by the Binary Compatibility Package through mappings and the use of alternate routines providing the expected interface and behavior.
The system call mappings can cause the output of the truss(1) program run under the Binary Compatibility Package to differ from your expectations. A system call name might differ, or a system call might not occur when expected. The arguments to the call or the returned value might be different. For example, in cases requiring path name resolution (see "Resolving Path Names "), an open() call to one file can actually open a different file.
Applications should invoke the system calls through the wrapper routines provided in libc. Do not directly invoke system calls through the trap mechanism, as it is then impossible to call the appropriate routine and map the data and system call number properly.
Some system call incompatibilities are not addressed by this package because the calls have become obsolete, because they should not be used by user applications, or because they are included in other independent packages. The following is a detailed list of all such calls:
The Solaris 2.x version of acct is compatible with the Application Binary Interface (ABI) and the System V Interface Definition (SVID); the SunOS 4.x version is not. The differences involve turning accounting off and the format of the accounting record. In the Solaris 2.x release, with accounting already on, a call to acct with a given path name turns accounting off. In the SunOS 4.x release in the same situation, the call will switch only to another accounting file, and will not turn accounting off.
Auditing is not supported by the Binary Compatibility Package or by the base Solaris 2.x environment. Auditing is handled by an independent package in the Solaris 2.x release. The auditing facility provided by that package will not be binary compatible with SunOS 4.x applications.
This call has become obsolete. It is not supported in the Solaris 2.x release or the Binary Compatibility Package.
A version of flock is implemented on top of fcntl(2) locking. It does not provide complete binary compatibility, and the following differences exist between this version and the SunOS 4.x version:
flock requires the file to be opened for writing before requesting an exclusive lock.
Read permission is required on the file to obtain a shared lock.
Locking a segment that is already locked by the calling process causes the old lock type to be removed and the new lock type to take effect.
Locks are not inherited by a child process in a fork function.
Locks obtained through the flock mechanism under SunOS 4.x were known only within the system on which they were placed. This is no longer true.
The SunOS 4.x behavior is not available in the default Solaris 2.x release or with this package.
All ioctl's related to filio, sockio, streamio, termio, termios, mtio, and dkio, as well as ioctl's supported by the older version 7 and 4BSD terminal drivers are supported. Otherwise, only the ioctl's pertaining to standard devices of Solaris 2.x platforms are provided. Discrepancies between the ioctl numbers (for the ioctl's supported) in the two versions are handled transparently. The ioctl parameters are mapped whenever necessary.
The following SunOS 4.x ioctl's are incompatible with the Solaris 2.x release:
This ioctl is not available in this release, but it is supported by the Binary Compatibility Package. This ioctl is replaced by DKIOCINFO, which now includes the combined information of the SunOS 4.x DKIOCGCONF and DKIOCINFO structures.
This ioctl is not supported in Solaris 2.x. With the Binary Compatibility Package it returns EINVAL.
In SunOS 4.x this ioctl toggles the write check on the floppy device. With the Binary Compatibility Package, this ioctl does not toggle the write check on the floppy device, but it returns success.
This ioctl is available only for the xd(7), xy(7), and ipi(7) drives. This ioctl will fail for SCSI devices. Use the USCSI ioctl for these devices.
This ioctl is obsolete and is not supported by the Solaris 2.x release or this package.
This ioctl is obsolete and is not supported by the Solaris 2.x release or this package.
This ioctl is obsolete and is not supported by the Solaris 2.x release by the Solaris 2.x release or this package.
This ioctl is obsolete and is not supported by the Solaris 2.x release or this package.
This ioctl is obsolete and is not supported by the Solaris 2.x release or this package.
This Solaris 2.x system call behaves differently from SunOS 4.x. When a -1 is supplied as the first argument, the calling process is also killed; this was not the case in SunOS 4.x.
The pipe system call in SunOS 4.x opens one descriptor for reading and one for writing. In the Solaris 2.x release it opens both descriptors for reading and writing. Because this difference should affect few if any binaries, no compatibility version has been provided.
The optional addr2 argument to the SunOS 4.x ptrace system call is not supported. In addition, the following requests are not supported in the Solaris 2.x release:
PTRACE_ATTACH /* 10, attach to an existing process */
PTRACE_DETACH /* 11, detach from a process */
PTRACE_GETREGS /* 12, get all registers */
PTRACE_SETREGS /* 13, set all registers */
PTRACE_GETFPREGS /* 14, get all floating point regs */
PTRACE_SETFPREGS /* 15, set all floating point regs */
PTRACE_READDATA /* 16, read data segment */
PTRACE_WRITEDATA /* 17, write data segment */
PTRACE_READTEXT /* 18, read text segment */
PTRACE_WRITETEXT /* 19, write text segment */
PTRACE_GETFPAREGS /* 20, get all fpa regs */
PTRACE_SETFPAREGS /* 21, set all fpa regs */
PTRACE_GETWINDOW /* 22, get register window n */
PTRACE_SETWINDOW /* 23, set register window n */
PTRACE_22 /* 22, filler */
PTRACE_23 /* 23, filler */
PTRACE_SYSCALL /* 24, trap next sys call */
PTRACE_DUMPCORE /* 25, dump process core */
PTRACE_SETWRBKPT /* 26, set write breakpoint */
PTRACE_SETACBKPT /* 27, set access breakpoint */
PTRACE_CLRDR7 /* 28, clear debug register 7 */
PTRACE_26 /* 26, filler */
PTRACE_27 /* 27, filler */
PTRACE_28 /* 28, filler */
PTRACE_GETUCODE /* 29, get u.u_code */
This system call does not exist in the Solaris 2.x release or the Binary Compatibility Package and should not be needed by user applications.
This system call does not exist in the default Solaris 2.x release or the Binary Compatibility Package.
The Binary Compatibility package provides a set of libraries compatible with the SunOS 4.x libraries. Therefore, even if the interface or behavior of a routine has changed in the Solaris 2.x release, user applications should not be affected when the Binary Compatibility Package is used.
Library routines that deal with the /etc/xtab file will not work correctly with the Binary Compatibility Package. See the xtab(5) and exportent(3) manual pages in the SunOS Reference Manual.
The order of locales in the string returned by setlocale() differs between the SunOS 4.x and Solaris 2.x releases. This string is normally used by a subsequent call to setlocale(), and the order should not matter. Applications that rely on a specific order of locales may not be binary compatible.
All data mapping takes place in the binary compatibility library. If bad addresses are passed as an argument, the expected EFAULT error is not always returned. The data mapping library routines attempt to catch bad addresses, but since this is not possible at all times, accessing bad addresses may result in a Bus Error/Segmentation Violation.
The Binary Compatibility Package provides a signal handling mechanism compatible with SunOS 4.x. It also resolves the differences in signal numbers.
The SIGLOST signal is not supported.
Many system files have been renamed or moved in the Solaris 2.x release. Some do not exist in this release and others have a different format. Whenever possible, the Binary Compatibility Package addresses this problem by creating symbolic links, installing new files, or mapping the data.
A portable program should avoid using system-dependent files. If a program must access such files, then it must do so using the standard interface routines provided. For example, rather than opening and reading the /etc/mtab file directly, the program should use the getmnt() family of routines to access the contents of the mtab file.
Accounting files in the Solaris 2.x release have different formats than those in SunOS 4.x. An application accessing an accounting file will not be binary compatible.
Exporting system files in the Solaris 2.x release is handled very differently than it was in SunOS 4.x. Binary compatibility cannot be provided for these files. This should not be a problem since user applications are not expected to access these files.
The name and format of these files have changed. The Binary Compatibility Package performs the mappings needed to give applications read-only access to these files. Applications requiring write access to these files are not binary compatible. Applications are not expected to write to these files.
Symbolic links to these files are no longer supported. This is, if an application creates a link to /etc/fstab or /etc/mtab, and attempts to open the symbolic link, the open call fails.
This file has no direct equivalent in the Solaris 2.x release and is not be provided as part of this package. Applications using this file will not be binary compatible.
In the Solaris 2.x release, the actual passwords are kept in a shadow file. Applications accessing the passwd file to obtain a password will not be binary compatible. All applications should access this file through the getpw() interface routines.
The printcap of SunOS 4.x is replaced by a directory tree in SunOS 5.x. The Binary Compatibility Package provides applications read-only access to the equivalent data for the host on which the application is executed. Write access to printcap is not supported.
This file was obsoleted in SunOS 4.x. Because the utmp file format and access mechanism are very different, programs depending on the relationship between /etc/ttys and the utmp file will not work on the Solaris 2.x release. Use ttyslot for dynamically linked applications (will not work for statically linked applications).
This file in SunOS 4.x replaced /etc/ttys. Obsolete in SunOS 5.x. No compatibility provided.
These files hold user and accounting information for commands such as who, write, and login. In Solaris 2.x, each of these files has been replaced with a pair of files: /etc/utmp has been replaced with /var/adm/utmp and /var/adm/utmpx, and /var/adm/wtmp with /var/adm/wtmp and /var/adm/wtmpx. When an application opens one of these files, it receives the concatenation of its two new counterparts.
Symbolic links to these files are no longer supported. This is, if an application creates a link to /etc/utmp or /var/adm/wtmp, and attempts to open the symbolic link, the open call fails.
Localized 4.x applications will not run on a domestic SunOS 5.x regardless of static or dynamic BCP. See the appropriate localization documentation to determine if a particular 4.x application will run on the appropriate localized Solaris environment.