A Practical Guide to Adopting the Solaris 8 OS: Part 3

Print-friendly Version

July 2000

Application Compatibility with Solaris 8

This section provides information on:

• Binary Compatibility

• Source Compatibility

• Application Environment Compatibility

• Application Localization

• Third-Party Application Compatibility

• Hardware Compatibility

• Useful Tools for Checking Application Compatibility

• Features Dropped from Previous Solaris Releases

Binary Compatibility

A common problem in evolving computing environments is ensuring that applications continue to run despite changes to the underlying system's infrastructure or environment (hardware and software). The following sections describe a methodology for defining a safe and stable system interface for applications, and then for checking application binaries to determine if they are relying on unstable system interfaces, which would put them at risk when the operating system is later upgraded.

Existing 32-bit SPARC applications are binary compatible and can run in either the 32-bit or 64-bit operating environment. The only exceptions are those that deal with kernel memory or /proc.

The Problem of Cross-Release Stability

When end users upgrade to a new release of the operating system, they are concerned about what happens to the applications and other layered software products that they use to run their businesses. Their desire is that all of their application binaries will run on the new system without change.

Without such release-to-release stability, or binary compatibility for applications, end users face a dilemma: even though each successive release of the system software may be desirable, upgrading may not be possible because a large investment has been made in the applications and one or more of these applications may fail to work on a new release. Consequently, application breakage is a serious problem for both software users and producers.

The System/Software Ecosystem

The figure shows the layering of dependencies between software products that form an overall system. Instability occurs when any product upon which other products depend is changed in a way that introduces an incompatibility.

Reasons for Application Breakage

There are two fundamental reasons for application breakage that are worth considering. First, the operating system has undermined one or more legitimate dependencies that existing applications had upon the system. Second, one or more applications relied on something that was not intended for their use and that internal part has now been changed in an incompatible way.

The basic solution to these problems is to identify clearly which interfaces are public and stable (that is, those constrained to strictly upward compatible change), and to restrict applications entirely to those stable interfaces.

To achieve this, the Solaris Application Binary Interface (ABI) Program provides a tool (appcert) to perform static checking of application binaries. This tool is presently used as a part of the process to certify Solaris applications.

See the section Useful Tools for Checking Application Compatibility of this white paper for more information.

Defining the Application Runtime Interface

An application gains access to system services in Solaris software by making procedure calls to interfaces in the system's shared libraries. Since every dynamically linked application must do this, this is the starting point used to define the Solaris ABI.

The ABI specifies, first at shared library level, and then at the level of global symbols within those shared libraries, which system shared objects are intended for application use. The ABI system model provides a complete list of interfaces available in the bundled Solaris product, thus describing the public (that is, stable and committed) and private (unstable) interfaces of a given release of Solaris, where the public constituent is an upward compatible evolution.

Solaris ABI definitions are provided intrinsically with the ABI-conformance checking tool appcert. In fact, appcert has already been successful at identifying private interface dependencies in certain commercial software products that did cause binary breakage going from one release of Solaris to the next.

More Information

Links:

• http://www.sun.com/developers/tools/abi/index.html

Other Documents:

• David J. Brown and Jarrett Rosenberg, "Static Checking of Application Binaries for Cross-Release Stability". Eleventh Int'l Software Quality Week, San Francisco. Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303

Source Compatibility

Source level compatibility has been maintained for 32-bit applications. For 64-bit applications, the principal changes pertain to the data types used in the application-programming interface.

32-bit applications will continue to run on either a 32-bit or 64-bit operating environment except those that deal with kernel memory or /proc. Device drivers and loadable modules have to be recompiled to be 64 bits compliant with a 64-bit kernel. See Making a Device Driver 64-bit Ready for more details.

Data Model

The C type data model chosen for Solaris 8 is LP64, where long pointers are 64 bits, hence LP64. The following table shows the 32-bit and 64-bit data model.

Following are the derived types recommended for use: blkcnt_t, id_t, major_T, minor_t, mode_t, pid_t, size_t, ssize_t, uid_t, uchar_t, blkcnt64_t, fsblkcnt_t, ino_t, off64_t, ino64_t.

Programmers need to be aware of this difference to make their applications work in both 32-bit and 64-bit environments.

Using Derived Types

In general, it is a good idea to use derived types for definitions to allow for changes. Moreover, using the Solaris system derived types will help make the code 32-bit and 64-bit safe, since the system derived types are themselves safe for both environments.

For source compatibility, recommended system include files are inttypes.h and sys/types.h. Both files contain constants, macros, and derived types that are helpful for making the code 32-bit and 64-bit safe.

More information on derived types can be found in Why 64-bits? in this white paper.

Loopholes to Look For

Many problems arise from longs or pointers changing size in LP64. First, unlike ILP32, the assumption that ints, longs, and pointers are the same size is no longer true. This change alone is the cause of most problems in making the existing code both 32-bit and 64-bit safe, because a lot of code assumes that ints and pointers, and ints and longs, are the same size.

Second, data structures involving longs and pointers have to be checked. Structures are aligned by their longest (largest) member. There may be a wasted space in structures because of alignment differences from long and pointer fields growing to 64 bits. Unions may no longer make sense because of the difference in size.

Third, declarations and casts are very important in showing what is intended; how expressions are evaluated may change since the types have changed. Type conversion rules are affected by the change in data sizes. To adequately show what is intended, even the types of constants should be declared. Casts may also be needed in expressions to make certain that the expression is evaluated the way the programmer meant. Some examples are described in 64-bit Application Support in this white paper.

The fourth reason for application breakage is changes in the header files. In Solaris 8, one such change has occured that may cause binary and, in some remote cases, source incompatibility issues. The header file ldap.h has been modified. The field struct ldapmod *mod_next has been removed to make libldap.so LDAP C-API compliant with the latest IETF draft. Also, the ldctl_value field in the ldapcontrol structure used to be a pointer to the structure berval. To make this structure compliant with the latest C-API draft, it is changed to struct berval ldctl_value. Applications that use these structures should be recompiled.

Application Environment Compatibility

This section discusses changes in the Solaris 8 operating environment that may affect some existing applications. It also covers the potential application compatibility issues that might surface when moving an application to the Solaris 8 operating environment.

The section Solaris 8 Features in this white paper details how and why your application can improve under Solaris 8.

How to Check your Application for Compatibility Issues

• Run the appcert utility on your binaries; refer to the section Useful Tools for Checking Application Compatibility, in this white paper. See also Appendix A, Sample Summary Report Produced by appcert.

• Run your binaries on Solaris 8 under the control of apptrace. The apptrace utility runs an executable program and traces all calls that the program makes to the Solaris shared libraries. For each call the program makes, apptrace reports the name of the library called, the arguments passed, and the return value, if applicable. This method will help you become more familiar with the Solaris function calls utilized by your application.

More Information

See Performance and Scalability Enhancements in this white paper.

Man Pages:

• appcert(1)

• apptrace(1)

• sotruss(1)

• truss(1)

New Device Nodes

There are new device nodes in Solaris 8. If applications depend on third-party device nodes, then the node names should be checked for conflicts with Solaris 8 device names.

Example of a new device node:

/dev/poll --> ../devices/pseudo/poll@0:poll 

This is a pseudo-device-node. There is a possible conflict if the application already uses a device named /dev/poll.

Possible solution: Rename the application's old /dev/poll device to another custom name, avoiding conflicts with new system device names.

More Information

Man Pages:

• devfsadm(1M)

• poll(7D)

Application Localization

Locale Names

In order to conform to industry standards for locale naming, it was necessary to rename some locales.

Applications accessing /usr/lib/locale/localename directly might not find old locale names. However, using setlocale() with an old name is still supported, so applications using setlocale() will still be supported.

Use the locale(1) command to display your current settings. If the locale strings under Solaris 8 have changed for your country, scan the application for the following function calls and check for conflicts in locale name usage.

• setlocale()

• localedef()

See Solaris 8 Locales for a complete list of Solaris 8 locales, with old and current names.

Locale Shared Objects for Properly Linking Applications

If the application build environment has hard-coded paths to locale shared objects, the .so file might not be found in the hard-coded location. For example:

/usr/lib/locale/localename/localename.so.version_number
(32-bit shared object)

/usr/lib/locale/localename/sparcv9/localename.so.version_number
(64-bit shared object)

Since the localename might change, it is better to query the current locale via setlocale() and derive the proper /usr/lib/locale/ directory. A common mistake is to assume that setlocale() will always return a pointer to a simple localename. The man page for setlocale(3C) states the following: "If there is a mixture of locales among the categories, setlocale() will return a (pointer to) composite locale."

The following is an example of a possible composite locale returned by setlocale():

/en_CA.ISO8859-1/en_CA.ISO8859-1/en_CA.ISO8859-1/en_CA.ISO8859-1/
en_CA.IO8859-1/C

More Information

Man Pages:

• locale(1)

• locale(5)

• setlocale(3C)

• localedef(1)

• localeconv(3C)

• environ(5) {LANG,LC_*}

New Message IDs

In Solaris 8, system messages written using the syslogd facility have a new field called message ID. The message ID generation capability is enabled by default in log.conf, as described below.

Example of message ID within a message written to /var/adm/messages:

Sep 29 21:41:18 cathy ufs: [ID 845546 kern.notice] alloc /: file 
system full

New field added to message: [ID 845546 kern.notice]

The System File /var/adm/messages

Applications parsing /var/adm/messages might require changes to handle the extra field, as noted above.

As a transition phase workaround only, the system administrator can disable message ID generation. This is accomplished by editing the driver configuration file /kernel/drv/log.conf, setting msgid=0. The change will take effect on the next system reboot. This property is unstable and may be removed in a future release.

More Information

Man Pages:

• syslogd(1M)

• log(7D)

• syslog.conf(4)

• msgid(1M)

IPv4 to IPv6 Transitioning

The following terms are helpful to understand transition issues:

• IPv4 - the traditional TCP/IP 32-bit addressing protocol.

• IPv6 - the new TCP/IP 128-bit addressing protocol.

• IPv4-only node - A host or router that implements only Ipv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers not yet upgraded to IPv6 are IPv4-only nodes.

• IPv6/IPv4 node - A host or router that implements both IPv4 and IPv6.

• Dual stack node - When you upgrade your hosts and routers to IPv6, they retain their IPv4 functionality to provide compatibility for all IPv4 protocols and applications. These hosts and routers are known as dual stack.

• /etc/hosts - The file that has been traditionally used to store host names and addresses (IPv4-only ). It remains for backwards compatibility.

• /etc/inet/ipnodes - The new file to store host names and addresses. It may contain both IPv4 and IPv6 addresses.

When you install Solaris 8 and enable IPv6, your host becomes a dual stack node. This means it will continue to support IPv4 host addresses, and in addition will support IPv6 host addresses. A dual stack node can communicate with an IPv4 node and an IPv6 node, and can identify packets as being IPv4 or IPv6. With a dual stack, existing IPv4 applications will continue to work seamlessly.

If you do not enable IPv6, your host becomes an IPv4-only node, and will support only IPv4 host addresses. That also means your host will communicate only with nodes that are IPv4 capable, in other words, traditional IPv4 nodes and dual stack nodes.

The proper way to access host information, such as host name, IP-address and aliases, is by using the correct Host Name Service API. For example:

struct hostent *gethostbyname(const char *name).

However, the gethost...() family of networking functions will only work for IPv4 host addresses. With Solaris 8, you now have a new, dual stack, getipnode...() family of networking functions. The new functions work for both IPv4 and IPv6 host addresses.

If your application accesses /etc/hosts directly (which is not good practice), it will support only IPv4 hosts, as before. Instead of changing your application to access /etc/inet/ipnodes directly (also not good practice), you should update your application to use the getipnode...() family of APIs, and have full access to both IPv4 and IPv6 host information.

Once the getipnode...() family has been used to replace or supplement the gethost...() family of APIs, it is recommended that you synchronize the IPv4 hosts database with the IPv4/IPv6 ipnodes database. This practice will prevent delays in host name resolution.

More Information

Links:

• Check the Solaris IPv6 FAQS (http://www.sun.com/software/solaris/ipv6/faqs.html) for optional transition mechanisms and other details.

Solaris 8 System Administrator Collection

• System Administration Guide, Volume 3 (Transitioning from Ipv4 to Ipv6; Implementing IPv6)

Man Pages:

• hosts(4), gethostbyname(3NSL), gethostbyaddr(3NSL), and so forth.

• ipnodes(4), getipnodebyname(3SOCKET), getipnodebyaddr(3SOCKET), and so forth.

See also IPv6 in the section Solaris 8 Features in this white paper.

ifconfig

If IPv6 is enabled in Solaris 8, the ifconfig -a command will report each host interface twice, once for the IPv4 address and a second time for IPv6.

Applications (and scripts) parsing the ifconfig -a output might have to be adjusted accordingly.

Perl (5.005_03) Bundled with Solaris

Solaris 8 includes Perl (/usr/bin/perl) as a convenience. Applications relying on a specific version of Perl might not find this version suitable, for example, if the application requires Perl features introduced after Perl Version 5.005_3.

Usually /usr/bin appears early in the application search PATH. That means the bundled perl binary will be found first, ahead of some other perl binary appearing later in the application search PATH.

Tip: If finding /usr/bin/perl ahead of another perl binary is a problem, change the application PATH to find the other perl ahead of /usr/bin/perl. If you instead rename and repeat symlink /usr/bin/perl, you will solve only a local problem, that is, one machine at a time, and the next operating system upgrade will probably overwrite your symlink.

If you have shell scripts using hard-coded paths to /usr/bin/perl (and #!/usr/bin/perl), change those accordingly, if required.

O/S Files and Directory Attributes

Most O/S files and directories have changed ownership and permissions:

• Default file and directory ownership changed from bin to root

• Previous default permissions of 775 changed to 755 - more restrictive

• Previous default permissions of 664 changed to 644 - more restrictive

Checking for Changed Files

Use the following procedure to check which files have changed:

1. Run this on the old host O/S (not Solaris 8):
   # find /etc -exec ls -lad {} \; | nawk '$3 != "root" {print}' |\
sort -k 9,9 | nawk '{print $1, $3, $4, $9}' \
> /var/tmp/etc_not_root.old

2. Now transfer /var/tmp/etc_not_root.old to the target (Solaris 8) host.

3. Repeat the find command as above on the target (Solaris 8) host, and redirect (>) to:
   /var/tmp/etc_not_root.new

4. Run diff on the two files:
   # diff /var/tmp/etc_not_root.old /var/tmp/etc_not_root.new

• Example of diff output:

  < drwxrwxr-x adm adm /etc/acct --- permissions have changed, see
                                     the corresponding ">" line.
  < -rw-rw-r-- bin bin /etc/acct/holidays --- owner changed to root
  < -rw-rw-r-- lp lp /etc/lp/fd/pr.fd     --- owner changed to root
  < -r--r--r-- bin bin /etc/mail/sendmail.cf -owner changed to root
  ...
  ---
  > drwxr-xr-x adm adm /etc/acct ----- only permissions have changed
  ...
  

5. Items preceded by "<" (that is, existing in .old only) now belong to root or have changed permissions or group.
   Items preceded by ">" (that is, existing in .new only) are new or have only changed permissions or group.
   Note: This example only checks the /etc directory tree. Substitute the directory name (immediately after the find keyword) to check other directory trees.

New Packages

New packages for Solaris 8 must adhere to the following rules:

• Directories and executables must have default permissions of 555 or 755.

• Regular files must have default permissions of 644 or 444.

• Setuid/setgid files cannot be writable by the owner unless the owner is root.

Potential Effect on Behaviour of pkgadd(1M):

When running pkgadd, if the package updates system directories, you might see a message stating that the directories in question are already installed and that the new attributes conflict. The following options are then offered:

It is rare that a package will set system directory permissions because the application requires it. That might not be a safe practice, which is why pkgadd gives warnings about conflicting files; after all, pkgadd runs as root.

To avoid such conflicts, new packages should change the pkgmap file to use "????" in the mode field, indicating that permissions should be left unchanged (the directory/file in question must already exist on the target machine).

Example of pkgmap using "????":

: 1 760 202
1 i copyright 59 5209 941836613 
1 i depend 374 28782 941836618 
1 i pkginfo 435 33930 941836710 
1 d none usr ???? root sys 
1 d none usr/bin ???? root bin 
1 f none usr/bin/audioconvert 0755 root staff 220752 51906 941828551 
1 f none usr/bin/audioplay 0755 root staff 109640 5526 941828542 
1 f none usr/bin/audiorecord 0755 root staff 27704 13586 941828547

More Information

Solaris 8 Software Developer Collection

• Application Packaging Developer's Guide

Man Pages:

• pkgproto(1)

• prototype(4)

• pkgmk(1)

• pkgadd(1M)

Obsolete Functionality Removed

Some obsolete features have been removed from Solaris. To review the features removed since Solaris 2.5.1, see the section Features Dropped from Previous Solaris Releases in this white paper.

Third-Party Application Compatibility

This section describes the various programs that are available to Independent Software Vendors (ISVs) to ensure their applications are Solaris 8 Ready.

The section Application Environment Compatibility in this white paper also applies to third-party applications. This means that potential incompatibilities with the Solaris 8 operating environment apply equally to applications developed in-house and applications developed by a third-party ISV.

Note: It is possible that some of the direct links provided below have changed since this document was written. In that case, go to http://www.sun.com and search by keyword.

Application Binary Interface Program

• For information on downloading and using the appcert tool, see Solaris ABI TOOLS at http://www.sun.com/developers/tools/abi/index.html. See also ABI Tools in this white paper.

Solaris Ready Logo Program

Solaris Ready is a very strict branding program. Applications that comply with the necessary criteria may use the Solaris Ready logo in packaging and advertising. You do not need the logo just to be able to run your application on Solaris 8.

Compliance with appcert is just one of the compliance criteria for the Solaris Ready logo.

• To learn more about the Solaris Ready logo program see http://www.sun.com/solarisready/.

• To register for the program, see http://www.keylabs.com/solarisready/registration.html. Your profile will enable Sun to provide your company with a private web site for all of your Solaris Ready verification needs. Sun has a team in place to support you by phone, email and the Web.

More Information

If you have a specific question about Solaris Ready programs, write to: solarisready@keylabs.com.

Hardware Compatibility

Hardware that does not run the Solaris 8 O/S

The sun4c, SPARCstation^TM Voyager, and SPARC Xterminal 1 platforms are not supported with Solaris 8. Attempts to install will produce the message: This hardware platform is not supported by this release of Solaris. Hardware models not supported are:

• SPARCstation 1, 1+, 2, ELC, SLC, IPC, IPX

• SPARCstation Voyager

• SPARC Xterminal 1

Useful Tools for Checking Application Compatibility

Migrating from one release of Solaris to the next provides certain challenges to Solaris users. Applications that use unstable "private" Solaris interfaces are at risk of failure if those particular interfaces change their syntax or semantics in a subsequent release of Solaris. Up until now, there has been no easy way to identify which applications might be at risk, or of determining the severity of that risk. Now, however, there are tools from the Solaris ABI Program that can greatly simplify this process. Using these tools will help programmers to find out if a binary or a shared object will run on the next release of Solaris.

One of the tools, appcert, will help to identify public and private interfaces used by programs under test. It can also identify demoted symbols (symbols that are removed from the current release) and unbound symbols (symbols that rely on the executables that link against them).

Public and Private Interfaces

Public interfaces are the standard interfaces such as System V Interface Definition (SVID) and Solaris interfaces such as those in libthread.so.1. These interfaces contribute to the total Solaris ABI.

Private interfaces are referred to as "internal to system implementation" and are not intended for use by applications or any other layered software product. These interfaces are subject to incompatible changes in subsequent minor releases of the library or the system release. These interfaces may become a public interface, remain an internal moving part, or disappear.

ABI Tools

The appcert tool is a Perl script that statistically examines Executable and Linking Format (ELF) binaries and their shared objects to see what Solaris library interfaces they use. It uses models of the Solaris ABI that extend from Solaris 2.3 to Solaris 8. Note that appcert only examines C language interfaces; other language bindings such as C++ and Java are not covered.

Running appcert

To run appcert, provide it with the name of one or more binaries to check, or one or more directories that contain the binaries to check. appcert will recursively examine subdirectories to locate binaries.

appcert first makes sure that the file is suitable for checking (it must have execute permissions set and not be suid root), then collects the binary symbols. These symbols are then checked against the model of public and private symbols for that library in that specific release of Solaris.

Interpreting appcert Output

Appendix A (Sample Summary Report Produced by appcert) contains a sample summary report from running appcert on a simple one-binary application (the sample program is used in this example).

The report header indicates which version of appcert generated the report; next, the name of the product being examined; the version of Solaris it was built on; and the version of Solaris it was checked against. This is followed by a summary of whether or not any potential binary stability problems were detected.

HTML versions of this summary and detailed reports are also generated, making it easy to go from summary report to detailed report.

Application Triage

The utility appcert can be used to quickly and easily divide a set of applications into those that have potential stability problems and those that do not. If appcert does report stability problems, the user needs to determine where the source of the problem is (sometimes it is due to static linking of a library, rather than to the application itself, in which case the solution is to dynamically link the library), and what type of problem it is. The following table lists a number of cases.

Note that appcert may report things that may not be real problems.

Always use the latest version of appcert, which is available from http://docs.sun.com.

More Information

Links:

http://www.sun.com/developers/tools/abi/index.html

Features Dropped from Previous Solaris Releases

Features Dropped by Solaris 8

The following features were dropped in Solaris 8. This section does not cover features that were obsoleted in Solaris 8 to be removed in a future release. For a complete list of dropped features and hardware, refer to the End-of-Software Support Statements at http://docs.sun.com under the Solaris 8 Release Documents Collection.

HotJava Browser

The HotJava Browser is no longer supported.

Solaris Java Development Kit: JNI 1.0 Interface

The 1.0 version of the Java Native Interface (JNI 1.0) is no longer supported by the Solaris Java Development Kit version 1.2 (JDK 1.2).

Support in the Solaris Java Development Kit (JDK) for the 1.0 version of the Java Native Interface (JNI 1.0) has been removed. JNI 1.0 is also known as the Native Method Interface (NMI).

Solstice AdminSuite 2.3/ AutoClient 2.1

Solstice AdminSuite 2.3 software is no longer supported with the Solaris 8 operating environment. Any attempt to run Solstice AdminSuite 2.3 to configure Solstice AutoClients or diskless clients will result in a failure for which no patch is available or planned. While it may be possible to manually edit configuration files to enable diskless clients, such an operation is not recommended or supported.

F3 Font Technology

F3 fonts and the TypeScaler rasterizer, Sun's proprietary scalable font technology, is no longer supported. Sun will continue to support the industry standard font formats Type1 and TrueType.

XGL

The XGL graphics API was declared obsolete in Solaris 7 and is no longer supported. XGL is being phased out in favor of the OpenGL industry standard. This will impact SunPHIGS applications since SunPHIGS is built on top of XGL.

Derived Type paddr_t

The paddr_t data type found in sys/types.h is not supported in the 64-bit compilation environment. It is currently only available in the 32-bit compilation environment. It has been removed from all other compilation environments.

Planned Changes to APIs for User Accounting Data

There are two sets of Application Programming Interfaces (APIs) that allow user accounting data to be accessed by applications. The preferred set of programming interfaces for accessing and manipulating user accounting information is described on the getutxent(3C) man page. These are both more capable and more portable than the older getutent(3C) routines.

Older applications may access the underlying accounting files directly. The files /var/adm/utmp and /var/adm/wtmp and the corresponding symbolic links /etc/utmp and /etc/wtmp are no longer supported. The format of the data contained in these files constrains the future evolution of the Solaris operating environment. Applications using these files should be updated to use the documented and supported APIs.

Applications that are already using the getutent(3C) family of routines may be unaffected on small system configurations. However, in future releases these interfaces may return errors when used on very large system configurations. For this reason, use the getutxent(3C) routines for both old and new code in place of the getutent(3C) APIs.

The sysidnis System Identification Program

sysidnis(1M) is no longer supported. sysidnis(1M) is the system identification program responsible for configuring name services during installation and upgrade, and after unconfiguration using sys-unconfig(1M).

sysidnis(1M) has been replaced by sysidns(1M).

x86 Architecture Only: Console Subsystem

The console subsystem for the Solaris operating environment running on an x86 (IA) based system has been replaced. The replacement is more compatible with the console subsystem for the Solaris operating environment running on a SPARC-based system and provides for future extensibility. This replacement has invalidated a large number of undocumented and unsupported interfaces, as well as some documented interfaces.

Documented interfaces:

• pcmapkeys(1)

• loadfont(1)

• loadfont(4)

Undocumented and unsupported interfaces:

• ioctls listed in /usr/include/sys/kd.h

• ioctls listed in /usr/include/sys/vt.h

• VT support

• /dev/vt*

• The terminal type for the console is no longer "AT386"; it is now "sun-color".

sysmem(3), asysmem(3)

The sysmem and asysmem routines were declared obsolete in Solaris 2.5.1 and have been replaced by arguments to sysconf(3C). They were mistakenly published in the System V Interface Definition, Third Edition, (SVID).

nis_db(3N)

The nis_db(3N) interface provided NIS+ database access functions and was declared obsolete in Solaris 2.6. It has now been removed in Solaris 8. The shared object libnisdb.so should not be used by any user application. The list of interfaces includes:

• db_add_entry(3N)

• db_checkpoint(3N)

• db_create_table(3N)

• db_first_entry(3N)

• db_list_entries(3N)

• db_remove_entry(3N)

• db_standby(3N)

• db_unload_table(3N)

• db_table_exists(3N)

• db_reset_next_entry(3N)

• db_initialize(3N)

• db_free_result(3N)

• db_destroy_table(3N)

• db_next_entry(3N)

SPARCstation Voyager

The following interfaces have been removed since SPARCstation Voyager systems are no longer supported.

• mic(7D)

• pmc(7D)

• contrast(1M)

mount -o f Option

The -o f option has been removed from the ufs and udfs mount commands. The f option was used to execute a "fake" mount, which caused an entry to be written to /etc/mnttab, but no actual mount to occur (that is, the mount(2) system call is not executed).

Features Dropped by Solaris 7

The following list only covers dropped features. This list does not include features that were obsoleted in Solaris 7 to be removed some time in the future. For a complete list of dropped features and hardware, refer to the End-of-Software Support Statements at http://docs.sun.com under the Solaris 7 Release Documents Collection.

• The Solaris PEX runtime libraries and development environment are no longer supported.

• SYMON is no longer bundled.

• Platforms based on the Intel 80386 chip are no longer supported.

• IBM PS/2 Personal Computers and PC Server systems with the IBM Micro Channel Bus Architecture are no longer supported.

• Micro Channel systems and devices are no longer supported.

Features Dropped by Solaris 2.6

The following features were dropped in Solaris 2.6. This section does not cover features that were obsoleted in Solaris 2.6 to be removed in a future release. For a complete list of dropped features and hardware, refer to the End-of-Software Support Statements at http://docs.sun.com under the Solaris 2.6 Release Documents Collection.

Dataless Clients

Support for the dataless client system type is no longer available in Solaris 2.6. Customers currently using this system type are advised to convert existing dataless systems to the diskless, standalone, server, or Solstice AutoClient system type.

NeWSprint and NeWSprint-Based Printers

NeWSprint software is no longer available in Solaris 2.6.

Motif Window Manager

The Motif Window Manager (MWM) is no longer supported in the Solaris 2.6 operating environment. If you are currently using the MWM, upgrade to CDE.

F3 Font Technology

Support for F3 fonts and the TypeScaler rasterizer, Sun's proprietary scalable font technology, is no longer available in Solaris 2.6.

Uppercase User Name

When an uppercase user name was typed at the login: prompt, login(1) assumed that the terminal was not capable of handling lowercase and set the terminal modes for uppercase only operation. Because this feature caused user confusion and supported only obsolete hardware, it is no longer available in Solaris 2.6.

SPARCstorage Array - ssacli(1M) Command

The ssacli(1M) command is no longer available in Solaris 2.6. Use the ssaadm(1M) command for SPARCstorage Array administrative management.

SPARC Only: Direct Xlib

Direct Xlib is no longer available in Solaris 2.6.

Use the Sun Shared Memory Transport Extension (SUN_SME) with Standard Xlib for comparable Xlib performance. SUN_SME does not use Direct Graphics Access (DGA); therefore, it does not generate the overhead and limitations associated with using Direct Xlib. SUN_SME is supported on all SPARC platforms.

Next Topic

Solaris 8 Features

Complete Table of Contents