| |
|
|
Chapter 2
Kernel and API Compatibility Notes
As discussed earlier in this guide, SCO OpenServer Release 6 supports two ABIs: OSR5 and SVR5. In addition, the common execution environment provided by the SCO OpenServer Release 6 kernel and runtime libraries permits you to run most existing SCO OpenServer and UnixWare 7 applications without modification.
As an aid to porting applications, the differences between the two ABIs are discussed in detail in "Kernel compatibility" on page 23 and "API Compatibility" on page 35.
The more general subject of using the SVR5 libraries, compilers, header files and other tools on any platform is documented in the Software development documentation at http://osr600doc.sco.com/en/Navpages/SDKhome.html">http://osr600doc.sco.com/en/Navpages/SDKhome.html.
2.1 Kernel compatibility
This section details the differences between system calls, libraries, ioctls, system files, and commands supported on SCO OpenServer Release 5 and Release 6.
2.1.1 Executable formats
This section deals with the kernel's ability to recognize and start the load process for binaries of various types. This includes setting compatibility switches so the kernel can make decisions based on that knowledge when processing various system calls and libray routines.
The Release 5 Development System marks Executable and Linking Format (ELF) binaries in a distinctive way; the Release 6 cc command with the -K osr option marks binaries similarly. The Release 6 kernel uses this information to switch on Release 5 system call semantics for OSR5 ABI binaries. (Note that COFF executables are also assumed to be OSR5 ABI binaries.)
When the Release 6 kernel loads an ELF executable, the ELF processing code looks at the ELF note section of the executable and, if it is 28 bytes long, it assumes the executable is a Release 5 ELF executable.
Release 6 also provides a command that specifically mark the ELF flags section with a special string; the Release 6 kernel checks for this string in the flag section and, if present, assumes the executable is a Release 5 ELF executable. Using elfmark(CP), any ELF binary can be marked as an OSR5 ABI binary.
2.1.2 Error numbers
There are two incompatibilities in the error numbers returned by Release 5 and Release 6 in errno:
- Some errors have different error numbers on each system (see "Errors with different values" on page 24)
- The same calls on each system can generate errors that are not generated on the other system (see "System calls with different error returns" on page 26)
2.1.2.1 Errors with different values
There are three classs of error numbers with different values on Release 6 and Release 5:
- Errors that are semantically the same on both systems but have different error numbers on each system; these errors are directly translated on Release 6. See ``Errors that have different errnos on each system''.
- Errors on Release 6 that are not on Release 5; these errors are translated by the code for each system call on Release 6, so that an error appropriate for OSR5 ABI applications is returned. Applications running on Release 5 will not see these errors; the behavior of portable programs should not be made to depend on the target system returning these errors. See ``Errors on Release 6 but not Release 5''.
- Errors on Release 5 that are not on Release 6; the resolution of the incompatibilities varies depending on the system call, and is presented in ``Errors on Release 5 but not SCO OpenServer 6 Release 6''.
Errors on Release 6 and not Release 5 Error Release 6 errno ECLNRACE 59 ENOLOAD 152 ERELOC 153 ENOMATCH 154 EBADVER 156 ECONFIG 157 ECANCELED 158 EUSERS 94 ENOTAUTH 160 ELKBUSY 170 Olivetti 200-223
Errors on Release 5 and not on Release 6 Error Release 5 errno ELBIN 75 EDOTDOT 76 2.1.2.2 System calls with different error returns
The table below shows the errors returned for various system calls that are different between the SVR5 ABI and Release 5. See the for each system call listed for the detailed resolution of the error incompatibility (if you are viewing this document online, click on the system call name in the left-most column to go to the appropriate table).
2.1.3 Signals
The signal incompatibilities between the SVR5 ABI and OSR5 ABI are managed by the kernel.
When a sigaction type signal is sent to a process running an OSR5 ABI binary, the kernel puts the signal data in the OSR5 ABI structure before sending it to the application.
The incompatibilities arise in the siginfo_t and ucontext_t structures, which are different. See the following sections for more detail:
2.1.4 Core file generation
Core files generated on Release 5 systems are given file names of the form core.pid, where pid is the process ID of the process causing the core dump. On Release 6, core files are named simply core (though this behavior can be changed via a tunable). In general, portable applications should not make assumptions about core file naming on target systems.
2.1.5 CPU status information
On Release 5, CPU status information (active or inactive) could be obtained by opening the /dev/at1 device and making an ioctl() call. Release 6 has no such device, so ported applications must use the p_online() interface instead. Note that p_online() numbers processors starting at 0; on Release 5, processors are numbered starting at 1. Here is an example code fragment:
int state = p_online(processor_number, P_QUERY); switch (state) { case P_ONLINE: printf("active "); break; case P_OFFLINE: printf("inactive "); break; case P_DISABLE: printf("disabled "); break; default: fprintf(stderr, "%s: cannot determine processor_data[]\n", Pgm); exit(1); } printf("\n");2.1.6 C2 Security (libprot) library
2.1.6.1 OSR5 ABI Applications
The /osr5/usr/lib/libprot.so library is provided for use by OSR5 ABI applications only.
OSR5 ABI applications executing on Release 6 can expect that all libprot calls will functions as in previous releases, with the exceptions shown in the table below. These calls all return ENOSYS on Release 6. Ported applications should be rewritten to use the Release 6 equivalents:
Release 5 libprot call Release 6 equivalent stopio(S-osr5) getluid(S-osr5) getuid(S) setluid(S-osr5) setuid(S) statpriv filepriv(S) chpriv filepriv(S) Note that getluid and setluid have no exact equivalent in the OSR6 kernel. The "login user ID" is a UID assigned the user's login process, is propagated to all child processes, and can never be reset once assigned.
2.1.6.2 SVR5 ABI Applications
SVR5 ABI applications use the SVR5 ABI library /usr/lib/libiaf.so for Identification and Authentication, and these calls are not functional in the Release 6 kernel.
This will be resolved in a Release 6 Maintenance Pack when an SVR5 ABI version of libprot will be provided, as well as an updated libiaf that's compatible with libprot and its Identification and Authentication implementation.
2.1.7 System calls
The subsections that follow detail the differences between the system calls supported on Release 5 and the SVR5 ABI.
2.1.7.1 SUDS extension
These are a set of calls in a configurable module for Release 5 only. They are defined in a static library, libsuds.a, and are accessed through their own call gate that does nothing until the system is properly configured for these calls. The SUDS calls are unsupported on Release 6.
2.1.7.2 access(2)
Two constants defined in unistd.h for deriving the amode argument are not normally used on Release 5 (EX_OK and EFF_ONLY_OK). OSR5 ABI binaries will not normally use these values since they did not have kernel support, but since they are in unistd.h, it is possible for an OSR5 ABI application to use them. If such a binary runs on the SVR5 ABI, the EX_OK and EFF_ONLY_OK constants will be evaluated correctly as part of amode. This may cause the application to behave differently than it did on Release 5.
2.1.7.3 adjtime(2)
The Release 5 version of this system call is affected by a number of system tunable parameters that are not present in the SVR5 ABI: update_rtc (if set to 1, the real time clock is set to the new system time after adjtime); clock_drift (the rate at which adjustment is made in nanoseconds/second); and, track_rtc (keeps system clock accurate). OSR5 ABI applications that make assumptions based on the behavior of adjtime when the above parameters are set (on Release 5) may exhibit unexpected behavior with the SVR5 ABI.
2.1.7.4 execlp(2) / execvp(2)
The OS libc code retries up to 5 times on an ETXTBSY for the execlp and execvp system calls. The SVR5 ABI libc does not return ETXTBSY, so an application expecting this behavior will not see it.
2.1.7.5 fcntl(2)
The SVR5 ABI fcntl system call has many more commands than the Release 5 system call: F_DUP2, F_GETOWN, F_SETOWN, F_FREESP, F_RSETLK, F_RSETLKW, F_RGETLK. A portable application compiled using the SVR5 ABI should avoid using these commands, as they will fail with ENOSYS (or SIGSYS) on Release 5.
2.1.7.6 getrlimit/setrlimit(2)
On Release 5, the mnemonic for resource number 6 is RLIMIT_AS. For the SVR5 ABI, the mnemonic is RLIMIT_VMEM. However, the function of resource number 6 in both systems is exactly the same, so this does not cause a problem for OSR5 ABI binaries.Any source code brought to Release 6 from Release 5 would have to be changed (if it uses the Release 5 RLIMIT_AS mnemonic) before compiling with the SVR5 ABI compilation.
2.1.7.7 libattach/libdetach(S)
These Release 5 calls support static shared libraries for user applications; the calls are in the Release 5 kernel, but are not documented. These calls are not supported by the SVR5 ABI. A Release 5 application using this call on Release 6 will return ENOSYS for the call.
2.1.7.8 memcntl(2)
Although memcntl is not documented in Release 5, there is code in the kernel to support it. The call is documented in the SVR5 ABI, and is the same except for two extra subcommands available on Release 5: MC_MAPCPU and MC_MAPUBLK. Any Release 5 binary that uses these subcommands will fail with ENOSYS when run on Release 6.
2.1.7.9 mmap(2)
The Release 5 mmap.h contains 4 undocumented subcommands not supported by the SVR5 ABI: MAP_PHMEM, MAP_KVMEM, MAP_ANCESTRAL, and MAP_NOEOF. An OSR5 ABI application will get an ENOSYS error return when it attempts to use these subcommands on Release 6.
2.1.7.10 mount(2)
File-system specific options can be a problem if a given fstype name is the same on both systems (in sysfs) but the options in data_ptr are not.
There is a difference in the mflags=0x8 defined in mount.h. On Release 5 it is `MS_CACHE', described in mount.h as "RFS client caching". On Release 6 it is `MS_HADBAD', described in mount.h as "file system incurred a bad block so set sstate to FSBADBLK on mount".
The MS_NOEXEC mflag is defined in mount.h on Release 5 as "return ENOEXEC on exec()". Its bit value is 0x8000. Release 6 does not have anything at that bit value or a function like this at another value. Using this call on Release 6 results in EINVAL.
2.1.7.11 nice(2)
On Release 6, nice can only work on processes in the time sharing class, and returns EINVAL on attempts to change the priority of a fixed priority class process. On Release 5, nice does not return EINVAL. If a Release 5 application is run on Release 6 and does a nice on a fixed priority class process, it would get an unexpected EINVAL error.
To fix, alter the Release 5 application source code to expect EINVAL as a possible error return on using nice, and then recompile.
2.1.7.12 paccess(S)
This Release 5 system call is unsupported by the SVR5 ABI. The paccess(S) system call on Release 5 gets and sets parameters in the u area of the current process and is used by a parent process to trace a child process.
An OSR5 ABI application using paccess must be recoded to use the /proc file system to access status information about a process. See proc(F).
2.1.7.13 pipe(2)
With the SVR5 ABI, pipes are implemented as two bidirectional, STREAMs-based file descriptors. For the OSR5 ABI, a pipe is implemented as two one-way file descriptors, with one fd being `send' and the other `receive'. Release 5 applications run on Release 6 will behave properly despite the difference in implementation.
On Release 6, an fstat (see stat(S)) of a pipe returns the sum total of bytes available to be read on both pipes as the byte count of the pipe. On Release 5, it is just the data on the inward bound pipe.
The write side of a pipe on Release 5 blocks after 5120 bytes of data. On Release 6, the write side could block considerably later (depending on water marks and system resources). If an OSR5 ABI application depends on the write side blocking after 5120 bytes of data, it will probably not work correctly.
2.1.7.14 poll(2)
The OSR5 ABI poll code shows a system wide tunable poll_delay_compatibility that effects whether a poll call with no file descriptors will honor the timeout; if the tunable is set, the timeout is honored.
OSR5 ABI binaries executed on Release 6 will behave the same as on Release 5 (i.e., the poll_delay_compatibility tunable is checked and the timeout is honored only if the tunable is set).
2.1.7.15 priocntl(2)
The SVR5 ABI supports a few documented commands not supported by the OSR5 ABI: PC_ADMIN, PC_SETAGEPARMS, and PC_GETAGEPARMS.
2.1.7.16 probe(S)
On Release 5, this undocumented system call executes all the configured probe routines and returns the information they return to the calling user process. This system call is not supported on Release 6. OSR5 ABI applications run on Release 6 will return ENOSYS if they make a call to probe.
2.1.7.17 ptrace(2)
An OSR5 ABI application using ptrace should be recoded to use the /proc file system, which is the preferred interface for accessing status information about a process. See proc(F).
While ptrace(S) is supported on Release 6, only requests `0' through `9' are supported. The Release 5 kernel supports `0' through `13'.
To run on Release 6, an OSR5 ABI application that needs to use ptrace would probably need to be recompiled. It is highly recommended that such an application be rewritten to use /proc instead.
2.1.7.18 setcontext(2)
There are differences in the ucontext structure used by this system call on Release 6 and Release 5:
- On Release 6, sigset_t is 4 int fields; there is a uc_privatedatap long and 4 long fillers at the end of ucontext_t.
- On Release 5 sigset_t is 1 int, but there are 3 int fillers. At the end of ucontext_t there are 5 long fields.
This incompatibility is managed by the Release 6 kernel for OSR5 ABI applications provided these applications always precede a call to setcontext with a call to getcontext. If an OSR5 ABI application running on Release 6 makes a call to setcontext that is not preceded by a call to getcontext, the application could pass bad data to setcontext, with unpredictable results.
2.1.7.19 sysi86(2)
On Release 5, the SI86GETFEATURES call is used extensively by libc and other libraries to determine if a feature is available in the kernel. This subcommand is supported on Release 6, but FEATURE_TCGETS and FEATURE_SID will be turned off, as these services are not provided by the Release 6 kernel.
There are a number of sysi86 subcommands that are on Release 5 but not on Release 6. If an OSR5 ABI executable invokes any of these subcommands, the Release 6 kernel returns EINVAL:
0x23 (there is no mnemonic for this command in the sysi86 OSR5 ABI) SI86KSTR SI86SWAP SI86SWPI RDUBLK SI86VM86 SI86GETPIPE SI86SETPIPE SI86POPPIPE SI86GETNPIPE SI86SETPIPE_NM SI86GETPIPE_ALL SI86APM SI86TIMECHG SANUPD SI86CAUNICENTER SI86SETSYSLOG2.1.7.20 sysinfo
The following commands are not supported by the OSR5 ABI:
SI_SET_HOSTNAME SI_HW_PROVIDER SI_HW_SERIAL SI_ARCHITECTURE SI_INITTAB_NAME SI_BUSTYPES SI_KERNEL_STAMP SI_OS_BASE SI_OS_PROVIDER SI_USER_LIMIT2.1.7.21 syssetconf
This Release 5 system call and the kernel tunables it provides are unsupported on Release 6.
The Release 5 syssetconf system call is an extension to sysconf that provides a set of `kernel' type tunables, none of which are documented on the Release 5 sysconf(S) man page (syssetconf itself is undocumented). These constants are visible to applications, however, in the Release 5 sys/unistd.h header file, so an OSR5 ABI application can use them. None of these values are defined on Release 6. OSR5 ABI applications run on Release 6 that use syssetconf on Release 6 will return ENOSYS (and/or a SIGSYS signal). Such applications need to be recoded to work properly on Release 6.
Note that on Release 6, sysconf(S) is implemented as a C library function, not a system call.
2.1.7.22 uadmin(2)
There are two commands for this system call on Release 5 that are unsupported on Release 6: A_BDEVSYNC, A_GETDEV, and AD_PWRNAP. OSR5 ABI applications using these commands on Release 6 will get an ENOSYS error return and a SIGSYS signal).
On Release 6, the AD_HALT subcommand (to A_SHUTDOWN) shuts the system down, but does not support the "reboot on keystroke" functionality supported by Release 5.
2.1.7.23 ulimit(2)
The Release 6 system call supports two more commands than Release 5: UL_GMEMLIM and UL_GDESLIM.
2.1.7.24 waitid(2)
The siginfo_t structure used by this call differs between Release 5 and Release 6. For OSR5 ABI application binaries running on Release 6, these differences are managed by the kernel. An OSR5 ABI application being ported to the SVR5 ABI on Release 6 might need to be changed to conform to the SVR5 version of siginfo_t. Both versions have the same overall size, but there are differences in members and internal offsets, as follows:
- Although both structures use the pid_t data type, this type is a 32-bit value on Release 6 and a 16-bit value on Release 5.
- There are differences in _proc._pdata for the _kill and _cld structures within siginfo_t.
- The _fault structure in Release 6 has additional members not on Release 5.
See the header files /usr/include/sys/siginfo.h and /osr5/usr/include/sys/siginfo.h for details.
2.1.7.25 xsetre[gu]id(S)
The Release 5 xsetregid(S) and xsetreuid(S) functions allow setting the `real' and `effective' uids and gids in one system call. There are versions supported on Release 5 in both libc.so.1 and libsocket.a. OSR5 ABI applications must have been compiled using the version in libc.so.1 to run on Release 6 (applications linked with static archives are unsupported on Release 6).
When an OSR5 ABI application using these calls is run on Release 6, these calls are mapped to the setreuid(S) and setregid(S) functions.
2.2 API Compatibility
The API compatibility sections list each interface that is part of the documented APIs defined by the various libraries and header files shipped with SCO OpenServer Release 6 that have substantial differences from the same API on Release 5.
Each section describes the interface compatibility for OSR5 ABI applications as well as compatibility considerations for applications compiled with the SVR5 ABI.
2.2.1 Manual Pages
The same UNIX function can sometimes be in different headers and/or libraries depending on the platform. Use the man command to find the location of a function on SCO OpenServer 6:
$ man recv recv(S) recv -- receive a message from a socket Synopsis cc [options] file -lsocket -lnsl #include <sys/types.h> #include <sys/socket.h> ssize_t recv(int socket, void *buf, size_t len, int flags); ...The top of the man page indicates the headers to use in the source code and the libraries to reference in the makefile. Note that OSR5 API manual pages for libraries are generally available in manual page sections with the suffix "-osr5". For example, the OSR5 ABI Section (S) pages are available on OpenServer 6 in Section (S-osr5).
You can also use DocView (http://localhost/cgi-bin/manform) to search for maual pages. If you don't find the page you are looking for on your local OpenServer 6 system, you can also check the manual pages on the web:
- http://osr600doc.sco.com/en/Navpages/sectionlist.html">http://osr600doc.sco.com/en/Navpages/sectionlist.html
- The complete OpenServer 6 documentation set, with all SVR5 ABI manual pages (and many OSR5 ABI pages).
- http://osr507doc.sco.com/en/Navpages/sectionlist.html">http://osr507doc.sco.com/en/Navpages/sectionlist.html
- The complete OpenServer 5.0.7 documentation set, with all OSR5 ABI manual pages.
2.2.2 C library (libc) interfaces
The C library (libc) contains the system calls and C library routines described in the Section S manual pages.
This "API Compatibility" on page 35 topic is concerned with libc function calls; for compatibility information for system calls defined in libc (and compatibility for other basic system services), see "Kernel compatibility" on page 23.
C library compatibility with earlier releases is provided through these libraries on Release 6:
Binary compatibility for OSR5 ABI-compiled binaries is provided through the /osr5/usr/lib/libc.so.1 version of libc, which is loaded by the dynamic linker for any executable that is appropriately marked as an OSR5 binary (see elfmark(CP).
2.2.2.1 tm structure
The tm structure is used by various time functions in libc (asctime, asctime_r, ascftime, getdate, gmtime, gmtime_r, localtime, localtime_r, mktime, strftime, strptime, wcsftime).
The tm structure on Release 5 has two elements at the end of the structure that are not present on Release 6:
long tm_tzadj; /* seconds from UTC (east < 0) */ char tm_name[LTZNMAX]; /* name of timezone */On Release 6, these values are available only in the external variables timezone and tzname, respectively; these external variables are also available on Release 5. Portable applications should depend only on the external variables, not on the structure elements.
2.2.2.2 confstr
The following values for the name argument to confstr (defined in unistd.h) are valid on Release 6 but not on Release 5:
_CS_HOSTNAME _CS_RELEASE _CS_VERSION _CS_MACHINE _CS_ARCHITECTURE _CS_HW_SERIAL _CS_HW_PROVIDER _CS_SRPC_DOMAIN _CS_INITTAB_NAME _CS_SYSNAME 2.2.2.3 dlsym
The RTLD_NEXT argument for the handle parameter is unsupported on Release 5.
2.2.2.4 fnmatch
The Release 6 and Release 5 implementations of fnmatch differ in the header file declarations of flags and return values found in fnmatch.h. Basically, the Release 6 interface is a superset of Release 5. Some constants are defined with different values; these are managed by the Release 6 kernel.
The Release 6 interface supports these additional flags:
#define FNM_BADRANGE 0x008 /* accept [m-a] ranges as [ma] */ #define FNM_BKTESCAPE 0x010 /* allow in []s to quote next anything */ #define FNM_EXTENDED 0x020 /* use full ksh-style patterns */ #define FNM_RETMIN 0x040 /* return length of minimum match */ #define FNM_RETMAX 0x080 /* return length of maximum match */ #define FNM_REUSE 0x100 /* reusing this FNM */ #define FNM_COMPONENT 0x200 /* only matching a component */ #define FNM_SUBEXPR 0x400 /* fill fnm_nsub, fnm_so[], fnm_eo[] */ #define FNM_UNANCHORED 0x800 /* match need not include string start */ #define FNM_NSUBEXPR 10 /* length of fnm_so[] and fnm_eo[] */Also, the Release 6 interface supports one additional error:
#define FNM_ERROR (-4) /* internal error; probably allocation failure */A portable application should use only those flags common to the two systems, or first determine the system on which it is running and then use flags appropriate to that system.
2.2.2.5 ftw/nftw
The constants used as argument values for ftw and nftw (and defined in ftw.h) on Release 5 and Release 6 are slightly different. A portable program should only use those values common to the two systems or first determine the system on which it is running before issuing the call with appropriate values.
The Release 6 values are a superset of the Release 5 values; the extensions provided are:
#define FTW_ERR 8 /* FTW_ERRORS only; internal nftw() failure */ #define _FTW_FINDDIR 020 /* continue even if getcwd() fails */ #define FTW_TRYCHDIR (FTW_CHDIR|_FTW_FINDDIR) /* for nftw() to try getcwd */ #define FTW_ERRORS 040 /* call fcn for nftw() internal errors, too */2.2.2.6 glob/globfree
Release 6 and Release 5 have different constant and structure definitions in glob.h for the glob(S) routine.
While the glob_t structure has elements on both systems not found on the other, these elements are for system use only, and should not affect application compatibility.
/* SVR5 glob_t structure */ typedef struct { struct gl_str *gl_str; /* for memory management */ char **gl_pathv; /* list of matched pathnames */ size_t gl_pathc; /* length of gl_pathv[] (less 1) */ size_t gl_offs; /* slots to reserve in gl_pathv[] */ } glob_t; /* OSR5 glob_t structure */ typedef struct { size_t gl_pathc; /* count of paths matched by pattern */ char **gl_pathv; /* pointer to list of matched pathnames */ size_t gl_offs; /* slots to reserve in gl_pathv[] */ /* Internal SCO variables */ size_t gl_vnum; /* Number of entries in gl_pathv */ size_t gl_vmax; /* Maximum entries in gl_pathv */ } glob_t;The manifest constants supported on Release 6 are a superset of those provided on Release 5.
#define GLOB_FULLMARK 0x0080 /* append "/", "@", "*", "|" like ls(1) */ #define GLOB_NOCOLLATE 0x0100 /* use "C" sorting order */ #define GLOB_OKAYDOT 0x0200 /* permit leading . to match specials */ #define GLOB_BADRANGE 0x0400 /* accept [m-a] ranges as [ma] */ #define GLOB_BKTESCAPE 0x0800 /* allow in []s to quote next anything */ #define GLOB_EXTENDED 0x1000 /* use full ksh-style patterns */Some constants are defined with different values; these are managed by the Release 6 kernel for OSR5 ABI applications.
2.2.2.7 iconv
The implementation of iconv on Release 5 supports a flag mechanism that is not supported by Release 6 (or by the X/Open standard). This mechanism allows you to set a flag in a state field in the conversion descriptor used as input to iconv.
These flags (_ICONV_DELETE and _ICONV_COMP) and the state field in the conversion descriptor are not supported by Release 6. OSR5 ABI binaries that run on Release 6 will fail if they attempt to set the conversion descriptor state field with these flags.
2.2.2.8 isnan/isnand/isnanf
On Release 5, it is necessary to include nan.h, math.h, and ieeefp.h to compile a program using these functions. On Release 6, nan.h does not exist, so include only math.h and ieeefp.h.
2.2.2.9 jmp_buf
On Release 5, the size of the jmp_buf used by longjmp and setjmp is defined in setjmp.h as 6; on Release 6, it is 10. This presents no problem for source code portability. OSR5 ABI binaries that use jmp_buf will run correctly on Release 6.
2.2.2.10 mallinfo
The Release 5 implementation of mallinfo is available only in libc.a.
2.2.2.11 nl_langinfo
The header file langinfo.h on Release 6 contains a larger set of manifest constants than the same header file on Release 5. A portable application should only expect the constants that are defined on both systems to be available.
The additional constants defined on Release 6 in langinfo.h are:
#define _MAXSTRMSG 57 /* Maximum number of strings in langinfo */ #define QUITSTR 58 /* "yes, go away" answer */ #define QUITEXPR 59 /* "go away" response ERE string */ #define DATECMD_FMT 60 /* format string used by date(1) */ #define CHARCLASS 61 /* all valid wctype() strings, ;-separated */Also, some constants are defined with different values; these are managed by the Release 6 kernel for OSR5 ABI applications.
2.2.2.12 passwd structure
Several routines make use of the passwd structure defined in pwd.h. This structure contains two members (pw_uid and pw_gid) whose types (uid_t and gid_t, respectively) are defined differently depending on the operating system.
On Release 6, uid_t and gid_t are both defined as long; on Release 5, they are both unsigned short. The Release 5 implementation makes up for this difference by adding two pad fields to the passwd structure, as shown below:
uid_t pw_uid; /* user ID */ short __pad1; /* padded space */ gid_t pw_gid; /* group ID */ short __pad2; /* padded space */2.2.2.13 sigset_t
On Release 5, the sigset_t data type (use by the functions sigaddset, sigdelset, sigemptyset, sigfillset, and sigismember) is declared a long in sys/signal.h. On Release 6, it is declared as follows:
typedef struct { /* signal set type */ unsigned int sa_sigbits[4]; } sigset_t;The Release 6 kernel will put data from an OSR5 ABI binary into the Release 6 structure before executing the function.
Also see "setcontext(2)" on page 32.
2.2.2.14 sysconf
The following Release 5 sysconf commands are not supported on Release 6:
_SC_32BIT_INODES _SC_FSYNC _SC_KERNEL_PROC _SC_KERNEL_PROC_MAX _SC_KERNEL_REGION _SC_KERNEL_REGION_MAX _SC_KERNEL_FILE _SC_KERNEL_FILE_MAX _SC_KERNEL_INODE _SC_KERNEL_INODE_MAX _SC_KERNEL_S5INODE _SC_KERNEL_S5INODE_MAX _SC_KERNEL_DISK _SC_KERNEL_DISK_MAX _SC_KERNEL_CLIST _SC_KERNEL_CLIST_MAX _SC_KERNEL_DMABUF _SC_KERNEL_DMABUF_MAX _SC_KERNEL_MOUNT _SC_KERNEL_MOUNT_MAX _SC_KERNEL_FLCKREC _SC_KERNEL_FLCKREC_MAX _SC_KERNEL_PINODE _SC_KERNEL_PINODE_MAX _SC_MAPPED_FILES2.2.2.15 ttyslot
The file accessed by ttyslot on Release 5 is /var/utmp, while on Release 6 it is /var/adm/utmp. For OSR5 ABI binaries on Release 6, the kernel directs the program to the proper file.
2.2.3 BSD library (libucb) interface
The BSD Compatibility library (libucb) is present on SCO OpenServer 6, but it is usually not needed since many of the functions in this library are now in the native Release 6 libraries as well.
2.2.4 Threads and asynchronous I/O (libthread) interfaces
POSIX threads (libpthread) are documented on the Section PTHREAD manual pages.
The SVR5 threads library interfaces (libthread), which include the asynchronous I/O routines, are documented in the Section THREAD manual pages and Section AIO manual pages. Note that the asynchronous I/O routines on Release 5 that correspond to the routines documented in the Release 6 Section AIO manual pages, are part of libsuds on Release 5, and are not supported for OSR5 ABI binaries running on Release 6. The libsuds library and its versions of these routines are also not supported by the SVR5 ABI.
2.2.5 Network support library (libnsl) interfaces
2.2.5.1 AUTH structure
The AUTH structure (see /usr/include/rpc/auth.h) has an extra element (a des_block structure) that is not in the Release 5 implementation.
2.2.5.2 CLIENT structure
The CLIENT structure (see /usr/include/rpc/clnt.h) has elements not in the Release 5 implementation.
2.2.5.3 Berkeley style client calls
These calls (callrpc, clnttcp_create, clntudp_create, clntudp_bufcreate, and clntraw_create) are present in libnsl on Release 6 for compatibility only and are undocumented. To compile a program that uses them, you must include the /usr/include/rpc/clnt_soc.h header file. On Release 6 these client interfaces are replaced by the rpc_clnt_create(S) interfaces.
These calls also access the CLIENT structure; see above.
2.2.5.4 Portmapper
These interfaces (pmap_set, pmap_unset, pmap_rmtcall, pmap_getmaps, pmap_getport, and clnt_broadcast) are present in libnsl on Release 6 for compatibility only and are undocumented. To compile a program that uses them, you must include the /usr/include/rpc/pmap_clnt.h header file. On Release 6, the rpcbind(S) interfaces replace the portmapper interfaces.
2.2.5.5 Berkeley style service calls
These calls (svcfd_create, svcraw_create, svctcp_create, svcudp_bufcreate, svcudp_create, and svcudp_enablecache) are present in libnsl on Release 6 for compatibility only and are undocumented. To compile a program that uses them, you must include the /usr/include/rpc/svc_soc.h header file. On Release 6 these client interfaces are replaced by the rpc_svc_create(S) interfaces.
These calls also access the SVCXPRT structure; see below
2.2.5.6 SVCXPRT structure
The SVCXPRT structure (see /usr/include/rpc/svc.h) has elements not in the Release 5 implementation. This affects the folowing routines: svcerr_auth, svcerr_decode, svcerr_noproc, svcerr_noprog, svcerr_progvers, svcerr_systemerr, and svcerr_weakauth.
2.2.6 Transport interface (XTI and TLI)
SCO OpenServer Release 5 and Release 6 both support the X/Open Transport Interface (XTI) and the Transport Level Interface (TLI). Both XTI and TLI are APIs that allow user processes to access transport providers in a (mostly) transport-independent fashion.
The Transport Level Interface was modeled after the industry standard ISO Transport Service Definition (ISO 8072). The resulting interface was called the Transport Level Interface (TLI) library, first introduced with AT&T UNIX System V Release 3.0 in 1986.
XTI is the X/Open-sponsored successor to TLI, and is defined in the Networking Services, Issue 5 document.
From the standpoint of syntax and semantics, the two libraries are nearly identical, but XTI is the preferred interface for new applications, since it is the industry standard. The TLI library routines are maintained for compatibility with previous releases only.
The Release 6 transport level functions are defined in libnsl and support both the older TLI semantics and the newer XTI semantics. The library entry points have their traditional names for the TLI functions, such as t_open. For the XTI functions, however, the entry points have new names, such as _xti_open. When applications are compiled with the SVR5 ABI, the TLI function names are translated to the XTI entry points by macros by including the file xti.h in the source code.
In this way, Release 6 is able to support older applications that use the TLI interface, while still providing the new XTI interface.
To compile and link a program using XTI semantics, do the following:
- Include the xti.h header file at the beginning of your source files. The syntax of the include preprocessor directive to use is:
#include <xti.h>- Specify the libnsl library as one of the libraries to be searched on the cc command line:
cc option file -lnslTo compile a program using the TLI interfaces exclusively, include the TLI header file (tiuser.h) instead of the XTI header file. The syntax of the include preprocessor directive to use is:
#include <tiuser.h>2.2.7 Sockets interface
SCO OpenServer Release 5 and Release 6 support the sockets interface. Although there are many similarities between the implementations, the differences are significant enough that a compatibility library is provided in /osr5/usr/lib so that OSR5 ABI binaries can run on Release 6 without modification.
The default action on Release 6 is UNIX95 sockets behavior; this essentially translates to linking with /usr/lib/libsocket.so.2.
To compile and link a program using SVR5 sockets, do the following:
- Include the following header files at the beginning of your source files. The syntax of the include preprocessor directives to use are:
#include <netdb.h> #include <sys/types.h> #include <sys/socket.h> #include <net/if.h> #include <netinet/in.h> #include <netinet/if_ether.h>2. Specify the libsocket and libnsl libraries as two of the libraries to be searched on the cc command line, in the order shown:
cc -lsocket -lnsl ...cc -lxnet ...2.2.7.1 Socket addressing
The type of socket address structure passed to a socket routine depends on the address and protocol families used by your application.
2.2.7.2 accept
In Release 5, the *addrlen parameter is an int. In Release 6, it is declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
Release 5 can return EFAULT (the addr parameter is not in a writable part of the user address space), which is not returned by Release 6.
2.2.7.3 bind
In Release 5, the *namelen parameter is an int. In Release 6, it is declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
Release 5 can return EFAULT (the name parameter is not in a valid part of the user address space), which is not returned by Release 6.
2.2.7.4 connect
In Release 5, the third parameter is called *namelen and is an int. In Release 6, it is called *address_len and is declared as size_t. The parameters have the same use (i.e., they contain the length of the previous calling parameter).
Release 6 can return these additional errors (which are not returned by Release 5):
2.2.7.5 ether_aton
This returns an ether_addr_t (unsigned char) on Release 6, while it returns an ether_addr structure (which has one member of type ether_addr_t) on Release 5.
2.2.7.6 ether_hostton
This function takes an ether_addr_t (unsigned char) parameter on Release 6, while it takes an ether_addr structure (which has one member of type ether_addr_t) on Release 5.
2.2.7.7 ether_line
This function takes an ether_addr_t (unsigned char) parameter on Release 6, while it takes an ether_addr structure (which has one member of type ether_addr_t) on Release 5.
2.2.7.8 ether_ntoa
This function takes an ether_addr_t (unsigned char) parameter on Release 6, while it takes an ether_addr structure (which has one member of type ether_addr_t) on Release 5.
2.2.7.9 ether_ntohost
This function takes an ether_addr_t (unsigned char) parameter on Release 6, while it takes an ether_addr structure (which has one member of type ether_addr_t) on Release 5.
2.2.7.10 ftruncate/truncate
These functions appear as system calls in libc on Release 6 and Release 5; Release 5 also provides versions of these in the sockets library.
2.2.7.11 getpeername/setpeername
In Release 5, the *namelen parameter is an int. In Release 6, it is declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
ENOMEM There was insufficient user memory for the operation to complete. ENOSR There were insufficient STREAMS resources for the operation to complete. EINVAL The socket has been shut down. 2.2.7.12 getsockname/setsockname
In Release 5, the *namelen parameter is an int. In Release 6, it is declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
2.2.7.13 getsockopt/setsockopt
In Release 5, the *optlen parameter is an int. In Release 6, it is declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
ENOMEM There was insufficient user memory for the operation to complete. ENOSR There were insufficient STREAMS resources for the operation to complete. The following options are provided on Release 5, but are not supported on Release 6:
SO_REUSEPORT toggle on/off local port reuse SO_SNDLOWAT set low-water mark for output SO_RCVLOWAT set low-water mark for input SO_PROTOTYPE get/set the protocol number associated with the stream 2.2.7.14 gettimeofday/settimeofday
These routines are implemented as system calls in Release 6. On Release 5, they are implemented as routines in the libsocket library, as well as system calls (in libc).
The syntax of the system call on Release 6 is:
#include <sys/time.h> int gettimeofday(struct timeval *tp, void *reserved); int settimeofday(struct timeval *tp, void *reserved);where the second parameter is required to be NULL.
On Release 5, the system call syntax is:
#include <sys/time.h> int gettimeofday(struct timeval *tp); int settimeofday(struct timeval *tp);The Release 5 libsocket routine's syntax is:
#include <sys/time.h> int gettimeofday(struct timeval *tp , struct timezone *tpz); int settimeofday(struct timeval *tp , struct timezone *tpz);The timeval structures used are the same on each platform; but the timezone structure is unique to the Release 5 libsocket routines (and any data it contains is ignored on the other platforms):
struct timezone { int tz_minuteswest; /* of Greewich */ int tz_dsttime; /* type of dst correction to apply */ };2.2.7.15 listen
Release 6 can return these additional errors (which are not returned by Release 5):
2.2.7.16 netgroup
The netgroup routines (endnetgrent, getnegrent, setnetgrent, innetgr) on Release 5 require that the Network Information Service (NIS) is running for these routines to return successfully.
This is not a requirement on Release 5, on which these routines also check the file /etc/netgroup for network group information.
2.2.7.17 recv/recvfrom/recvmsg
- The recvmsg call uses a msghdr structure to minimize the number of directly supplied parameters. The Release 6 structure is defined in sys/socket.h and includes the following members:
void * msg_name; /* optional address */ size_t msg_namelen; /* size of address */ struct iovec * msg_iov; /* scatter/gather array */ int msg_iovlen; /* number of elements in msg_iov */ void * msg_accrights; /* access rights sent/received */ int msg_accrightslen; void * msg_control; size_t msgcontrollen; int msg_flags;
- In Release 5, this structure is defined as follows:
caddr_t msg_name; /* optional address */ int msg_namelen; /* size of address */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* # elements in msg_iov */ caddr_t msg_control; /* control information sent/received */ int msg_controllen; /* size of control information */ int msg_flags; /* size of control information */
- The use of the cmsghdr structure for control data along with the CMSG macros are supported in Release 5 and Release 6. In Release 5 the cmsghdr structure is defined as:
int cmsg_level; /* originating protocol */ int cmsg_type; /* protocol-specific type */ u_int cmsg_len; /* data byte count, including hdr */
- In Release 6 the cmsghdr structure is defined as:
size_t cmsg_len; /* data byte count, including hdr */ int cmsg_level; /* originating protocol */ int cmsg_type; /* protocol-specific type */
- Release 6 can return these additional errors (not returned on Release 5):
2.2.7.18 select
On Release 5, the FD_SETSIZE constant is normally defined in sys/types.h as either 150 or 11000; on Release 6, the value of FD_SETSIZE is 4096. See select(S).
2.2.7.19 send/sendto
In Release 5, the *len and *tolen meters are int values. In Release 6, they are declared as size_t.
Release 6 can return these additional errors (which are not returned by Release 5):
See ``recv/recvfrom/recvmsg'' for a description of platform differences in the msghdr structure.
2.2.7.20 shutdown
Release 6 can return these additional errors (which are not returned by Release 5):
2.2.7.21 socket
Release 6 can return these additional errors (which are not returned by Release 5):
ENOMEM Insufficient user memory is available. EPROTONOSUPPORT Protocol not supported. EMFILE The system file table is full. (Release 5 returns ENFILE instead.) Release 5 can return these additional errors (which are not returned by Release 6):
ENFILE The system file table is full. (Release 6 returns EMFILE instead.) The protocol families and types differ between the systems. On Release 6, the AF_INET6 and PF_KEY protocol families are supported, in addition to the AF_UNIX and AF_INET protocol families supported on Release 5.
Release 6 supports the SOCK_STREAM, SOCK_DGRAM, SOCK_RAW, SOCK_SEQPACKET, and SOCK_RDM socket types; Release 5 supports only SOCK_STREAM, SOCK_DGRAM, and SOCK_RAW.
2.2.7.22 openlog
On Release 5, /usr/include/sys/syslog.h contains the following facilities definitions:
#define LOG_CRON (9<<3) /* clock daemon */ #define LOG_AUTHPRIV (10<<3) /* security/authorization msgs (private) */On Release 6, the above lines are omitted, and the following appear instead:
#define LOG_LFMT (14<<3) /* logalert facility */ #define LOG_CRON (15<<3) /* cron/at subsystem */2.2.8 Name resolution (libresolv) library routines
The resolver library routines in Release 6 are based on the BIND 9 distribution. For OSR5 ABI applications there are no compatibility impacts beyond the relocation of the routines from libsocket to the libresolv library, which is a concern for source code compilation on Release 6 only.
There are differences in resolver options and the _res data structure that holds them that span the use of most of these routines. These impact source compatibility for SCO OpenServer Release 5 applications being recoded to use the SVR5 ABI.
2.2.9 File transfer protocol (ftp) interface
SCO OpenServer Release 5 and Release 6 support the Internet file transfer protocol (FTP) interface developed for SCO OpenServer; this interface is defined in /usr/lib/libftp.so. Source code that uses this interface will compile on Release 6 without any changes.
To compile and link a program that uses the FTP interface, do the following:
- Include the libftp.h header file at the beginning of your source files. The syntax of the include preprocessor directive to use is:
#include <net/libftp.h>- Specify the libftp library as one of the libraries to be searched on the cc command line:
cc options file -lftp2.2.10 STREAMS interface
The STREAMS interface on SCO OpenServer Release 5 and Release 6 are fundamentally the same, with the major differences in the stream head ioctl commands.
On all systems, STREAMS the interface is implemented through a set of system calls and ioctl commands (issued using the ioctl system call).
Note that applications compiled with the SCO OpenServer Development System must define _SVID3 in the source in order to use the following ioctl commands:
I_ATMARK I_CANPUT I_CKBAND I_FLUSHBAND I_GETBAND I_GETCLTIME I_GWROPT I_LIST I_PLINK I_PUNLINK I_SETCLTIME I_SWROPT2.2.10.1 I_GETCLTIME
This ioctl returns the close time delay in a long on Release 6; on Release 5 it is returned in an int.
2.2.10.2 I_RECVFD
The uid and gid members of the strrecvfd structure are defined as uid_t and gid_t (that is, long) on Release 6; on Release 5 they are both defined as an unsigned short.
2.2.10.3 I_S_RECVFD
This ioctl command is not supported on Release 5.
2.2.10.4 I_SETSIG
For the S_BANDBURG event subcommand, Release 6 returns SIGURG, while Release 5 returns SIGUSR1.
2.2.11 Event queue (libevent) interface
The Release 6 event library (libevent.so) is a direct port of the SCO OpenServer Release 5 event API, which allows applications to obtain device events directly.
Essentially, these routines allow a program to manage device events through an event queue. Devices such as mice or keyboards may be read through an event queue. For more information, see the manual pages for the ev_* (ev_block, ev_init, etc.) routines in Section S-osr5.
The event interface is not part of any current industry standard.
2.2.12 SNMP (libsnmp) interface
The version of libsnmp supported on Release 6 implements SNMP Version 1 (SNMPv1).
The Release 5 version of libsnmp (included in /osr5/usr/lib) is supported on Release 6 for Release 5 binaries only. By default, the Release 5 library implements SNMP Version 2 (SNMPv2), unless the application is compiled with either SNMPV1 or SNMPV1_ONLY set.
The header files for SNMP are found in /usr/include/snmp on Release 5, and in /usr/include/netmgt on Release 6.
Source compatibility for every one of these calls is affected by differences in the data structures used by the SCO OpenServer Release 5 and Release 6 implementations. See the following sections for details:
``Object identifier (OID) structure''
``Object type (OT) structure''
``SCO OpenServer 64 bit counters''
2.2.12.1 make_varbind
The implementation of make_varbind on Release 5 is as follows:
VarBindList make_varbind(OID oid_ptr, short type, unsigned long ul_value, long sl_value, OctetString os_value, OID oid_value, Counter64 *c64_value);The Counter64 data type as well as the *c64_value parameter to this function are not supported on Release 6.
There are differences in VarBindList types and error returns between SCO OpenServer Release 6 and Release 5 that impact source compatibility. The Release 5 definitions in snmp.h are:
/* Universal's */ #define INTEGER_TYPE 0x02 #define GET_REQUEST_TYPE 0xA0 #define GET_NEXT_REQUEST_TYPE 0xA1 #define GET_RESPONSE_TYPE 0xA2 #define SET_REQUEST_TYPE 0xA3 #define TRAP_TYPE 0xA4 /* obsolete */ #define GET_BULK_REQUEST_TYPE 0xA5 #define INFORM_REQUEST_TYPE 0xA6 #define V2_TRAP_TYPE 0xA7 #define BITSTRING_TYPE 0x03 #define OCTET_PRIM_TYPE 0x04 #define DisplayString OCTET_PRIM_TYPE #define NULL_TYPE 0x05 #define OBJECT_ID_TYPE 0x06 #define OCTET_CONSTRUCT_TYPE 0x24 #define SEQUENCE_TYPE 0x30 #define Aggregate 0xFF /* Primitive context's */ #define NO_SUCH_OBJECT 0x80 #define NO_SUCH_INSTANCE 0x81 #define END_OF_MIB_VIEW 0x82 /* Application's */ #define IP_ADDR_PRIM_TYPE 0x40 #define COUNTER_TYPE 0x41 #define GAUGE_TYPE 0x42 #define TIME_TICKS_TYPE 0x43 #define OPAQUE_PRIM_TYPE 0x44 #define IP_ADDR_CONSTRUCT_TYPE 0x60 #define OPAQUE_CONSTRUCT_TYPE 0x64 #define NSAP_ADDR_TYPE 0x45 #define COUNTER64_TYPE 0x46 #define UINTEGER_TYPE 0x47 /* SNMPv2 message related types */ #define PRIV_MSG_TYPE 0xA1 #define PRIV_DATA_TYPE 0x81 #define AUTH_MSG_TYPE 0xA1 #define MD5_AUTH_INFO_TYPE 0xA2 #define NO_AUTH_INFO_TYPE 0x04 #define MGMT_COM_TYPE 0xA2 /* Application's SMUX */ #define SMUX__PDUs_simple 0x60 #define SMUX__PDUs_close 0x41 #define SMUX__PDUs_registerRequest 0x62 #define SMUX__PDUs_registerResponse 0x43 #define SMUX__PDUs_get__request 0xA0 #define SMUX__PDUs_get__next__request 0xA1 #define SMUX__PDUs_get__response 0xA2 #define SMUX__PDUs_set__request 0xA3 #define SMUX__PDUs_trap 0xA4 #define SMUX__PDUs_commitOrRollback 0x44 /* Error codes */ #define NO_ERROR 0 #define TOO_BIG_ERROR 1 #define NO_SUCH_NAME_ERROR 2 #define BAD_VALUE_ERROR 3 #define READ_ONLY_ERROR 4 #define GEN_ERROR 5 #define NO_ACCESS 6 #define WRONG_TYPE 7 #define WRONG_LENGTH 8 #define WRONG_ENCODING 9 #define WRONG_VALUE 10 #define NO_CREATION 11 #define INCONSISTENT_VALUE 12 #define RESOURCE_UNAVAILABLE 13 #define COMMIT_FAILED 14 #define UNDO_FAILED 15 #define AUTHORIZATION_ERROR 16 #define NOT_WRITEABLE 17 #define INCONSISTENT_NAME 18The Release 6 definitions (from /usr/include/netmgt/snmp.h) are:
/* Universal's */ #define INTEGER_TYPE 0x02 #define OCTET_PRIM_TYPE 0x04 #define DisplayString OCTET_PRIM_TYPE #define NULL_TYPE 0x05 #define OBJECT_ID_TYPE 0x06 #define OCTET_CONSTRUCT_TYPE 0x24 #define SEQUENCE_TYPE 0x30 #define Aggregate 0xFF /* Application's */ #define IP_ADDR_PRIM_TYPE 0x40 #define COUNTER_TYPE 0x41 #define GAUGE_TYPE 0x42 #define TIME_TICKS_TYPE 0x43 #define OPAQUE_PRIM_TYPE 0x44 #define IP_ADDR_CONSTRUCT_TYPE 0x60 #define OPAQUE_CONSTRUCT_TYPE 0x64 /* Context's */ #define GET_REQUEST_TYPE 0xA0 #define GET_NEXT_REQUEST_TYPE 0xA1 #define GET_RESPONSE_TYPE 0xA2 #define SET_REQUEST_TYPE 0xA3 #define TRAP_TYPE 0xA4 /* Application's SMUX */ #define SMUX__PDUs_simple 0x60 #define SMUX__PDUs_close 0x41 #define SMUX__PDUs_registerRequest 0x62 #define SMUX__PDUs_registerResponse 0x43 #define SMUX__PDUs_get__request 0xA0 #define SMUX__PDUs_get__next__request 0xA1 #define SMUX_GET_REQUEST_TYPE GET_REQUEST_TYPE #define SMUX_GET_NEXT_REQUEST_TYPE GET_NEXT_REQUEST_TYPE #define SMUX_GET_RESPONSE_TYPE GET_RESPONSE_TYPE #define SMUX_SET_REQUEST_TYPE SET_REQUEST_TYPE #define SMUX_TRAP_TYPE TRAP_TYPE #define SMUX__PDUs_get__response 0xA2 #define SMUX__PDUs_set__request 0xA3 #define SMUX__PDUs_trap 0xA4 #define SMUX__PDUs_commitOrRollback 0x44 #define SMUX_SIMPLE_TYPE 0x60 #define SMUX_CLOSE_TYPE 0x41 #define SMUX_REG_REQUEST_TYPE 0x62 #define SMUX_REG_RESPONSE_TYPE 0x43 #define SMUX_SOUT_TYPE 0x44 /* Error codes */ #define NO_ERROR 0 #define TOO_BIG_ERROR 1 #define NO_SUCH_NAME_ERROR 2 #define BAD_VALUE_ERROR 3 #define READ_ONLY_ERROR 4 #define GEN_ERROR 52.2.12.2 parse_pdu
On Release 5, the parse_pdu routine is passed a packet and length argument, as follows:
Pdu *parse_pdu(u_char **packet, long *length)On Release 6, it is passed an AuthHeader structure:
Pdu *parse_pdu(AuthHeader *auth_ptr); typedef struct _AuthHeader { OctetString *packlet; unsigned long version; OctetString *community; } AuthHeader;The routines are identical for applications compiled on Release 5 with SNMPV1 or SNMPV1_ONLY set.
2.2.13 SNMP I/O (libsnmpio) interface
The version of libsnmpio supported on Release 6 implements SNMPv1.
The Release 5 version of libsnmpio (included in /osr5/usr/lib) is supported on Release 6 for Release 5 binaries only.
The header files for SNMP are found in /usr/include/snmp on Release 5, and in /usr/include/netmgt on Release 6.
2.2.13.1 get_response
This routine is defined on Release 5 as follows:
int get_response(fd, src, in_packet, in_packet_len, timeout); int fd; struct sockaddr_in *src; u_char *in_packet; long *in_packet_len; int timeout;It is defined on Release 6 as:
int get_response(int seconds);This routine is defined on Release 5 as follows:
int initialize_io(program_name, name, sin); char *program_name; char *name; struct sockaddr_in *sin;It is defined on Release 6 as:
void initialize_io(char program_name, char name);2.2.13.2 send_request
This routine is defined on Release 5 as follows:
int send_request(fd, dst, out_packet, out_packet_len); int fd; struct sockaddr_in *dst; u_char *out_packet; long out_packet_len;It is defined on Release 6 as:
int send_request(int socket, AuthHeader auth_pointer);2.2.14 SMUX (libsmux) interface
The version of libsmux supported on Release 6 implements SNMPv1.
The Release 5 version of libsmux (included in /osr5/usr/lib) is supported on Release 6 for Release 5 binaries only.
The header files for SNMP are found in /usr/include/snmp on Release 5, and in /usr/include/netmgt on Release 6.
Source compatibility for every one of these calls is affected by differences in the data structures used by the Release 5 and Release 6 implementations. See the following sections for details:
``Object identifier (OID) structure''
``Object type (OT) structure''
``SCO OpenServer 64 bit counters''
2.2.14.1 Object identifier (OID) structure
On Release 5, the length element of the OID structure is a long, on Release 6 it is a short.
2.2.14.2 Object type (OT) structure
The object_type (OT) structure is defined differently on Release 5 and Release 6.
The OT structure on Release 5 is defined as follows:
typedef struct object_type { char *ot_text; /* OBJECT DESCRIPTOR */ char *ot_id; /* OBJECT IDENTIFIER */ OID ot_name; /* .. */ OS ot_syntax; /* SYNTAX */ int ot_access; /* ACCESS */ #define OT_NONE 0x00 #define OT_RDONLY 0x01 #define OT_WRONLY 0x02 #define OT_RDWRITE (OT_RDONLY | OT_WRONLY) #define OT_RDCREAT (0x04 | OT_RDWRITE) u_long ot_views; /* for views */ int ot_status; /* STATUS */ #define OT_NONE 0x00 #define OT_OBSOLETE 0x01 #define OT_CURRENT 0x02 #define OT_OPTIONAL 0x03 #define OT_DEPRECATED 0x04 caddr_t ot_info; /* object information */ ot_getfunc ot_getfnx; /* get/get-next method */ ot_setfunc ot_setfnx; /* set method */ #define type_SNMP_PDUs_commit (-1) #define type_SNMP_PDUs_rollback (-2) caddr_t ot_save; /* for set method */ int ot_range; /* close enough */ int ot_lendpoint; /* .. */ int ot_rendpoint; /* .. */ char *ot_index; /* INDEX */ char *ot_augments; /* or AUGMENTS */ caddr_t ot_iit; /* .. */ caddr_t ot_smux; /* for SMUX */ struct object_type *ot_chain; /* hash-bucket for text2obj */ struct object_type *ot_sibling; /* linked-list for name2obj */ struct object_type *ot_children; /* .. */ struct object_type *ot_next; /* linked-list for get-next */ } object_type, *OT;On Release 6, the structure is declared as follows:
typedef struct object_type { char *ot_text; /* OBJECT DESCRIPTOR */ char *ot_id; /* OBJECT IDENTIFIER */ OID ot_name; /* .. */ OS ot_syntax; /* SYNTAX */ int ot_access; /* ACCESS */ #define OT_NONE 0x00 #define OT_RDONLY 0x01 #define OT_WRONLY 0x02 #define OT_RDWRITE (OT_RDONLY | OT_WRONLY) unsigned long ot_views; /* for views */ int ot_status; /* STATUS */ #define OT_OBSOLETE 0x00 #define OT_MANDATORY 0x01 #define OT_OPTIONAL 0x02 #define OT_DEPRECATED 0x03 caddr_t ot_info; /* object information */ IFP ot_getfnx; /* get/get-next method */ IFP ot_setfnx; /* set method */ #define type_SNMP_PDUs_commit (-1) #define type_SNMP_PDUs_rollback (-2) caddr_t ot_save; /* for set method */ caddr_t ot_smux; /* for SMUX */ struct object_type *ot_chain; /* hash-bucket for text2obj */ struct object_type *ot_sibling;/* linked-list for name2obj */ struct object_type *ot_children; /* .. */ struct object_type *ot_next; /* linked-list for get-next */ } object_type, *OT;In addition, the OS structure has some extra elements on Release 5:
typedef struct syntax { char *os_name; /* syntax name */ int os_type; /* syntax type */ os_decode_func os_decode; /* PE -> data */ os_free_func os_free; /* free data */ char *os_textual; /* for textual conventions */ char *os_display; /* for textual conventions */ struct enum_syntax *os_enum; /* for enumerations */ } *OS;The Release 6 version of the OS structure is:
typedef struct object_syntax { char *os_name; /* syntax name */ int os_type; /* syntax type */ IFP os_decode; /* PE -> data */ IFP os_free; /* free data */ } *OS;2.2.14.3 SCO OpenServer 64 bit counters
Objects of type Counter64 and the Counter64 structure are not supported on Release 6, but are supported on Release 5.
The Release 5 ObjectSyntax structure has an extra c64_value element not supported on Release 6.
2.2.14.4 Aggregate structure notes
A number of aggregate structures, such as those listed below, are affected by changes to lowerlevel structures.
For example, the OI structure is declared identically in both Release 5 and Release 6; but the structure members are of type OID and OT, which do have implementation differences.
The affected data structures are:
- OI/OIDentifier
- all types of the form type_SNMP_VarBind, type_SNMP_VarBindList, type_SNMP_ObjectName, free_SNMP_ObjectName, type_SNMP_ObjectSyntax, and free_SNMP_ObjectSyntax and any structures declared of these types
- VarBindList and VarBindUnit
- Pdu, and all types ending in PDU and PDUs
See the header file /usr/include/netmgt/snmp.h and the sections ``Object identifier (OID) structure'', ``Object type (OT) structure'', and ``SCO OpenServer 64 bit counters''.
2.2.15 Termios and termio interfaces
The termios interface is the preferred API for terminal management functions; the termios calls are translated into ioctl calls that issue the appropriate commands for the given operation.
Applications should never directly issue ioctl commands to terminal devices, but should use the termios(S) functions instead. Binaries produced using the Release 5 compilers will get iBCS2-compatible behavior when run on Release 6.
Source code from Release 5 will need to be changed to use the termios structure supported on Release 6, which omits the c_line (line discipline) element supported on Release 5, and uses a different value for the number of elements in the control character (c_cc) array.
2.2.16 curses (libocurses) interface
On Release 6 and Release 5, the standard curses library is the UNIX System V Release 4 (SVR4) curses library, libcurses.a. OSR5 ABI binary applications that use the standard curses libraries on those systems will execute as expected on Release 6.
While all the same function names are supported and these functions all have the same semantics on the two systems, there are slight differences in the:
These are detailed in the next few sections.
2.2.16.1 curses header files
On Release 6, the SVR4 curses interfaces are defined in /usr/lib/ocurses.h.
On Release 5, curses.h is a wrapper that reads in either of tcap.h or tinfo.h, depending on whether the application is compiled with termcap or terminfo support (termcap is not supported on Release 6). Since most applications are simply compiled with #include curses.h, this should not present a compatibiliy problem unless the lower level header files are included directly.
2.2.16.2 terminfo and termcap databases
These files define terminal characteristics and are used by various libraries and programs (for example, the curses library routines and the vi editor) to perform screen management functions.
The location and format of the terminfo and termcap databases are the same on all systems.
There are no known compatibility impacts for these databases.
2.2.16.3 X/Open curses (formerly libstdcurses) library
This library (libocurses) is supported on Release 6, but not on Release 5.
2.2.17 BSD database management (libdbm and libndbm) interface
Release 5 provides database management routines in the libdbm and libndbm libraries. Release 5 binaries that use these libraries will load and run correctly on Release 6.
For more information on using BSD compatibility libraries on Release 6, see ``BSD system libraries and header files''.
2.2.18 Encryption (libcrypt) interface
The libcrypt interface is documented on crypt(S). The crypt, encrypt, and setkey routines are also declared in libgen and in libc.
2.2.19 Executable and Linking Format (libelf) interface
The libelf implementations on Release 5 and Release 6 are nearly identical, with the following exceptions:
- Release 6 provides an additional flag, ELF_C_IMPURE_WRITE, that can be passed to elf_begin(ELF). Portable applications and applications targeted for Release 5 should not use this flag, as it is not supported on Release 5.
- The nlist function is declared in libelf on Release 6 and libc on Release 5. For Release 5 applications run on Release 6, the Release 6 kernel uses the Release 5 libc.
The Release 6 libelf interface is documented on the Section ELF manual pages.
2.2.20 Graphic interfaces
- Graphical programs sometimes rely on Motif 2.x. This version of Motif is normally compatible with Motif 1.2 (included with SCO OpenServer 6). In case problems do occur, you can try using Lesstif (available from http://www.lesstif.org">http://www.lesstif.org).
- A lot of graphical GNU programs use the xpm package, support for which is not provided by SCO OpenServer 6. The best thing to do is download the xpm source and build it.
| |
|
|