Mr Bill always seems to have the most interesting web tidbits on his blagh. This South Park characature editor is actually the most interesting of the self tests and such. It's not based on some web persona's interpretation of how you answer a bunch of questions, but how you decide to create the character. Now if doing things like manipulating the image to have a transparent background was as easy as creating the South Park character persona... (at least until I found a more pleasing background).

Ben

Surely you jest. Windows 98? Yep. It's kind of Microsoft's bane. I didn't believe it when I heard it, but one of the target markets of Sun's Java Desktop System was the Windows 98 Desktop replacement market. I guess when you're looking at a site license for Win2K, WinXP or Windows 2003, or just the incrmental upgrades, $50 a pop for JDS looks like a pretty good deal, especially with Star Office thrown in the mix. And that also means it should run decently on on PC's that are a couple of years old.

Why Windows 98 under Solaris?

Most of the applications that I find myself lacking for Solaris X86 include the normal kinds of things that day-to-day desktop users need. A browser, a couple of of plugins, a couple of applications that probably everyone needs, like media players (other than the M$ one). And then there are the ubiquitous Windows upgrades, since it is Windows. In about 2 hours of part time work, I managed to load all the windows 98 updates, Mozilla, Firefox, Thunderbird, Adobe Acroread 6.0,Quicktime, the Macromedia Flash and Shockwave plugins for both Internet Exploder and the Mozilla family, Real Player, and TightVNC. Shock. The Solaris X86 community has been complaining about this for *years*. Adobe didn't do Acrobat Reader 7 for Windows 98, but Acroread 6 is better than the ancient Acroread 4.05 which was the last supported version for Solaris x86. Xpdf and Gpdf are allright but there always seems to be some document which doesn't render correctly. Macromedia finally got on board and there's a Flash plugin for Mozilla 1.4 for Solaris X86, though no Shockwave, and RealPlayer is still a noshow. If you really want RealPlayer for Solaris X86, Juergen Kiel in Germany figured out how to write a shim so we could use the UnixWare (This still has me baffled why UnixWare had a port and Solaris X86 did not) RealPlayer 8 plugin. You can find the code to make it work at The Solaris X86/Real Player Wedge web site. Now that I have all those tools, the other reason is Windows 98 is lightweight enoughto run decently under QEMU's emulation. As I pointed, it's pretty ubiquitous, so finding a copy should be dead easy, and it doesn't requires that NTFS which Solaris doesn't have any support for, unless you use my hack from yesterday to use Knoppix to get at the NTFS file system.

Installing Windows 98 under QEMU on a Solaris/X86 Host

So you need a couple of things. 1) Windows 98 (SE Preferably) media and license. An ISO image will do just fine to. 2) Disk space for the ISO and IMG files 3) a couple of hours or more depending on the speed of your machine, and the amount of memory you can give the QEMU guest VM. If you don't want to be flipping CDROM's more than once, I prefer to use unix "dd" to turn them into ISO images. I have finally gotten used to the Solaris vold (though I know people who still hate it, I have my days too) so here's how we do this:

    # Put the Win98 CD in your CD/DVD Drive
    $ eject -q cdrom       # or cdrom0 or cdrom1. Whatever your solaris system uses

    $ cd /export/src/iso          # and have at least 450MB of free disk space for the Win98SE ISO

    $ dd if=/vol/dev/rdsk/c1t0d0/win98 of=win98se.iso bs=10240k

    # If someone has a way of doing this with cdrw, let me know and I'll modify this. I don't see
    # a way around this other than stopping a copy halfway through, so that seems more of a hack
    # than using "dd" 

Next, we need to make an image for Windows 98 to reside in. We whip out qemu-like

    $ cd /export/src/images
    $  mkdir Win98SE; cd Win98SE
    $ /tmp/qemu/bin/qemu-img create -f qcow win98se.img 2G    # We can always grown this later

Next, I find it easier to prepare the disk by hand, than to let Windows 98 do it's thing. So I cheated to bootdisk.com and got a Windows 98 Boot disk, and started qemu with that like:

    # from /export/src/iso/Win98SE
    $ /usr/sfw/bin/wget http://www.mirrors.org/archived_software/www.bootdisk.com/winfiles1/boot98se.exe
    $ unzip boot98se.exe    # Since it is a self-un-archiving exe, unzip works fine on it.
    #
    # now start a basic qemu just to get the disk made
    #
    $ /tmp/qemu/bin/qemu -fda winb98se.IMA -boot a -hda win98se.img
    #
    # the normal windows 98 boot disk comes up, run fdisk, allocate the 2G of space to
    # primary DOS partition, then run format/s c:.  Once the format is complete, you can
    # reboot to verify you can see all 2G of the C: drive, or take it for granted that it
    # worked, and exit via "[CTRL-ALT-2], then "quit".

Next we setup the QEMU environment for loading Windows 98/SE. Decide how much memory you're going to use, etc, and use a variation of the script from the first day, to start qemu:

    $ /tmp/qemu/bin/qemu -cdrom win98se.iso -user-net -enable-audio \
                         -pci -m 256 -k en-us -boot d -hda win98se.img
    # and go through the normal Windows 98 install.
    # when complete, shutdown and if you're paranoid, make a backup copy of win98se.img.

Using the Solaris Samba server to provide writable space to the Windows 98 Image

Using ftp in a QEMU Guest OS can be kind of a pain, especially since the firewalling done by QEMU and it's slirp network stack. I've found that under a Solaris X86 guest, a ftp client called "lftp" actually works pretty good, and is available from blastwave.org using pkg-get. But trying to fight the Windows 98 Command.exe and FTP.exe is hopeless. So, it turns out to be very easy to enable Samba so you can use native Windows 98 File sharing back to the host.

    $ mkdir /export/src/samba; chmod 755 /export/src/samba  # or whatever permissions float your boat.
                                                              # only the QEMU guest instance will have access
    $ cd /export/src/samba
    # first thing to do is get windows 98 to properly use the HLT command so when
    # idle, it's not sucking the CPU like crazy. It's on the samba share so
    # we can just run the install once we have it mounted.
    #
    $ /usr/sfw/bin/wget http://www.user.cityline.ru/~maxamn/amnhltm.zip
    $ mkdir win98hlt; cd win98hlt; unzip ../amnhltm.zip
    #
    # start Windows 98 for the first time since the install, note the change in
    # the "-boot" parameter from "d" to "c"
    #
    $ /tmp/qemu/bin/qemu -cdrom win98se.iso -user-net -enable-audio -pci -m 256 \
                -smb /export/src/samba -k en-us -boot c -hda win98se.img
    #
    # This boots windows, and login normally.  Open a COMMAND prompt and  enter
    #
    C:\WINDOWS> echo "10.0.2.4 smbserver" > lmhosts
    #
    # or use notepad.exe, but be sure to make sure it saves it as "lmhosts", 
    # or you rename it from lmhosts.txt to lmhosts. This cost me about an hour 
    # today debugging this since notepad.exe added the ".txt" extension to the file.
    # when done, you should have a file called "C:\WINDOWS\LMHOSTS.
    #
    % Right Click on "Network Neighborhood", and select "Map Network Drive"
    # QEMU setup an internal IP address in the user-net stack that connects 10.0.2.4
    # as a proxy to the Solaris Samba server, that QEMU starts up when you request to
    # map a drive.  
    #
    % Map "\\SMBSERVER\QEMU" to drive "E:"
    #
    # If this happened succesfully, Windows opens an explorer window on "E:"
    #
    # In the command window you have open, type
    $ E:
    $ cd win98hlt
    $ AMNHLT.BAT       # This installs the sequence to use the CPU HLT instruction.
    # close the command prompt
    #
    % Open DISPLAY under the Control Panel and go to Effects and turn off most of the
    % visual effects. Things like annimation and such go a long way to making Windows 98
    % under QEMU not feel so sluggish.  While you're in the display panel, change
    % the resolution and color depth to something more pleasing.  The Cirrus Logic
    % GDM 5446 chipset can do 1280x1024 @ 16-bit color with little issue. There is
    % probably not much to be gained by going to 24-bit color, and it will be 
    % slower.  If you need 24-bit color, you should be asking yourself if you 
    % don't need a specific PC for that application.
    #
    # At this point, you can run windows update, and get as much stuff updated as
    # possible.  The updates don't take too long on a 2Ghz Athlon.  Once you have   
    # the updates done, it probably a good time to stop the system, and make a backup
    # of the current image.  Just in case something goes wrong.  My image turned out
    # to be about 250MB at the time of the great IE6 Update.

So at this point, you should have a working Windows 98 SE install, all patched up, with visual effects turned down to minimum and the HLT cpu instruction enabled, and you can start loading your favorite batch of applications. And making backups is as easy as copying one big file.

On my laptop, I have a hibernation partition on P1, WinXP [ntfs] on P2, and Solaris Next on P3. Since Solaris cannot natively read an NTFS partition, I'd like to be able to read my files off of my WinXP partition without having to use something like a FAT32 partition to transfer data around. Since Knoppix can read an NTFS partition, I figured I should try and see if I can get to the data. It's a bit convoluted to do it this way, but it prevents having to reboot Solaris to get back to Windows XP so I can transfer some files. So I start qemu like this, still booting from the cdrom image, and assigning -hdd to be the primary Solaris fdisk partition /dev/rdsk/c0d0p0 on my laptop. Of course, unless you're running qemu as root, you won't have access to the physical partition as a user. We will setup access to the raw device for read only access by running the following command, as root, against the physical device's acl, for the user running qemu to access the NTFS partition.

    $ su root
    # getfacl `ls -l /dev/rdsk/c0d0p0 | sed 's,.* -> ../..,,'`

        # file: /devices/pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0:q,raw
        # owner: root
        # group: sys
        user::rw-
        group::r--            #effective:r--
        mask:r--
        other:---
    # setfacl -m user:bent:r-- `ls -l /dev/rdsk/c0d0p0 | sed 's,.* -> ../..,,'`
    # getfacl `ls -l /dev/rdsk/c0d0p0 | sed 's,.* -> ../..,,'`

        # file: /devices/pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0:q,raw
        # owner: root
        # group: sys
        user::rw-
        user:bent:r--
        group::r--            #effective:r--
        mask:r--
        other:---

I use the -snapshot to prevent any writes from happening to the disk, just as a matter of caution, even though I'm defining the boot device as -boot d. I do the following as the user which was given the acl read rights to the device:

    /tmp/qemu/bin/qemu -cdrom /vol/dev/rdsk/c1t0d0/knoppix -user-net -enable-audio \
                         -pci -m 256 -k en-us -boot d -snapshot -hdd /dev/rdsk/c0d0p0

At the Knoppix boot prompt, I type:

    boot: knoppix dma screen=1152x864

and wait for Knoppix to boot. If all goes well, you should see a couple of "Hard Disk" icons on the desktop, and since Knoppix sets up the mount entries, the knoppix user (non-root) is allowed to mount the drive. Verify that the partition that has the NTFS file system on it is listed in /etc/fstab in your Knoppix file system. Then just use the mount command with the mount point that corresponds to the mountpoint in the /etc/fstab. In my case, /dev/hdd2 is the location of the NTFS file system.

    $ mount /dev/hdd2

If there are no errors in the mount, then you should be able to cd /mnt/hdd2 and see the NTFS file system under Knoppix. There should be no problems because by default, Knoppix will mount the NTFS file system read only, which is all you need to access the files so that you can copy them from NTFS to the Knoppix image, and then transfer them out of the Knoppix virtual machine using ftp, scp, or samba (which I haven't figured out how to setup yet).

Using this configuration, is a perfect example of using a quick start configuration. It turns out that leaving the NTFS file system mounted in the QEMU Knoppix session caused the quick start to be something more like 60 seconds, rather than the 10 seconds I was seeing off a standard config. It also might have something to do with using the "-snapshot" option. I plan on doing some more testing.