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 internet-available resources.

As always, if you find anything that's wrong, or have any comments, drop me a note!

Keith Edwards
College of Computing
Georgia Tech
Atlanta, GA 30332-0280
(404) 894-6266


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.


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 include:


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 before.

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 are:


This section contains some specific hints to help you get up-and-running with Solaris 2.x.


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 path.
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 you did.

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 other-window-managers-under-CDE person:

OK, this is how to run the window manager of your choice on solaris (one minor bug remains, may not have a solution).

  1. 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 steps.
  2. add the following resource to your .Xdefaults file:
    dtsession*wmStartupCommand: path to wm of your choice (make sure it's installed)

  3. 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.
  4. 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.

Now when you log in to your solaris machine, it should run .dt/sessions/sessionetc, run any default dt apps, and then run your window manager.

If something goes wrong, debug as follows:

  1. 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 ~/.dt/sessionlogs/_DISP... read that file to see what went wrong
  2. 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:

  1. 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
  2. log out
  3. move your mouse over that window
  4. type: "ps -ugx"
  5. look for the dtsession and ttsession processes
  6. find their pids (the first number column)
  7. for each of their pids, type kill
  8. 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 it is.


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 pkginfo).

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 compatibility mode.

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 variable.

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 easier.

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 it.


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 Floppy."

(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 framebuffers.
  • 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.


  1. Sun Home Page
  2. The Solaris 2 FAQ (Excellent FAQ maintained by Casper Dik)
  3. The Sun Hardware FAQ (More info than you ever wanted to know about Sun hardware)
  4. The Solaris Porting FAQ (Information about porting to Solaris 2)
  5. SunSITE (Software, Information, and Technology Exchange for Sun users)
  6. Sun's Threads Developer's Page (Lots of nifty stuff for people developing with threads)
  7. Sun FTP site: (Multimedia and networking tools from Sun).
  8. Sun FTP site: (Various scripts and programs from OpCom Consulting at Sun)
  9. Migration Tools, including
    1. Developer Transition Tool (AKA Pipeline Tool)
    2. Administrator Transition Tools
  10. SunService Public Patch Page (Recommended and security-related patches from Sun)
  11. SunSoft Support Page (A nifty searchable index of commonly-asked support questions)
  12. Sunergy Home Page (Whitepapers, live broadcasts, etc.)
  13. Other FAQs (Lots of Sun-related FAQs about modems, FTP sites, OpenLook, PPP, security, WABI, you name it)
  14. Solaris for x86 Intel Corner (Lots of useful information for Solaris on Intel; some of it's appropriate to Solaris on SPARC as well.)
  15. Solaris at UMBC (A page like this one, only for Solaris users at the University of Maryland, Baltimore County)
  16. Books from SunSoft Press
  17. Celeste Stokely's Guide to Modems and Terminals (A great guide to doing modem and terminal shenanigans on Solaris.)
  18. Solaris PPP Guide (A useful resource if you're trying to configure the Point-to-Point Protocol with Solaris.)