Since our lab has been one of the early adopters (and proponents!) of
Solaris in the College of Computing, I've written up this page that
contains some basic information about Solaris, and some issues that
you may want to be aware of.
We've been running Solaris in our lab since version 2.1, and some of
us have used beta and even alpha versions of 2.0. Our experiences
have been very positive, and things keep getting better and better
with each release.
I've tried to provide some introductory information here, some reasons
why you may want to use Solaris, some reasons why you may NOT want to
use Solaris, and explanation of how things are different between
Solaris 2.x and earlier releases, some common gotchas, and a list of
As always, if you find anything that's wrong, or have any comments,
drop me a note!
College of Computing
Atlanta, GA 30332-0280
Solaris is Sun's name for their operating environment (including the
operating system, SunOS, the windowing system, networking, and so
forth). Solaris 1 is probably what you're using now, and includes
SunOS 4.x. Solaris 2 includes SunOS 5.x. The latest version is
Solaris 2.5.1 (which includes SunOS 5.5.1).
SunOS 5.x is based on UNIX System V Release 4. In fact, Sun was one of the
creators of SVR4 along with AT&T. SVR4 is in turn based on SunOS 4.x
and earlier versions of System V.
Note that Solaris 2.x doesn't just run on Suns. It also runs on
Intel-based PCs, and (soon) PowerPC machines.
I WANT TO
There are a lot of really cool things in Solaris; in a lot of ways
it's a playground for developers. Some of the niftier items
- A fully multithreaded, reentrant, and preemtable kernel. The SunOS
5.x kernel is completely SMP and will distribute itself over all the
processors available on the system.
- A very cool threads programming model, which includes userspace
threads (which Sun calls "threads") and kernel-scheduled threads
(called "LWPs," for Light-Weight Processes (which have no relation to
the earlier SunOS 4.x Light-Weight Processes, which weren't
light-weight)). Also, practially every library and system call in
SunOS 5.x is thread safe and, in some cases, thread hot.
- A real-time scheduler. In fact, the scheduler is configurable enough
that you can create your own scheduling classes and assign processes
to them. A must for multimedia work and process control.
- Far better development tools than SunOS 4.x. The C++ compiler is
great. The debugger understands threads in a fundamental way,
provides visualization of data structures, runtime memory leak and
access checking, a "fix and continue" feature that lets you patch
fixes into your object files while they're running and while you're
debugging them, and lots more. Automatically-parallelizing FORTRAN
compilers, static analysis tools for detecting problems in
multithreaded code, etc.
- Support for newer, better hardware. Things like SunVideo, exotic (and
fast) framebuffers, ATM, etc.
- Lots of new libraries for development: XTL (telephony), XIL (imaging
and video), Transport-Independent RPCs, Display Postscript, Rogue Wave
C++ class libraries, etc.
- Nifty applications that only work on Solaris 2: WABI (the Windows
emulator), MAE (Apple's Macintosh emulator), Adobe Photoshop and
Illustrator, Lotus Notes, etc.
- HotJava only works on Solaris 2.x.
OpenStep (the NextStep toolkit ported to X/DPS and Solaris) will only
run on Solaris 2. CDE (The COSE Common Desktop Environment) is only
available for Solaris.
- Support for 64-bit hardware as of Solaris 2.5.
- Solaris 2 is much more standards-compliant than Solaris 1. Better
support for POSIX and ANSI standards.
- Performance for users is actually better than SunOS 4.x (as of
Solaris 2.4 anyway).
- Lots of nifty new user-level features, like automagic mounting of
floppy and CD-ROM media without having to su to root.
HOW IS IT
- With the exception of having to change a few paths around, users
shouldn't notice much different between Solaris 1 and Solaris 2,
except that their window system performance will improve, and they'll
have some nifty applications available to them that they didn't have
- Things have changed significantly from the administrator's viewpoint.
That's beyond the scope of this page. :-)
- If you've paid attention to portability in the past (written in ANSI
C, used standard interfaces) you should have no problems moving to
Solaris 2. In our group, when we made the switch to Solaris we moved
a HUGE body of code over to the new system in just a few days. One of
our projects, Mercator, was ported completely in three days (and it
does all kinds of weird things with X, audio, serial ports, RPC, calls
out to a voice recognition subsystem, etc.)
Some of the things that are different and that may cause problems
- TI-RPC. If you have RPC-based code, you may have to port to
Transport Independent RPCs. For most projects this is probably no
big deal. For others, it may involve some significant work.
- Signals. If you've been using the Berkeley-style signal APIs
(such as signal()), you'll probably want to move to the SVR4-style
- Slight socket differences. Solaris 2 is more strict than
Solaris 1 about catching sloppy programming in the socket API.
Things like not clearing out sockaddr structures before passing
them to bind() are not ignored like they are with Solaris 1.
- POSIX/ANSI issues. If you haven't written to POSIX/ANSI
interfaces you'll have some cleaning up to do. These are changes
that you'll probably need to do anyway if you want your code to be
portable. It's not too difficult, and there are tools to help you
with the conversion.
This section contains some specific hints to help you get
up-and-running with Solaris 2.x.
SETTING UP YOUR ACCOUNT
- What's env.path and how can it help me?
- The CNS staff uses a file called /etc/env.path to specify a list
of machine types for the system that you are on, from more-specific
to less-specific. For example, on a Sun 4-class machine running
Solaris 2.4, /etc/env.path may contain:
The default .login, .cshrc, and .xinitrc files look at /etc/env.path
to figure out what kind of machine you're on, and then try to
execute (in order) .cshrc-sun-5.4, .cshrc-sun-5, .cshrc-sun, and
.cshrc-gen. This scheme allows you to have different startup files
in your home for each type of system that you're on (Suns running
Solaris 1, Suns running Solaris 2, SGIs running IRIX, etc.) It's
easy to keep your system-specific login stuff separate this way.
Look in /usr/local/dotfiles/README for more information.
- Where does XXX live?
- There are a few directory changes under Solaris 2 that you'll
probably want to know about. A few good ones to know include:
- /sbin and /usr/sbin
- These are where statically-linked
administration commands live. These are the programs that
are needed to bootstrap the system.
- This is where the BSD versions of your favorite commands
live. If you're used to BSD-style ps, df, etc., you should
probably have this directory before /bin and /usr/bin in your
- This is a nappy SVR4-ism. This directory is where
make, ld, gprof, and other development-related tools live.
- This is the SVR4 location for "optional" software packages.
You may not consider some of these packages (like the
compiler) to be all that optional. In most cases, the
binaries in the individual /opt packages have symbolic links
in /usr/local/bin so that you can get to them without having
to figure out what all of the individual packages are.
I recomment having /usr/ccs/bin and /opt/SUNWspro/bin in your path before
/usr/ucb. This will make your life much easier.
A few other good things to know are (1) ranlib doesn't exist on your
system because it's not needed. The SVR4 ar command keeps archive
tables of contents up-to-date without the need for ranlib. Link
ranlib to /bin/true or something if you have a bogus makefile that
thinks it needs ranlib. (2) Make sure you're using the C compiler
in /opt/SUNWspro/bin (or /usr/local/bin) instead of the one in
/usr/ucb/cc. The compiler in /usr/ucb/cc is the "backwards
compatibility" compiler that invokes /opt/SUNWspro/bin/cc with flags
to compile using BSD libraries and include files. Go through the
extra 5 minutes of work to use the native compiler, you'll be happy
- Do I dare trust /usr/local?
- There is a separate /usr/local for each type of system in the
College. So Suns running Solaris 2.x see a different /usr/local
than Suns running Solaris 1.x. By default, any binaries
which exist on the Solaris 1.x /usr/local and DO NOT have Solaris
2.x-specific counterparts will show up in the Solaris 2.x
/usr/local, however. Basically you can think of the Solaris 2.x
/usr/local as being overlayed on top of the Solaris 1.x /usr/local.
Anything specifically built for 2.x will override 1.x versions.
We've built 2.x-specific verions of quite a bit of software,
including: AudioFile, Doom, elm, GCC (and various other GNU tools),
ghostscript and ghostview, the MBone tools, Modula-3, Mosaic 2.4,
Netscape, olvwm, Python 1.2, Tcl/Tk, tcsh, XEmacs, etc.
Most SunOS 4.x programs that (1) don't muck with kernel memory, (2)
don't do weird BSD-style terminal shenanigans, and (3) don't use
undocumented system interfaces will work just fine under the Solaris
Binary Compatibility Package. This allows you to run nearly all
SunOS 4 binaries without problems under Solaris 2.x.
- How do I run a different window manager under CDE?
- This is from Jen Mankoff , our resident
OK, this is how to run the window manager of your choice on solaris (one
minor bug remains, may not have a solution).
Now when you log in to your solaris machine, it should run
.dt/sessions/sessionetc, run any default dt apps, and then run your
- run the standard window manager at least once. This will cause it to
create certian files and directories which you need for the rest of these
- add the following resource to your .Xdefaults file:
dtsession*wmStartupCommand: path to wm of your choice (make sure it's installed)
- make a special version of your .xinitrc for sun-5. This works like any
other .xinitrc, but make sure that you remove the call to your window
manager (dt will run that for you automatically). You might want to add a
comment to the .xinitrc-sun-5 explaining why you removed that line, so
you don't add it back by mistake later.
- make a link as follows:
ln -s .xinitrc-sun-5 .dt/sessions/sessionetc
.dt/sessions/sessionetc is the file dt reads instead of your
.xinitrc-sun-5. making them the same file (by linking one to the other)
just makes it easier for you to keep track of.
If something goes wrong, debug as follows:
- comment out the line in your ~/.dtprofile file which writes to
/dev/null. instead, a record of everything you do in
/sessionetc will be written to
read that file to see what went wrong
- the ~/.dt/errlog file, if it exists, might also have useful
information in it.
caveat: when you log out, all that happens is your window manager dies.
In general, if you never log out this won't be a problem, but it should
be fixed and I don't know how.
In order to log out completely, you need to do the following:
- before you log out make sure there's a window showing on
your screen with a log in to the machine on which dt is running
- log out
- move your mouse over that window
- type: "ps -ugx"
- look for the dtsession and ttsession processes
- find their pids (the first number column)
- for each of their pids, type kill
- wait. you will be logged out like you wanted to be in the beggining.
Note: I'll probably write a shellscript pretty soon which finds my window
manager process, and my dtsessino and ttsession processes and kills them
all (thus logging me out) so I don't have to always do this by hand.
There might already be a program which does this, but I don't know where
- What's WABI?
- WABI is Sun's MS Windows emulation software. Unlike things like
SoftPC which interpret all of the x86 instructions (including those
for Windows itself), WABI provides a native implementation of
the Windows API. So all of an application's calls to any Windows
routines results in a call to a SPARC- and X-native reimplementation
of that function. Pure application code is still interpreted.
The result is that WABI runs Windows apps pretty quickly. Sun
"certifies" about 20 applications that are guaranteed to work.
Officially, you're on your own if you want to run an app that's not
on the list, but lots of programs seem to work well.
WABI 2.0 requires you to install your own copy of Windows to work
(WABI needs OLE and other DLLs for which there is not a SPARC-native
implementation). For more information on running apps under WABI,
and tips about running non-certified apps, you can send email to
one of the answerbots:
WABI lives in /opt/SUNWwabi.
- Where does the compiler live?
- The compiler lives in a strange place: /opt/SUNWspro/bin. The
"/opt" thing is an SVR4-ism for optional software. The "SUNWspro"
thing is a unique token for the "package" that the software is a
part of. Lots of interesting things live in /opt, and you can use
pkginfo to find out more about them (check the man page for
The C compiler (cc), C++ compiler (CC), debugger (dbx), and various
graphical tools are all in there.
Note that there is a "cc" in /usr/ucb. This "compiler" is actually
just a shell script that invokes /opt/SUNWspro/bin/cc with a few
extra flags to compile older BSD-based software (it links in -lucb
and used the BSD-style include files). Since most software off the
net now support compilation for Solaris (and the stuff that doesn't
can usually be fixed in a few minutes), I'd recommend never
using the BSD compiler unless you absolutely can't avoid it. You'll
pay a (slight) performance hit for running under the binary
- What's up with dynamic libraries?
- Solaris 2 dynamic libraries work a little differently than on SunOS
4. Solaris requires that you have an exact match between the
version number on the library and the version number that the
application was linked against. There are no minor shared object
version numbers in Solaris, and no ".sa" files.
If you're linking aginst shared libraries, the correct way to
do it is to use -R to specify a list of directories where those
objects live. The -R option puts the paths you specify into the
executable, and the runtime linker will search there for them when
the executable runs. Without the -R option, you require those
running your programs to use an LD_LIBRARY_PATH environment
LD_LIBRARY_PATH is the work of the devil and should be avoided at
all costs. Don't have one set yourself, don't make your users set
one. If you find a program that won't run without having it set,
that program is broken.
- What!? You want me to use dbx?
- The Solaris dbx isn't your grandfather's dbx. This debbugger (and
its graphical counterpart, called "debugger") support all kinds of
nifty things, like thread handling, some excellent C++
features (like debugging exceptions, virtual functions, template
code), a visual data inspector that will draw things like linked
lists on your screen, run-time memory access and leak checkers, a
"fix-and-continue" feature that lets you fix errors while you're
debugging (and running), and lots more.
- Where are bzero, bcopy, and friends?
- bzero and it's brethren are Berkeleyisms and aren't found in the
Solaris libc on Solaris versions 2.4 and earlier. The SVR4 interfaces
that accomplish the same things are memset, memcpy, etc. These basically
work just like bzero, et al, except that the argument order matches the
man (3) string functions.
If you use the (evil) compatibility compiler (which you shouldn't use,
see above), then the libucb compatibility library will get linked in and
it contains the bzero, ..., functions.
In Solaris 2.5, bzero and friends are included in libc to make life
- Where is ranlib?
- Ranlib is not needed in Solaris, or other System V Unices. The
SVR4 ar program handles the functions that ranlib was required for.
Note that if you use the GNU fileutils version of ar then all bets are
off. Stick to the one that comes with Solaris.
- Is the C++ compiler worth anything?
- Absolutely. The compiler supports exceptions (even in multithreaded
programs), and has a pretty cool template instantiation scheme. The
compiler is also a native C++ compiler so it avoids the
translation to C that cfront-based compilers do.
- Are there any other tools that I should know about?
- The graphical debugger and source browser speak ToolTalk (Sun's
inter-application communication facility). So they can communicate
with things like XEmacs in a fairly high-level way. In fact, the
debugger and source browser will simply use XEmacs as their editor
if you've enabled this feature.
If you're doing multithreaded development, check out LockLink, a
tool for doing static analysis of C programs to detect potential MT
problems, and thread analyzer. There's also a performance analyzer,
maketool, and some other stuff.
If you're a C++ coder, the RogueWave Tools.h++ class library comes
for free. Sun has enhanced the library to be thread-safe.
The AnswerBook program provides online access to the complete Sun
documentation set, in a hypertext and searchable format. The books
are displayed using Display PostScript. Type answerbook to get at
USING REMOVABLE MEDIA
- How do I mount a floppy?
- Solaris has a thing called the Volume Manager that
controls removable media. Look at the man pages for vold,
vold.conf, and rmmount.conf (rm for "removable media") for
information about how to configure the thing.
The floppy drives on Suns don't autodetect floppy insertions. So
you have to tell the Volume Manager that a floppy is there. You can
do this from the command line by typing "volcheck" or from the File
Manager by pulling down the file menu and selecting "Check for
(I usually leave a File Manager running just for this purpose; it
also gives you a graphical interface to formatting floppies.)
- What about PC filesystems?
- Solaris understands low-density (720KB), high-density (1.44MB),
and the funky NEC medium-density floppies. If you insert one of
these, Volume Manager will mount it for you just like any other file
system. You can cd to it, vi files in it, and so on.
- How do I mount a CD-ROM?
- Solaris does autodetect CD-ROM insertions. So just stick
it in and it'll get mounted under /cdrom for you.
- How do I share a CD-ROM?
- At the end of /etc/rmmount.conf, add the line
share cdrom* -o ro=all-cc
to share your CD-ROM drive with any CoC system.
- What's so open about OpenWindows?
- Previous versions of OpenWindows included the X Window System
(version X11R4) along with NeWS (the Network Extensible Window
System). NeWS was nifty, but its inclusion seriously slowed down
the X side of the world.
In Solaris, the OpenWindows server is essentially an enhanced MIT
X11R5 server. The code is actually based on the MIT sample server
source, so it behaves just like the "generic" MIT server.
So why use OpenWindows? OpenWindows provides a few extra benefits
over the MIT server:
- Performance. The DDX layer of the OpenWindows server is
significantly more tuned for Suns than MIT's.
- Hardware Support. The OpenWindows server supports all
current Sun framebuffers. MIT only supports the older GX-class
- Display PostScript. Adobe Display PostScript is included
as a server extension.
- Interactivity Extension. As of Solaris 2.4, the window
server uses a special extension to communicate with the kernel. The
kernel actually moves the process owning the window with the current
focus into the "interactive" scheduling class for better interactive
performance, even when compiles are running in the background.
- General Coolness. The Sun server includes XTEST, the X
Input Extension, loadable extensions and input methods, and is
generally cooler than the MIT server.
- But I don't like ol(v)wm!
- No problem. Run any window manager you like. olwm and twm
ship with the system, mwm comes with the developers kit (which we
have), and many others are installed in /usr/local/bin.
You probably should run the OpenWindows server though, unless
you have a specific need for some extension that's only in the X11R6
server (you can run R6 clients with the OpenWindows
server no problem).
See above for special tips on running a different window manager with CDE.
- Where's Motif?
- Motif is in /usr/dt. No, this isn't another weird Sun-ism.
This is the new "standard" location, as specified by CDE. All
vendors will be shipping Motif here soon.
- What's CDE?
- CDE is the Common Desktop Environment, the user interface
specification done by COSE, the Common Open Software Environment.
It's based on Motif 1.2 with a window manager that looks a lot like
HP VUE, and inclues the Sun Deskset apps ported to Motif.
CDE lets you switch at login time between your different
environments. It also uses the OpenWindows server.
- What's the scoop with OpenStep?
- OpenStep is a port of NeXT's NextStep toolkit to Solaris. Like
CDE, it'll also run atop the OpenWindows server. No official word
on when it's due to ship, but probably around this summer.
Sun Home Page
The Solaris 2 FAQ (Excellent FAQ maintained by Casper Dik)
The Sun Hardware FAQ (More info than you ever wanted to know about
The Solaris Porting FAQ (Information about porting to Solaris 2)
SunSITE (Software, Information, and Technology Exchange for
Sun's Threads Developer's Page (Lots of nifty stuff for people
developing with threads)
Sun FTP site: playground.sun.com (Multimedia and networking
tools from Sun).
Sun FTP site: opcom.sun.ca (Various scripts and programs from
OpCom Consulting at Sun)
Migration Tools, including
- Developer Transition Tool (AKA Pipeline Tool)
- Administrator Transition Tools
SunService Public Patch Page (Recommended and security-related
patches from Sun)
SunSoft Support Page (A nifty searchable index of
commonly-asked support questions)
Sunergy Home Page (Whitepapers, live broadcasts, etc.)
Other FAQs (Lots of Sun-related FAQs about modems, FTP sites,
OpenLook, PPP, security, WABI, you name it)
Solaris for x86 Intel Corner (Lots of useful information for
Solaris on Intel; some of it's appropriate to Solaris on SPARC as
Solaris at UMBC (A page like this one, only for Solaris users
at the University of Maryland, Baltimore County)
Books from SunSoft Press
Celeste Stokely's Guide to Modems and Terminals (A great guide to
doing modem and terminal shenanigans on Solaris.)
Solaris PPP Guide (A useful resource if you're trying to configure
the Point-to-Point Protocol with Solaris.)