Robust Software Developer Environment

The Solaris operating environment provides developers with the documentation, development software libraries, productivity tools, sample code, and testing tools needed to develop software applications for the Solaris runtime environments. This section describes new features to help developers dealing with large files (over 2 Gbytes), multithreaded applications, and X servers and libraries.

Large Files

The large files project supports files that are larger than or equal to 2 Gbytes. Large-file semantics are supported on UFS, NFS, and CacheFS file systems. Applications will be able to create and access files up to

• One Tbyte on UFS-mounted file systems

• The limit of the NFS server for NFS- and CacheFS-mounted file systems

Existing file I/O interfaces have been modified to detect the error when they are used with a large file. New data types (most with suffixes of 64 or 64_t) and new interfaces (most with suffixes of 64) are provided to operate on large files.

An existing application running on Solaris 2.x software should be checked for the following points:

• To make the application large-file compatible (for example, "large-file safe in Solaris 2.6"), examine the application's source code to ensure that use of existing interfaces is appropriate and has the correct error-handling characteristics when a large file is encountered.

• For your application to work with large files (for example, "large-file aware"), you must examine and modify your source code. Examples for areas to modify include:

  • Output and in-memory formatting strings such as %ld to %ll

  • Any variable for temporary storage of sizes or offset information must be correctly sized to avoid truncation

  • Function parameters and return values should be checked and corrected if necessary.

For more information, see NFS Administration Guide and System Administration Guide.

Versioning and Scoped Libraries

Versioning and scoping are related enhancements to the link editor in the Solaris operating environment. Developers of dynamic objects can use these technologies to define sequential versions of a dynamic object's binary interface within the object and reduce global symbols to local scope. These capabilities provide the means to control interface evolution across software releases, inherit global symbols from previous versions, record version dependencies, and describe internal implementation changes.

Versioning and scoping enable developers to provide stable interfaces for program development, achieve standards compliance, and protect implementation changes (such as bug fixes) from the object's public interface. An added benefit can be reduced object size and runtime relocation cost, which can improve an application's runtime performance.

For the Solaris 2.6 operating environment, the system libraries take advantage of this technology and have been both scoped and versioned.

For more information, see Linker and Libraries Guide.

Scheduler Activation

Scheduler activations provide additional kernel scheduling support for multithreaded applications. This is implemented as a private interface between the kernel and the libthread library (or libpthread), without changing the libthread (libpthread) interface. Among other things, this enables the thread library to implement adaptive mutex locks. Adaptive mutex locks is where a thread trying to acquire a lock spins if the thread holding the lock is currently running on a processor, and blocks otherwise.

See the libsched(3X) man page for more information.

Pre-emption Control

Pre-emption control allows applications to give scheduling hints to the kernel to prevent preemption for short periods of time. This can improve the performance of some classes of applications such as database servers.

/proc File System and Watchpoints

The previous flat /proc file system has been restructured into a directory hierarchy that contains additional subdirectories for state information and control functions. It also provides a watchpoint facility to monitor access to, and modification of, data in the process address space. The new /proc file structure provides complete binary compatibility with the old /proc interface.

The adb(1) command has been modified to use the new /proc watchpoint facility. It now provides data breakpoints to cause the subject processes to stop on access to specified variables.

For more information, see the adb(1) man page.

Federated Naming Service (FNS)

FNS is now compliant with the X/Open XFN CAE definition. FNS has also been enhanced to include support for Lightweight Directory Access Protocol (LDAP). It also provides improved support for the files and NIS back ends.

For more information, see Federated Naming Service Programming Guide, Solaris Naming Administration Guide, and Solaris Naming Setup and Configuration Guide.

Asynchronous I/O for Tape Drives

Asynchronous I/O support for tapes provides an interface to improve performance on the high performance tape devices. With the ability to queue up to requests, this feature significantly improves the I/O throughput.

Solaris Developer Kit (SDK)

The SDK software is now built into the Solaris environment and is no longer an unbundled product. All the information a developer needs to produce applications and graphics handlers for end-user Solaris runtime environments is now available in the Solaris software.

Graphics

The Solaris VISUAL^TM software includes several graphics and multimedia software foundation libraries. Foundation libraries are the lowest-level device-independent layer of the Solaris software. This level of interface is designed to support a wide variety of common functions. You can build higher-level libraries on top of the foundation libraries, or the foundation libraries can be used directly by a software application. These foundation libraries create applications that incorporate 2-D and 3-D graphics, imaging, and digital video. The libraries are the XGL graphics library (which serves as a foundation library for the Solaris PEX software) and XIL imaging library.

PEX 3.0.2 Runtime Environment

The Solaris PEX 3.0.2 RTE consists of a PEX client-side runtime library (PEXlib) and a PEX server-extension shared-object file (Solaris PEX server). PEXlib is an API to PEX protocol as Xlib is to core X protocol. PEXlib provides application portability across hardware platforms and enables 3-D graphics rendering on local and remote displays. The OpenWindows Version 3.6 X11 server automatically loads the PEX shared-object extension when it receives a PEX request from a PEX client.

The PEXlib implementation for the Solaris 2.6 release is based on PEXlib - Specification and C Language Binding: Version 5.1, available from the Massachusetts Institution of Technology. The PEX server extension is based on PEX Protocol Specification, Version 5.1.

Solaris PEX 3.0.2 RTE is included in the Solaris 2.6 release and should be installed if you are planning to

• Run PEXlib-based graphics client applications

• Display any 3-D graphics from client applications that perform rendering on remote displays through the PEX protocol

To install PEX, choose the entire distribution software group when installing the Solaris 2.6 software.

For more information on PEX, see:

• Solaris PEX Implementation Specification

• Solaris PEXlib Reference Manual

• CGE PEX 5.1 Portability Guide

Also, the following books are available at bookstores:

• PEXlib Programming Manual, O'Reilly and Associates, Inc.

• PEXlib Reference Manual, O'Reilly and Associates, Inc.

XGL 3.3 Runtime Environment

The XGL library is a 2-D and 3-D immediate-mode API that provides application portability across hardware platforms and enables graphics applications to get optimal performance from graphics accelerators. The XGL version 3.3 library enables applications to determine transparency support level and includes a new attribute to enable user control over edge offset.

The XGL 3.3 runtime environment (RTE) is included with the Solaris 2.6 release and should be installed if users at your site are running graphics applications. It is not always obvious whether an application requires the XGL RTE; therefore, you should install the XGL RTE if you are installing CDE or OpenWindows software, since an application may reference the XGL libraries.

For more information on XGL, see XGL Programmer's Guide or XGL Reference Manual.

XIL 1.3 Runtime Environment

The XIL library is an imaging API that provides a basic set of functions for imaging and video applications. The library provides a strategy for low-level software interfaces (foundation libraries) and enables APIs and API developers to port their code to these foundation libraries.

The XIL 1.3 runtime environment (RTE) is included with the Solaris 2.6 release and should be installed if users at your site are running imaging applications. It is not always obvious whether an application requires the XIL RTE; therefore, you should install the XIL RTE if you are installing either OpenWindows or CDE software, since an application may reference the XIL libraries.

Backward Compatibility

The XIL 1.3 library API is fully backwards compatible. This means that existing applications can be run without modification or recompilation.

MT-Hot

The XIL 1.3 library is MT-hot. Developers can write multithreaded applications without putting locks around XIL functions. Multiple threads from the API will execute correctly as long as they do not require data from the same image. The library itself also is MT-hot. It takes advantage of multiprocessor systems without applications having to be rewritten.

Tiled Storage

The XIL 1.3 library stores very large images in buffers of memory called tiles. If a region of an image within a tile boundary is needed, only that tile is loaded into memory, thereby increasing performance.

The library also includes a new storage object, which supports conventional contiguous storage as well as tiled or stripped storage for XIL images. The storage object serves as a container for the image's attributes, such as its scanline and pixel stride, and its data pointer. Storage is not allocated for the image until you export the image and modify it directly. This saves on memory use.

New Data Type

The XIL 1.3 library now supports the 32-bit single-precision, IEEE floating-point data type. Using this data type enables you to develop highly sophisticated scientific imaging applications.

Temporary Images

The XIL 1.3 library supports temporary images, which are images used as an intermediate step in creating a subsequent image. They may only be written to, and read from, once. Temporary images are particularly advantageous for large images, because XIL can release the storage associated with them when it's no longer needed.

XIL_GENERAL Storage Format

The XIL 1.3 library supports the new XIL_GENERAL() storage format. This format provides the flexibility of specifying each band of a multiband image as a separate memory buffer. Furthermore, each band can have its own scanline and pixel stride.

XIL_BAND_SEQUENTIAL Storage Format

The XIL 1.3 library now supports the XIL_BAND_SEQUENTIAL format for all data types, not just XIL_BIT images.

KCMS Integration

The XIL 1.3 library includes Kodak Color Management System (KCMS) support. You can achieve very close color matching between a display image and the actual stored image.

KCMS Multithreaded Programming

The Kodak Color Management System (KCMS) software product is a color management solution that ensures color consistency from input devices to output devices. It is technology licensed from Eastman Kodak that was developed in conjunction with SunSoft.

KCMS now supports multithreaded programs: it is multithread safe (MT-safe). If your KCMS application uses multithread capabilities, you do not need to put locks around KCMS library calls.

For more information, see KCMS Application Developer's Guide.

X11R6 Base Window System

The X11R6 Base Windowing System includes the latest fixes and patches from the X Consortium.

For more information, see the X/Open web site at http://www.xopen.org.

X11 Double Buffer Extension

The Double Buffer Extension (DBE) provides a standard way to use double-buffering within the framework of the X Window System. Double-buffering uses two buffers, called "front" and "back," that hold images. The front buffer is visible to the user; the back buffer is not. A detailed specification is available via an internet browser in ftp://ftp.x.org/pub/DOCS/DBE/.

For more information, see the X/Open web site at http://www.xopen.org.