Saturday, January 9, 2016

Building Ruby From Source With Microsoft Visual Studio


Ruby packages are available for Windows, and they can be used to develop Ruby applications, all day long. However, they lack the necessary files to develop Ruby modules in C/C++ and unlike PHP, where you can fairly easily shoehorn the headers into an already-installed package, it's not so easy with Ruby. In fact, to get a hold of the components to shoehorn in, you have to do an entire build from source, so you might as well just do that to begin with.

Fortunately, it's not too difficult.


For this effort you will need:

  • Microsoft Visual Studio
  • The Ruby source code.
  • A few unixish commands - gunzip and tar. These can be provided by a gnuwin32 installation, a cygwin installation.
  • A text editor. Notepad or vi will do.

The Process

I last did this with Ruby 2.2.0, so I'll use it in this example.

The Ruby source code comes as a tar.gz file. There aren't any .zip files available, or if there are, I'm not sure where to find them. So you'll have to use some unixish commands to extract it.

Move the ruby sources to somewhere convenient and use the unix tools to extract it:

gunzip ruby-2.2.0.tar.gz
tar xf ruby-2.2.0

This should create a directory named ruby-2.2.0

Open the appropriate Visual Studio command prompt. If you plan on building a 32-bit version of Ruby, then open the x86 command prompt. If you plan on building a 64-bit version of Ruby, then open the x64 command prompt.

Navigate into the ruby-2.2.0 directory that was created by the extraction process above.

To get everything to compile and install correctly, I had to edit the file tool\rbinstall.rb and change line 714 to read:

rescue LoadError

This may or may not be necessary with a newer version of ruby, or the line to edit might be different.

Now, configure the build.

For a 64-bit build, run:

win32\configure.bat --prefix=C:\Ruby --target=x64-mswin64

For a 32-bit build, run:

win32\configure.bat --prefix=C:\Ruby --without-ext=fiddle 

(The --without-ext=fiddle command just disables the "fiddle" extension, which I couldn't get to build on 32-bit Windows, for some reason. Your mileage may vary.)

To actually build Ruby, run:


(This will run for a while.)

When it's done, install Ruby by running:

nmake install

Everything should get installed under C:\Ruby

To make the ruby programs generally accessible, add C:\Ruby\bin to the system PATH as follows:

  • Open the Control Panel
  • Search for Environment
  • Click the link for "Edit the system environment variables"
  • Click "Environment Variables"
  • In the System Variables pane, scroll down and click on Path
  • Click Edit...
  • Append: ;C:\Ruby\bin to the Variable Value.
  • Click OK
  • Click OK
  • Click OK

And that's it. Ruby is now built, installed and accessible.

Hopefully this helps someone out.

Good luck developing your Ruby modules on Windows.

Generating a Missing Import File From a DLL


Occasionally I run into software packages for Windows that are missing some of the developer bits. One bit that occasionally gets left out is the import library. The headers are there, the .dll is there, but the .lib file is missing.

It's not impossible to generate a .lib from a .dll though.

Here's how.


You'll need a few things to do this:

  • Microsoft Visual Studio
  • A few unixish commands - echo, cat, and cut. These can be provided by a gnuwin32 installation, a cygwin installation, or just a second linux or unix system.
  • A text editor. Notepad or vi will do.

The Process

I ran into this issue with Active Perl 5.20, so I'll use it in this example. Adjust accordingly.

First, dump the list of exports from the dll into an file. Open a Visual Studio command prompt and run some commands similar to the following:

cd C:\Perl64\bin
dumpbin /exports perl520.dll > exports

(adjusting for the path and file name of your .dll)

Now, edit the exports file.

Trim off everything prior to the first function definition. In the perl dll, that was a line like:

          1    0 000295C0 ASCII_TO_NEED

Trim off everything after the last function definition. In the perl dll, that was a line like:

       1249  4E0 001271B0 win32_write

Now, use the unixish commands to create a .def file.

(If you're doing this on a second machine, then you'll need to copy the exports file over to it and then, afterwards, copy the .def file back.)

echo EXPORTS > perl520.def
cat exports | cut -c27- >> perl520.def

Now, use Visual Studio's lib command to build the .lib file.

lib /def:perl520.def /OUT:perl520.lib /MACHINE:X64

Note: In this example, we had a 64-bit DLL. To build from a 32-bit DLL, use the /MACHINE:X86 flag instead.

Currently the .lib file is sitting in the bin directory, but .lib files generally need to go in a lib directory or some other place. So, move it now.

move perl520.lib ..\lib\CORE

You can now clean up if you like.

del exports
del perl520.def

And that's it. You can now link against the .lib file and your app will load the .dll at runtime.

Hopefully these instructions help if you ever find yourself in a similar situation.

Shoehorning Development Headers Into PHP for Windows


In years past, I've had trouble building PHP modules on Windows because, though PHP packages are available for Windows, they lack the necessary header files to build PHP modules. One solution is to build and install PHP from source, but that takes forever, uses a ton of space, and has a long list of prerequisites. It turns out that it's actually faster and easier to shoehorn in a set of development headers into the already-installed PHP package.

Here's how.


You will need the following items:

  • A Linux or Unix machine, with a working compiler toolchain. (Actually, a cygwin installation with a working compiler toolchain might suffice but I've never tried it.)
  • The PHP package for Windows.
  • The source code for the same version of PHP as the package.
  • The same version of Microsoft Visual Studio that was used to build the PHP package. The version of VS is discernible in the package filename. For example, was built with Visual Studio 14 (aka Visual Studio 2015).
  • Several bits of software from the gnuwin32 project:

On the Windows machine, install the PHP package into C:\PHP and install Visual Studio.

Install the gnuwin32 software:

  • Create C:\gnuwin32
  • Extract each zip file by right-clicking on it and selecting Extract All.
  • Move the contents of the folders created during the extraction into C:\gnuwin32
  • Add C:\gnuwin32\bin to the PATH environment variable.
    • Open the Control Panel
    • Search for Environment
    • Click the link for "Edit the system environment variables"
    • Click "Environment Variables"
    • In the System Variables pane, scroll down and click on Path
    • Click Edit...
    • Append: ;C:\gnuwin\bin to the Variable Value.
    • Click OK
    • Click OK
    • Click OK

If you can run bison or flex from the command prompt, then it worked.

Building the Headers

Copy the source code to the Linux/Unix machine and extract it. Then build and install the headers somewhere convenient, like your home directory. In this example, we'll use /home/dmuse/php though it could be anywhere.

tar xf php-5.6.17.tar.bz2
cd php-5.6.17
./configure --prefix=/home/dmuse/php
make install-headers

Now, copy the entire /home/dmuse/php/include directory to the Windows machine. If the linux/unix machine is visible as a Windows share then you can just drag the directory across the network. Otherwise you can zip or tar it up, contrive to copy it over using scp, ftp, http, or something else, and then extract it by right-clicking on it and selecting Extract All.

Move the includes folder to C:\PHP\dev such that there is now a C:\PHP\dev\include folder. Verify that C:\PHP\dev\include\php exists and that C:\PHP\dev\include\include didn't get created by accident, as sometimes the top-level folder gets duplicated during extraction.

The PHP package now contains most of the headers necessary to develop PHP modules, but a few windows-specific files need to be generated and installed.

Extract the PHP source somewhere convenient on the Windows machine.

Open a Visual Studio command prompt. Make sure to open a prompt for the same architecture as the PHP binary package. For example, if the package is an x86 package, then make sure to open the x86 prompt. If the package is an x64 package, then make sure to open the x64 prompt.

Change directories to the folder that was created when you extracted the PHP source and run the following commands.

cscript /nologo configure.js

Then, copy the Windows-specific headers that were built by those commands into the PHP tree:

copy main\config.w32.h C:\PHP\dev\include\php\main
copy TSRM\tsrm_config.w32.h C:\PHP\dev\include\php\TSRM
copy Zend\zend_config.w32.h C:\PHP\dev\include\php\Zend

And that's it. You have now shoehorned development headers into the PHP package for Windows. Good luck building your PHP module!

Friday, September 25, 2015

Solaris 9 Sparc


Qemu 2.4.0 came out on August 11th and I've been so busy that I didn't even notice. This week though, I've been sick, all week. ...and my mind just hasn't been up to its customary level of problem solving. Feeble attempts to get work done gave way to browsing the web, and eventually to sleep. During one of those periods of consciousness though, I noticed that Qemu 2.4.0 had been released. And the ChangeLog included something that piqued my interest.

In the SPARC notes:

     Fix SunOS 4.1.4 boot on sun4m with OpenBIOS

SunOS 4.1.4 is also known as Solaris 1.something-or-other. Last I checked, OpenBIOS couldn't boot anything except Solaris 7, 8 and 9, in single-user mode, and there were even some limitations to that. Older versions of Solaris were completely unsupported.

I knew that Artyom Tarasenko and friends had been poking at OpenBIOS and QEMU over the years, and bit-by-bit it could boot more and more things, but the last I'd heard, a year ago, they'd just barely gotten it to boot Solaris 9 in full single-user mode.

What's this I hear about SunOS 4.1.4? Has a bunch of progress been made since the last time I checked?

I would have to find out.

But I didn't. Not at first. Instead I slept and slept and tried to kick this cold. But later in the week, I improved somewhat, and rather than spending my conscious moments browsing the web, I nudged along some projects, including an attempt to get some version of Solaris for Sparc running.

I started with Solaris 9. I'm not sure why, really. I own copies of 1.1.1B, 2.1 and versions 7 through 11. No idea why I settled on 9. My subconscious was making most of my decisions at the time. I think it's because I'd also read that 9 sort-of-boots further and 9 was still on my mind.

At any rate, I gave 9 a try.

VM Configuration

I sort-of followed some of the directions at Artyom's Solaris/sparc under qemu how-to but with a few modifications. I had a few false starts, but it didn't take long, or much effort (thankfully) to work my way through them.

So here's what I ultimately did...

I created a 36G disk.

qemu-img create solaris9_sparc.img 36G

Why 36G in particular? Wait and see...

This is the QEMU command that I ended up using too.

qemu-system-sparc -drive file=solaris9_sparc.img,format=raw \
-cdrom solaris-9-sparc-installation.iso \
-nographic -net bridge -net nic,macaddr=aa:00:00:00:00:a0 \
-prom-env "auto-boot?=false"

Modern QEMU complains if you use a raw disk but don't tell it that you're using a raw disk, thus the -drive argument rather than just using -hda.

The -nographic option basically runs it in the terminal window rather than simulating the framebuffer, which is great because it runs much faster and the only supported framebuffer resolution is big and unwieldy.

I'm also using bridged networking. Here's a little info on that.

The weird -prom-env argument keeps it from trying to boot. There are various issues related to using the QEMU -boot option. If you tell it to boot to the CD, it does ok, but it universally attempts to boot to the wrong disk partition. It seems better to boot manually from the OpenBIOS prompt.

Also, the Solaris 9 distribution comes with a bunch of CD's, including an Installation disc, 2 Software discs, a Supplements disc, and Companion CD. I configured QEMU to boot to the installation disc here.


Running that QEMU command dropped me to an OpenBIOS prompt, where I booted to the CD, in single-user mode.

boot cdrom:d -vs

(-v means verbose, -s means single-user)

If you do this, and you look carefully, you'll notice something like this scroll up the screen:

        Corrupt label; wrong magic number

As neozeed has pointed out before, Sun-provided disks were apparently pre-formatted, but if you used a non-Sun disk, you had to format it yourself, or the installer won't recognize it. My QEMU disk image was certainly a non-Sun-provided disk.

The single-user boot dropped me at a root prompt, and I ran the "format" command.


Which disk? Disk 0. What disk type? Other.

And then it prompted me for a dozen odd parameters. The important ones were:

  • data cylinders: 24622
  • heads: 27
  • data sectors/trac: 107
  • disk type name: qemu

I accepted defaults for the others.

BTW, the reason I used a 36G disk, in particular, is because those parameters are known to work with a 36G disk. Sun disks apparently have odd geometries, and the old geometry calculator web page is long gone.

After that, I labelled the disk, quit and rebooted.

format> label
Ready to label disk, continue? y

WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0):
        Corrupt label; wrong magic number
format> quit
# reboot

Ok. Disk formatted. Time to get down to business for real.


At the OpenBIOS prompt, I booted to the CD normally:

boot cdrom:d -v

This time, no "Corrupt label" errors.

The installer ran, I chose to install in English. Then it wanted a location to copy the installation software to. I allowed it to repartition the disk, accepted the default 512MB swap slice size, and allowed it to start the slice at beginning of the disk. The installer then copied itself to the disk and attempted to reboot.

But, since I'd disabled auto-boot, I had to tell it where to boot:

boot disk:b -v

At this point, the installer would sometimes just run, or other times crash. If it crashed, I could restart it by running disk0_install, and then it would run fine. I never figured out exactly why it was crashing sometimes. Later I read that maybe giving QEMU more memory (using -m 256) might have fixed the problem. I never tried that though. Your mileage may vary.

When the installer came up, it was intuitive. I supplied various networking parameters, time zone parameters, and a root password.

Then, after the weird (but familiar) Web Start message...

Solaris Web Start will assist you in installing software for Solaris.

(Whatever Web Start means)

...the installer asked a few more intuitive questions and asked for Software Disc 1.

If I'd been installing on real hardware, the CD tray would have been ejected and it would have been clear that I needed to change CD's. Everything being virtual, I didn't realize that I needed to do anything, and forgot that there are like 5 CD's with software on them, so it took me a while to realize that I needed to switch into the QEMU monitor and change CD's.

(qemu) change scsi0-cd2 solaris-9-sparc-software-disc1.iso

But after I figured that out, and hit return, and went through a few more prompts, the installer continued with a crude (but familiar) progress bar.


Then it wanted Software Disc 2.

(qemu) change scsi0-cd2 solaris-9-sparc-software-disc2.iso

And there was more of the same, before it finally tried to reboot again.

Once again, I had to specify the disk and partition to boot to:

boot disk:a

Though this time to a different partition, and without the verbose flag.

The installer wasn't done yet though, it wanted the Supplements CD.

(qemu) change scsi0-cd2 solaris-9-sparc-software-supplement.iso

And it installed a some stuff that I recognized like Java3D and OpenGL, but then also stuff like PC Launcher, PCfileviewer, RSC, SunForum, SunHSI PCI, and SunVTS. What are these things?

After a few more prompts, it tried to reboot again, and again I told it to boot to disk:a...

boot disk:a

But this time, everything started up for real.


I could log in as root, and networking worked on the first try!

Post-Install Tweaks

So, I now had a working Solaris 9 Sparc installation. I hadn't seen such a thing in more than 10 years.

But the system as it was, wasn't all that useful yet. I wanted languages (well, other than java) and compilers and web servers. Companion CD to the rescue...

I swapped the CD again:

(qemu) change scsi0-cd2 solaris-9-sparc-software-companion.iso

And, after a bit of trial and error, figuring out which device was the CD, mounted it and ran the installer.

mount -F hsfs /dev/dsk/c0t2d0s0 /cdrom
cd /cdrom

But it failed miserably because it's requires a graphical environment to run. Fortunately, I had one of those, just not on that machine.

Locally, I gave the VM permission to use my display:

xhost +

And then ran the installer, piping it's display here:

DISPLAY= ./installer



It took a while to start up, and there were a bunch of intuitive prompts, and it took a really long time to install, but eventually, it did, and I had most of the utilities I'm so accustomed to having.

I did need to tweak a few things though.

First, sudo had the wrong permissions.

chmod u+s /opt/sfw/bin/sudo

Second, even though I had a 36G disk, the root division is only 2G, and it was getting full, so I moved /opt/sfw to /export/home (which had a ton of space), and symlinked it back to /opt.

cd /opt
mv sfw /export/home
ln -s /export/home/sfw sfw

I also wanted to add some paths to everyone's PATH, but vi didn't work very well. The TERM environment variable is set to "sun" by default, but even setting it to xterm, vt100 or vt220 didn't help. I'm not sure why exactly, but I was eventually able to get it to work by running a dtterm (which supports the "sun" terminal type) and editing /etc/profile from there:

DISPLAY= /usr/dt/bin/dtterm

And then in that terminal:

vi /etc/profile

I added the following, near the top:


I also created a user for myself:

useradd -m -d /export/home/dmuse dmuse
passwd dmuse

And I gave myself some sudo privileges, though the sudoers file was in /usr/sfw/etc/sudoers rather than /etc/sudoers.

ssh appeared to be running, but I enabled X11 forwarding in /etc/ssh/sshd_config

X11Forwarding yes

...and restarted it.

/etc/init.d/sshd stop
/etc/init.d/sshd start

I was then able to ssh into the VM, and run X apps without having to fiddle with the DISPLAY variable.

All right!

The Web

Solaris 9 comes with some version of Apache. I copied the example config file.

cd /etc/apache
cp httpd.conf-example httpd.conf

And tweaked a few things (in httpd.conf):

AddHandler cgi-script .cgi
Options Indexes FollowSymLinks MultiViews ExecCGI
DirectoryIndex index.html index.cgi

And restarted apache.

/etc/init.d/apache restart

And wrote a quick and dirty CGI (/var/apache/htdocs/env.cgi)

echo "Content-type: text/plain"

And it worked!


Solaris 9 also comes with Netscape Communicator 4.78 which tries to go to and crashes unless you manage to stop it in time. It appeared to support png's but that's about the most modern thing it could do.


Ok, so all that had been fun, but could I get any of my software to run?

Turns out yes. I'd gotten it to work on Solaris 9 x86 long ago, and wrung out all the endian, alignment, and 32/64-bit issues over the years. The companion CD provided all the dev tools that I needed, including gcc 2.95.3. Pretty old, but good enough.

I was able to build and install Rudiments and SQL Relay and access Oracle 12 via an SQL Relay server on another machine.


The companion CD came with MySQL too, Relay found it, and built a connection plugin for it, but it was such an old version that it was incompatible with modern MariaDB:

mysql_real_connect failed: Client does not support authentication protocol requested by server; consider upgrading MariaDB client

Yeah, pretty old:

/opt/sfw/mysql/bin/mysql  Ver 11.15 Distrib 3.23.43, for sun-solaris2.9 (sparc)

I have various versions of Oracle for Sparc Solaris. One of them probably works on Solaris 9.

Fun for another day.


Having used Solaris 9 on x86 quite a bit, it was very familiar on Sparc. Backspace is delete and /home is /export/home, but I'm used to that. The most difficult thing to deal with was the inability to use vi on the console, and that wasn't too big of an issue. Other than that, it does slam the host cpu, so I can't just leave it running, but I think it does that on real hardware too, so it's not unexpected.

I've been collecting versions of Sparc Solaris for a few years now, in the hopes that someday QEMU/OpenBIOS might support it. Yeah, I know you can use the Sun ROMs but the dubious legality of those isn't my style. It's really great to find that it all works now. I'll have to try out some of the other versions soon too.

Friday, May 8, 2015

UnixWare 7.0.1

This one's been a long time coming.


Months and months ago I acquired a scattered collection of old SCO software from a seller on eBay. It included a random hodgepodge of all kinds of stuff; a dozen manuals, dozens of CD's and floppies, packs and packs of licenses... It took a few hours just to sort out what went with what. Among the haul: a complete copy of OpenServer 5.0.0, two complete copies of OpenServer 5.0.2, and the license pack for UnixWare 7.0.1, but no UnixWare media. Seriously?! What happened to the media?

At the time I was a bit frustrated, but not terribly because I had plenty to play with. In fact, I still haven't gone through most of it. And, so I just sat on the licenses and waited.

Months later, someone was selling a copy of OpenServer 5.0.5 and the photos showed media for UnixWare 7.0.1 included in the pile. This wasn't too surprising though. SCO used to give away promotional copies of UW 7.0.0 and 7.0.1 with OSR 5.0.5. In fact, that's how I was first exposed to it, way back. They didn't give away licenses though. You could install everything, but you only had about 60 days to play with it before the demo timed out.

But, I had an actual license! And a few days later I had media to go with it!


Still, it was a few weeks later before I had enough time on my hands to start trying to get it to run. That turned into a bit of an adventure too.

Here's how it went.


Actually, first... What the heck is UnixWare?

I'm a little fuzzy on the history actually.

Novell and somebody else (AT&T?) got together at some point in the early 90's to put together a version of SVR4 Unix that could interoperate with Novell NetWare, for some reason. I'm not sure what the motivation was, actually. But they succeeded, released a few versions, and eventually got the attention of SCO. At the time, SCO had OpenServer, which was an SVR3 implementation. UnixWare had feature-parity with OpenServer, aside from the configuration interfaces and back-compatibility with older SCO platforms. I guess they figured it would be easier to buy an SVR4 platform and port their goodies to it than rework OpenServer.

Whatever the motivation, SCO bought UnixWare, or licensed it, or something, and made several 2.x releases. In the late 90's Sun released Solaris version 2.7 as "Solaris 7". SCO was coming out with another version of UnixWare around then, and rather than name it 3.0, they named it "UnixWare 7" as well.

SCO made a few more releases and tried to get everyone to migrate from OpenServer to UnixWare, but there weren't a lot of takers. SCO's users had legacy apps galore that still needed to run, like apps written in FoxPro for 3.2v4.2, and apps written in Microsoft Basic for Xenix, and instances of Oracle7. They could recompile their modern C/C++ apps, but FoxPro, MS Basic, and Oracle7 didn't even run on UnixWare. Those apps would have to be completely rewritten in different languages or migrated away from SCO platforms. No thanks.

SCO tried a few stunts. Unixware 7.1.2 was released as "OpenUnix 8", for example, but people stuck with OpenServer. Eventually, SCO released OpenServer 6, which piled everything that everybody liked from OpenServer (including back-compatibility) onto a UnixWare base. It looked and felt like OpenServer, ran all the legacy apps, but it was UnixWare underneath.

Technologically, they'd finally achieved what both they and their users wanted, but it might have been too late. When OSR 6 was released, SCO's courtroom shenanigans had turned the world against them. I wonder how many takers OSR6 actually has.

But I digress. My adventure begins about half of that story ago, with version 7.0.1, right about when SCO got serious about trying to get everyone to migrate off of OpenServer.

Here's how it went. (For real, this time)

VM Configuration

I'd had good success with various OpenServer's in VMware, but UnixWare is a totally different breed. Turns out it'll run too, but only if you're careful about how you do it.

In particular, UnixWare can't make heads or tails out of VMware's IDE emulation. SCSI's the way to go. And, in particular, BusLogic SCSI. Don't even fool around with LSI, it's not going to work. The hard drive has to be SCSI, and so does the CD ROM.

But, UnixWare 7.0.1 predates bootable CD's by a year or two, so you've got to come up with some boot floppies. None came with my CD, but it turns out there are floppy images on the CD. Not in an intuitive place, mind you, but they're on there. It took a little bit of digging, but I found them under INFO/IMAGES. The files are named BOOT.IMA.1 and BOOT.IMA.2. There are other disk images there too, but they're not necessary for VMware installation.

Installation basically involved adding a floppy, aiming it at BOOT.IMA.1 and powering on the VM.

Right away I was greeted with the familiar UnixWare splash screen.

unixware 7.0.1 - 1. splash

And the installation was kind-of straightforward.

I answered a few intuitive questions, swapped floppies when prompted, answered a few more intuitive questions, eventually answered some less-intuitive ones...

Do I want to enter the DCU? Maybe. What's a DCU? Ahh, "Driver Configuration Utility." I'm not sure. As it turns out, letting it auto-configure is the way to go.

The installer detects the emulated PCnet ethernet card but the driver has a lot of trouble with it. The "IBM PCI Ethernet" driver works well though.

Configuring TCP/IP is intuitive, except that you can select the ethernet frame format. The default of ETHERNET_II works well though.

Since this is UnixWare, it also supports IPX, and as it turns out, IPX can't not be installed. That's OK though, the defaults seem to work.

Unfortunately, NIS also can't not be installed. I gave my installation an NIS Type of "client" and NIS domain of "firstworks" and as I have no NIS servers anywhere, left the optional NIS servers blank.

Just about everything else was totally intuitive, and before too long, the installation proceeded unattended.

unixware 7.0.1 - 2. install

When the installation was complete, I had to disconnect the cdrom and floppy before reboot. Failing to do so resulted in several very insistent messages.

On reboot, I got a funny message about swap being smaller than memory. I'd given my VM a monstrous 256MB of RAM. In the late 90's, 32mb would have been a lot.

I also got some apparently-unimportant SCSI errors and a bunch of messages about configuring NetWare and other things. Eventually I had to configure the mouse and then it asked me to insert disc #2 to continue installing the system. I only had 1 system disc though. The other disc was the development system. I tried that disc, but apparently that's not what it was looking for. It also didn't like it when I gave it the first disc again. Oh, well. Eventually I just hit F8 to defer that step. It then prompted me for disc #3 and I just deferred it again. I might have chuckled a little too.

Fortunately it didn't ask me for disc #4, but instead started doing boot-type things and eventually presented me with a CDE login.

unixware 7.0.1 - 3. first boot

All right!

Post-Install Tweaks

Logging in got me to a familiar CDE desktop.

unixware 7.0.1 - 4. cde desktop

But, not a lot worked. I could poke around the system, but it was an island unto itself. I couldn't ping, ftp or telnet to anywhere.

This took days to figure out.

It turned out that there were two big problems. First, though above I say "the PCnet driver sucks, use the IBM PCI Ethernet driver", I hadn't done that at this point. I was still using the PCnet driver, which sucks. Tremendous packet loss.

After switching to the IBM PCI Ethernet driver, things were a lot better, but I couldn't yet tell that they were.

It eventually turned out that NIS was wreaking widespread havoc. I never figured out exactly what was going wrong, but my guess is that the /etc/hosts file is an NIS-able file, and since there were no NIS servers anywhere, all DNS lookups had to wait for an NIS timeout before proceeding past the /etc/hosts file. The effect was that if I tried to ftp or telnet to somewhere, it would hang for quite a while before actually trying the address. Telnetting or ftp'ing in from other hosts would hang too, during the reverse-lookup. If I waited, each these operations would eventually succeed, but in the beginning, I wasn't patient enough to realize this.

Once I did determine that NIS was the culprit, disabling it was still fairly tricky. I had to edit /etc/init.d/nis, set the domain to an empty string early in the file:


And then also comment out the setting of the variable "d" because the domainname program would somehow still return my domain, even though domain has been set to "".


But! After that, and a reboot, everything started working really well.

I was able to download a bunch of useful software from the SCO Skunkware FTP site, but unfortunately none of it worked without first installing a libc patch. Apparently the shared version of the libc that ships with 7.0.1 is missing some symbols. Weird. The patch fixed it though.

So I installed that patch, and several bits of software, like bash, sudo, gzip, etc., all using the standard SVR4 package management tools, which are worth discussing a bit.

Package management on UnixWare, while SVR4-compliant, is (not-unexpectedly) archaic. There's no dependency-resolving "yum install xxx" or "apt-get install yyy". You just download a .pkg file, hope it doesn't have any not-too-obvious dependencies, and install it in a completely unintuitive manner.

For example, if you download a file named xxx.pkg, then you'd install it using:

pkgadd -d `pwd`/xxx.pkg

The -d meaning "the packages are contained on this device or in this directory".

What? I'm trying to install the package xxx.pkg, why do I declare it to be the directory containing packages?

Well, the pkg file is actually a cpio archive.


In antiquity, packages weren't distributed individually. Dozens of expanded package trees were cpio'ed en-masse to a tape, and the tape was distributed. If you aimed pkgadd at the tape device, like pkgadd -d /dev/rmt0, or similar, it would tell you what packages are available and allow you to install one or more of them at a time. If you already knew which one(s) you wanted to install, you could supply the name(s) on the command line too.

As hard drives got bigger, someone got the idea to distribute packages as individual files, rather than collected up on tape. And, since on unix, everything is a file, pkgadd doesn't care whether the argument to -d is a file or a device, as long as it's a cpio archive.

Clever. Agreed. But completely unintuitive.

In fact, the man page for pkgin doesn't help much either. It goes on and on about how -d can refer to a directory, or a pipe, or a device (like a tape), and about the default locations, and other stuff, and unless one notices that -d can refer to a "directory, file, or named pipe", and it occurs to one that file might mean .pkg file, and that .pkg files might simulate tapes, then one might overlook that option altogether.

That's what I did, way back, when I first encountered UnixWare, and it drove me nuts. Even after I figured out the whole file=tape thing, I still couldn't get it to work because the fact that the argument to -d has to be the full pathname to the .pkg file is not mentioned ANYWHERE, AT ALL!

Somewhere I found an example though, and had to laugh, in hindsight, at how obvious it should have been.

Remote Access

It was fun using the CDE desktop and all, but not practical in the long run. Telnet worked, but it's difficult to automate.

OpenSSH packages were available, but they were apparently built for a later version of UnixWare. sshd kept complaining about libc missing the strlcmp function.

No problem though, I've built OpenSSH for a bunch of old Linux and Solaris platforms. Maybe I could get it to work on UnixWare too.

I had to install a few packages first though. OpenSSL for starters, and it required prngd and zlib. Also, I didn't have a lot of faith in the native development system, so I installed gcc-2.95.2pl1 too.

And, it turned out, building OpenSSH-3.4p1 from source was quick and easy.

./configure --prefix=/usr/local/openssh-3.4p1
sudo make install

Configuring it was familiar from OSR5 too.


X11Forwarding yes
UsePrivilegeSeparation no

And I created an init script at /etc/init.d/sshd...


case "$1" in
        kill `ps -efa | grep sshd | grep -v grep | cut -c10-15`
        echo $"Usage: $0 {start|stop}"
        exit 1

exit 0

...made it executable, and set it up to run at boot:

chmod 755 /etc/init.d/sshd
cd /etc/rc2.d
ln -s ../init.d/sshd S98sshd

The last step was to uninstall OpenSSL. Oddly, for both UnixWare and OpenServer, the OpenSSL packages only contain static libraries. This creates problems for my software, and since once OpenSSL is compiled it no longer needs the OpenSSL libraries, it's safe to remove the packages.


unixware 7.0.1 - 5. ssh

Remote access!

But, it wasn't perfect. ksh on UnixWare is all but unusable over SSH. Neither backspace nor delete work. Bash worked though, so it was easy enough to work around.

I could ssh out too.

Looking good.

File Transfer

As mentioned earlier, ftp worked pretty well. OpenSSH came with scp and sftp. I'd installed gzip earlier. UnixWare comes with tar and cpio, though neither can gunzip on the fly. Packages for GNU tar, as well as zip, unzip and bzip were all available from skunkware.

After installing a few more packages, I was well equipped to transfer files.

The Web

No system is complete without being able to get on the web, right?


UnixWare 7.0.1 came with Netscape Navigator 3.0.4. Cutting edge for 1999, but it struggled pretty badly with today's web.

I installed wget and lynx packages from skunkware though. Good old lynx.

On the server side, things were slightly better.

UnixWare comes with the Netscape FastTrack web server. To turn it on, you have to log into a CDE desktop, run SCOAdmin and select Netscape Server Admin. This launches Netscape and aims it at FastTrack's web-based configuration interface.

After logging in as admin and using the password for the root user, you get this snazzy UI.

unixware 7.0.1 - 6. netscape fasttrack web server

The toggle switch on the left is for the web server on port 80. Switching it to the "ON" position started up the web server, and it was immediately accessible from my local browser.

unixware 7.0.1 - 7. default web page

Oh yeah!

It took a bit of digging around in the interface, but I figured out how to enable CGI's and a quick "print out the environment variables" script worked.

Skunkware packages for Apache were also available, but I didn't try them. Maybe later.


The CDE login and desktop was enabled by default.

It can be disabled using:

scologin stop

And re-enabled using:

scologin start

When disabled, running startx from the command line, surprisingly, didn't start a CDE session though.

unixware 7.0.1 - 8. non-cde desktop

Weird. I'd apparently never done that before because I didn't recognize the desktop from OpenServer, UnixWare, or anywhere else.

It turns out that it is possible to get a CDE session with startx though, if you first create a .xinitrc file containing:


There were Skunkware packages for GNU make and CVS. What about the compiler though?

Well, I'd intalled gcc earlier to build OpenSSH, but I had 2 CD's. One with the OS, and the other with the development system. And, I had actual licenses for it in the same pack as the OS licenses.

The OpenServer development system isn't super mature, at least as of OSR 5.0.5. There's no support for 64-bit integers, and the C++ compiler is just a c-front and both quirky and not terribly capable with templates, even simple ones. I wasn't sure about the UnixWare development system though. Back in the late 90's, I never got around to playing with it.

Now would be a good time, I figured.

The CD had a README on it, so I followed its instructions to run the Development System's installer.

unixware 7.0.1 - 9. dev system

Turns out, it installed the C and C++ compilers, a ton of libraries and headers, and Java version 1.1.3. Whooo! 1.1.3. That's a blast from the past.

The UnixWare C++ compiler was a lot more capable than it's OSR cousin. In fact, calling them cousins isn't even inaccurate. It didn't appear to be a c-front, and compiled my Rudiments library with only a few tweaks.

But, when I got around to running the tests, I discovered one of its deficiencies. Like earlier versions of gcc, it didn't handle nested template invocations correctly. Darnit.

There were issues with variadic macros too, but I could just comment those out. The template thing was a show-stopper.

That's OK, there's always gcc, right?

Not exactly.

I'd installed gcc-2.95.2p1 earlier, and it was able to compile all of my software quite easily, but when I tried to run just about anything, I'd get a segfault, almost immediately.

I tracked it down to a dynamic linker error of some sort. Basically, my charstring class had an overloaded compare() function with two different signatures, and attempts to call the one with 3 arguments would crash.

I'd actually seen this same error on OpenServer 6 years ago, and eventually fixed it by compiling gcc-2.95.3, with some SCO patches from source, using the native compiler.

No such luck though. Same error.

I tried other versions of gcc-2.95.x, both packages and builds from source. Nothing worked. At best I'd get the same error. At worst, the compiler would segfault. Eventually I gave up.

And that's where it sat, for months. Sometimes you've got to get away from a problem for a while though. This afternoon I took another look at it. I noticed that there were Skunkware packages for older versions of gcc, like 2.8.0 and the egcs compilers. I couldn't remember if I'd tried them before or not.

I must not have because the compiler from the egcs-1.1.1 package ran without segfaulting, and produced working code.

The rudiments tests mostly ran fine. SQL Relay built and the command line client ran.

unixware 7.0.1 - 10. sqlrsh

SQL Relay supports lots of languages and database backends, but unfortunately not many of them are well supported on UnixWare 7.0.1.

I couldn't get it working with Perl, Python, PHP, TCL, Ruby or Java. In some cases, even the oldest language package was clearly meant for a newer version of UnixWare. In other cases, there were odd header quirks that prevented them from compiling cleanly. I'm not sure what the issue is with Java yet. By rights, it ought to work but I get weird errors at runtime.

Things weren't any better on the database front. PostgreSQL was the only database available, and the only package that would install was for version 6.5.3 - older than the oldest version I've ever tried before. UnixODBC was available, but the package was for a newer version of UnixWare.

SQL Relay builds against that old PostgreSQL, but there's some shared-memory-related issue that keeps it from running.

Ehh, who knows. There's always some quirky thing with every platform.

That's where I left it.

Quirks and Endearing Features

So, what's weird about UnixWare 7.0.1?

Not all that much, actually, especially given it's age.

The most significant thing is an issue with the filesystem. It's very easy to run out of inodes, waaaaay before you run out of space:

bash-2.05a$ df -v /
Mount Dir  Filesystem           blocks      used     avail  %used
/          /dev/root          16000740   1538304  14462436   10%
bash-2.05a$ df -i /
Mount Dir  Filesystem            iused     ifree    itotal %iused
/          /dev/root             55862      9674     65536   85%

Multiple times I had to tar and zip stuff up and delete directory trees to free up enough space to untar something else. It looks like they're using a 16-bit number for the number of inodes. I guess back in the day, when a 1.6G hard drive was gigantic, file systems would have been smaller, there would have been more of them, and that was enough. But I'd swear that one of the selling points of UnixWare was support for petabyte and exabyte sized volumes. Maybe the filesystem does support more inodes, but there's no option for it at install time, and 65536 is a small default.

Other quirks...

The ksh shell has trouble over ssh, neither backspace nor delete work.

The halt and reboot commands are in /usr/ucb, which isn't in the default PATH.

Adding directories to the PATH is remarkably difficult. /etc/profile exports PATH before setting it. Lord knows where it's getting the default PATH from. Also, CDE sessions don't appear to source /etc/profile at all. Again, it's unclear where their PATH is set.

socklen_t is defined but a lot of network functions use size_t instead.

The chmod command accepts a shorter argument list than commands like cp. I had to update several Makefiles to work around this.

If you make a change that requires a kernel relink, the relink is done during the reboot, not before. As such, there's no unix.old to boot to until after the boot fails. Actually, for that matter, it's not clear how to get to a bootloader prompt.


Strange, old unix.

Gotta love it.

Thursday, November 20, 2014

Sudo on Minix 3.1.8

Minix 3.3.0 came out a while ago and I had all kinds of fun playing with it.  I'd long been running 3.2.1 but never gave 3.1.8 a try at all.  The fun I had with 3.3.0 got me motivated though and a few weeks back I gave it a shot.

It was fairly straightforward, for the most part.  A few things here and there reminded me of 2.0 but the overall user experience was similar to 3.2.1.  Getting various bits of software running required many of the same tweaks that 3.3.0 and 3.2.1 required, but the most difficult bit by far was sudo.

Sudo 1.7.something-or-other is available via pkgin but it dumps core whenever you do anything with it.

Sudo version 1.6.9p23 has been reliably portable for me though, so I gave it a try.  It took a while to work around various issues, but eventually I got it working.  If anyone out there is interested, here are the tricks:

The code requires a little hackery.

Add the following line after the includes in interfaces.c


Edit and comment out:

# include <search.h>

it should look like this when you're done:

/*# include <search.h>*/

Minix 3.1.8's implementation of getgroups always returns -1.  This causes a few problems for sudo.  To solve them, edit set_perms.c and make 3 modifications.

Make the declaration of runas_groups (around line 376) look like:

static GETGROUPS_T *runas_groups = NULL;
Update a section of the function runas_setgroups() as follows:

    if (runas_ngroups <= 0) {
        pw = runas_pw ? runas_pw :;
        if (initgroups(pw->pw_name, pw->pw_gid) < 0)
            log_error(USE_ERRNO|MSG_ONLY, "can't set runas group vector");

        if ((runas_ngroups = getgroups(0, NULL)) > 0) {
            runas_groups = emalloc2(runas_ngroups, sizeof(GETGROUPS_T));
            if (getgroups(runas_ngroups, runas_groups) < 0)
                log_error(USE_ERRNO|MSG_ONLY, "can't get runas group vector");

    } else {

Update the function restore_groups() as follows:

static void
    if (user_ngroups > 0) {
        if (setgroups(user_ngroups, user_groups) < 0)
            log_error(USE_ERRNO|MSG_ONLY, "can't reset user group vector");

That third modification is actually a workaround for a bug (or feature) in setgroups().  It goes completely haywire if user_ngroups is -1.  I'll bet that this is the problem that the version of sudo available via pkgin has too.  There might be a libc update that fixes this issue but for now we'll just work around it.

Now build and install.  Some options needs to be enabled in the header files with the _POSIX_SOURCE macro, so we'll pass that in.  I also like to install it under it's own directory tree, so I use the --prefix option for that.

CPPFLAGS="-D_POSIX_SOURCE" ./configure --prefix=/usr/local/sudo-1.6.9p23
make install

The default permissions are wrong for Minix though, so they need to be set manually:

chmod 555 /usr/local/sudo-1.6.9p23/bin/sudo
chmod u+s /usr/local/sudo-1.6.9p23/bin/sudo

Now add a line for your user (dmuse in my case) to /etc/sudoers.


Yes, the sudoers file is installed under /etc independent of the --prefix option used earlier.  The NOPASSWD option makes it so you don't have to enter a password.

And the last step is to add /usr/local/sudo-1.6.9p23/bin to your PATH in ~/.ashrc

export PATH=$HOME/bin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:\

And that's it.  Re-login and sudo should work as expected.

$ sudo ls -l /
total 44
drwxr-xr-x  2 root  operator   2880 Sep  4  2010 bin
drwxr-xr-x  3 root  operator    384 Sep  4  2010 boot
drwxr-xr-x  2 root  operator  29120 Sep 20 02:47 dev
drwxr-xr-x  3 root  operator   2304 Nov 20 22:53 etc
drwxrwxrwx  5 bin   bin         320 Sep 20 02:55 home
drwxrwxrwx  2 root  operator    128 Sep 20 02:45 mnt
drwx------  2 root  operator    768 Sep 20 04:09 root
drwxr-xr-x  2 root  operator    896 Sep  4  2010 sbin
drwxrwxrwt  2 root  operator    640 Nov 20 23:52 tmp
drwxrwxrwx 23 bin   bin        1536 Sep 20 03:27 usr
drwxr-xr-x  3 root  operator    256 Sep 20 02:45 var

Woohoo!  Sudo on Minix 3.1.8.

Thursday, October 23, 2014

Solaris 2.6 x86


If you search eBay for "Solaris" you'll find a lot of people selling old copies of 2.6, but all of these copies are for the SPARC platform. 2.6 for Intel was alleged to exist, but after leaving a fruitless search going for months and months, I started to wonder if it was a myth.

And then, one day, out of the blue, something turned up. It was too good to be true. I didn't believe it at first. But there it was. Solaris 2.6 for Intel.


When it came in the mail, I was even happier. The packaging might have been reused from something else, but boy was it cute.

solaris 2.6 - 1. packaging

Also, the shipper included a little note on cat-themed stationery thanking me for my purchase, AND refunding me my change from shipping! kri-bri - best seller ever.

I was so wrapped up admiring the packaging that I almost forgot about what was inside. But there it was, the mythical Solaris 2.6 for Intel, shiny and still shrink-wrapped.

solaris 2.6 - 2. box

It almost felt wrong to open it. "Fortunately" I didn't have to right away. I was really busy at the time so all I could do for a week or more was put it on the shelf and wait for a break.

VM Configuration

(Two Weeks Later)

Not terribly long ago I'd managed to get the unexpectedly less-rare Solaris 2.5.1 x86 running in VMware 8.0.6. It had required jumping through a few hoops. Even longer ago I'd installed Solaris 7 x86, and in comparison, it had required jumping through flaming hoops while riding a unicycle. I was curious where 2.6 would fall on this spectrum and a little nervous that it might require some set of new gymnastics.

Turned out there were few surprises.

Through trial and error I discovered that 2.6 only supports about a 4G disk. Or, at least that a 4G disk image works but an 8G does not. You can install to an 8G disk, but you can't boot from it after installation. Or at least I couldn't get that to work. So, 4G disk.

128mb of memory seemed to be enough. I told VMware that the guest OS was Solaris 8. I removed the sound card, and aimed the virtual floppy at the Solaris Device Configuration Manager image.


Right away I got an odd error:

    Loading driver blogic.bef
Failed to initialize host adapter

It looked like Solaris wasn't too happy with VMware's Buslogic implementation. My virtual drives were on the virtual IDE controller though, and it turned out I could just hit return to keep going.

The rest of the installation was straightforward-ish. It was a lot like other Solaris installations, with some of the same quirks. It didn't ask for DNS info or a default route. Several times it tried to get me to run kdmconfig and I had to either Bypass or Bypass and Suppress it.

The oddest thing was disk partitioning, but it was no odder than usual. In fact it was exactly the same as 2.5.1 and 7. You have to uncheck and re-check c0d0 (c-zero d-zero) or the installer will think that it has partitions defined even though it doesn't. Also, the default filesystem layout includes a small root and large /export/home and the editor for removing /export/home and resizing root isn't very intuitive.

But I was used to that, did that, and pretty soon it looked like this:

solaris 2.6 - 2. install

The main installer ran for a while, then it appeared to install some updates. I'd told it to not to auto-reboot so I'd be able to remove the floppy. When it was done it dropped me to a root prompt, I removed the floppy, halted the system and rebooted.

solaris 2.6 - 3. first boot

All right!

Post-Install Tweaks

Everything wasn't perfect yet though.

Even though I'd bypassed and suppressed configuration of the graphical environment it still tried to start anyway, so I disabled it for real.

dtconfig -d

Fortunately the emulated PCNet NIC was recognized (unlike in 2.5.1), but the installer didn't ask for a default route or DNS info so I configured that manually too.

Default route:

echo "" > /etc/defaultrouter




hosts: files dns

I rebooted after that step to make sure everything network-related came back up correctly on restart, and it did.

The default path didn't include some important stuff, so I updated /etc/profile


I'd told the installer not to create a /export/home partition, but if you don't create the partition then the directory doesn't even get created. This is where home directories are created by default though, so I added it.

mkdir /export/home

I also added a user for myself.

useradd -m -d /export/home/dmuse dmuse
passwd dmuse

And I added /usr/local and /opt/sfw because I intended to install some software in those locations later.

mkdir /usr/local
chmod 777 /usr/local
mkdir /opt/sfw
chmod 777 /opt/sfw

As with Solaris 2.5.1 and 7, software was difficult to come by. There's plenty of source code out there but what was I going to compile it with?

Also as with 2.5.1 and 7, the solution was to build a compiler targeted for 2.6 on a different version of Solaris. This time I built gcc 2.95.3 on Solaris 9. I first tried building on 11 and 10 but the versions of gcc that I had installed on those systems appeared to be too new to build 2.95.3.

On Solaris 9, I ran:

./configure --prefix=/usr/local/gcc-2.95.3 --host=i386-pc-solaris2.6 --target=i386-pc-solaris2.6 --enable-shared
gmake install

Then I tarred up /usr/local/gcc-2.95.3, ftp'ed it over to the 2.6 VM, untarred it in /usr/local and added /usr/local/gcc-2.95.3/bin to my PATH.

As if by magic, I could now build software in my 2.6 VM.



Now that I had a working compiler, I rebuilt gcc natively and installed it under /opt/sfw.

CC=gcc ./configure --prefix=/opt/sfw --enable-shared
make install

I removed /usr/local/gcc-2.95.3, removed it from my path, added /opt/sfw/bin to my path (and /opt/sfw/lib to my LD_LIBRARY_PATH) and used the new gcc to build a bunch of other stuff: gzip-1.3.12, bash-1.14.7, sudo-1.6.9p23, perl-5.003_07, openssl-0.9.6h, zlib-1.2.8, openssh-3.1p1, GNU tar-1.13, apache-2.0.65, lynx-2.8.7, wget-1.5.3, cvs-1.11.23, GNU make-3.82, vim-7.4... Maybe some other stuff too.

I configured everything to install under /opt/sfw and just about everything compiled cleanly.

openssh required line 58 of openbsd-compat/bsd-snprintf.c to be commented out:

/*# undef HAVE_VSNPRINTF*/

I think that was all though.

Remote Access

It's fun to work on the console for a while, but it does get old. After building and installing openssh, I created an init script for it at /etc/init.d/ssh


case "$1" in
        killall sshd
        echo $"Usage: $0 {start|stop}"
        exit 1

exit 0

...and set it up to run at boot:

chmod 755 /etc/init.d/sshd
cd /etc/rc3.d
ln -s ../init.d/sshd S90sshd

I tried enabling X-Forwarding in /opt/sfw/etc/sshd_config

X11Forwarding yes

...but for whatever reason it never worked.

But, after starting ssh

/etc/init.d/sshd start

I could log in remotely.

solaris 2.6 - 4. ssh

I could also scp files back and forth.

The Web

I'd built and installed lynx and wget earlier and they both worked as expected.

Netscape 4.78 was available and worked but struggled hilariously with modern websites.

solaris 2.6 - 5. netscape

It did support PNG's though, which I didn't expect.

The hotjava web browser was also available but it struggled even more. Side note though... I think Solaris 2.6 was the first version to support java (version 1.1.3 no less), or at least to ship with support for it.

On the server side, I was able to get Apache working but I had to do the same Group trick that I did under Solaris 7. By default, Apache is configured to run as Group #-1. On most systems, group id's are 16-bit, -1 translates to 2^16-2, and the "nobody" group has that group id. Apparently, on Solaris, group id's are 32-bit, "nobody" has an id like 60001, and it couldn't make any sense of #-1. This fixed it though:

#Group #-1
Group nobody

I added an init script for it too, at /etc/init.d/httpd


case "$1" in
        /opt/sfw/bin/apachectl start
        /opt/sfw/bin/apachectl stop
        echo $"Usage: $0 {start|stop}"
        exit 1

exit 0

...and configured it to run at boot.

chmod 755 /etc/init.d/httpd
cd /etc/rc3.d
ln -s ../init.d/httpd S90httpd 
X Windows

Solaris 2.6 comes with Sun's X server but it doesn't support VESA framebuffers so under VMware it's limited to 16-color VGA mode at 640x480.


Binaries of XFree86 4.7.0 are available for Solaris 2.6 at And they work!

They do take a little coercion though.

To get it working, I downloaded the following files:


Then I ran:

sudo sh

The prompts were intuitive and I installed all optional components but I told it not to create links for opengl or rstart.

I also added /usr/X11R6/bin ahead of other paths in the PATH variable and added /usr/X11R6/lib ahead of other paths in the LD_LIBRARY_PATH variable.

Configuring XFree86 (xf86config) took some trial-and-error but I eventually got it. The important settings are:

  • mouse protocol: 1. Auto
  • monitor: 2 31.5 - 35.1; Super VGA, 800x600 @ 56 Hz
  • vertical sync range: 4 40-150
  • yes, look at a card database
  • card: 0 * Generic VESA compatible
  • video memory: 3 1024K
  • color depth by default: 4 16 bits (65536 colors)

The color depth appears to have to be the same as the depth of the host display.

After configuration the mouse didn't work, but editing /etc/X11/XF86Config manually and commenting out the following line seemed to fix it:

    #Option "Device"      "/dev/mouse"

After all that I was able to get a simple X session running with startx.

Running openwin gave me an OPENLOOK session.

solaris 2.6 - 7. openwin

I was able to get a CDE session by creating an .xinitrc with:


...and running startx.

solaris 2.6 - 8. cde

A graphical login was a little more difficult.

It turns out that the dtlogin program runs /usr/openwin/bin/Xsun directly, and passes it an option that the XFree86 server doesn't understand, so I replaced it with a script that removes the option:


ARGS=`echo $@ | sed -e "s|-nobanner||g"`

/usr/X11R6/bin/X $ARGS

I'd had the same issue with Solaris 7 though, so the solution was familiar.

Enabling dtlogin was simple.

dtconfig -e

It didn't work perfectly though. As on Solaris 7, I could login and run a CDE session, but I had to use ctrl-backspace to exit the session and get back to the login.


I had previously built and installed all the tools I usually use to build my software, so I gave it a try.

Rudiments required one modification. I'd added a hack at some point for FSU pthreads on SCO something-or-other, but then later disabled FSU pthreads support but forgot to remove the hack. The hack caused a problem on Solaris 2.6 and removing it solved it.

Everything else built cleanly and I was able to run the SQL Relay client software.

solaris 2.6 - 9. sqlrsh

I'd really like to get the SQL Relay server running on Solaris though.

I'm still looking for a version of Oracle or Sybase or DB2 or something that'll run on older Solaris x86. I remember seeing Oracle 8.0.5 on eBay once, but only once. I guess I should have jumped on it then.

I probably should try to build MySQL, PostgreSQL, Firebird and SQLite. I'm not sure how much work that would be but if I could get it going then it'd at least be something.

Eh, something to work on later.

Endearing Features

Solaris 2.6 has the standard set of Solaris quirks: you have to use delete for backspace on the console, home directories are created in /export/home, the default shell doesn't understand ~/, filesytem performance is not so good under VMware (untarring and rm -rf'ing take a while) and setting the domain in /etc/resolv.conf requires the "domainname" keyword rather than "domain".

2.6 also only supports 4g disks, which make sense, given its vintage - 1998. Unfortunately it also makes host cpu run at 100%. I can't say that was unexpected either though, as both 2.5.1 and 7 do the same.

So there you have it. Solaris 2.6 x86. About what I expected. Not too surprising. Not too disappointing.

I'll have to try to get more software running on it though - databases, maybe some old java. Yeah, that would be fun.