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!

WHAT THE HELL IS SOLARIS?!

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.

WHY WOULD I WANT TO USE IT?

• 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.
• DOOM!
• 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 DIFFERENT?

Users

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.

Administrators

Things have changed significantly from the administrator's viewpoint. That's beyond the scope of this page. :-)

Developers

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:

• 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 sigaction() interfaces.
• 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.

NOTES ON MIGRATION

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:

sun-5.4:sun-5:sun:gen

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.

/usr/ucb

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.

/usr/ccs/bin

This is a nappy SVR4-ism. This directory is where make, ld, gprof, and other development-related tools live.

/opt

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:

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

-jen

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:

	wabi2.0-questions@east.sun.com
	wabi2.0-apps@east.sun.com
  

WABI lives in /opt/SUNWwabi.

COMPILING PROGRAMS

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.

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

WINDOW SYSTEMS

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.

WHAT RESOURCES ARE AVAILABLE?

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: playground.sun.com (Multimedia and networking tools from Sun).
8. Sun FTP site: opcom.sun.ca (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.)