As part of the Gnash buildbot farm, I run several virtual machines as build slaves. I started with VirtualBox because it is free software and I prefer to support free software, but it’s still a bit too fragile and it still lacks x86_64 guest support.

When I discovered that VMware Server is now available for free–well, free as in beer, anyway–I happily installed it and set up some new VMs on it. Best of all, it supports x86_64 guests! Of course, now I have the problem of migrating those VirtualBox guest VMs over to VMware.

VMware uses its own VMDK format for storing virtual disk images, while VirtualBox uses its own VDI format. The first step is getting a copy of vditool, VirtualBox’s command line program for manipulating VDI files.

The host OS I used to run VirtualBox is Ubuntu‘s 8.04 Hardy Heron on AMD64. The VirtualBox 1.6.0 .deb package didn’t include vditool, for some reason. Fortunately, the VirtualBox package in Debian’s “lenny” release includes it, so lets just grab it from there.

$ wget http://http.us.debian.org/debian/pool/main/v/virtualbox-ose/virtualbox-ose_1.5.6-dfsg-6_amd64.deb
$ dpkg -x virtualbox-ose_1.5.6-dfsg-6_amd64.deb vbox-1.5.6
$ sudo cp vbox-1.5.6/usr/lib/virtualbox/vditool /usr/lib/virtualbox/vditool
$ sudo ln -sf /usr/lib/virtualbox/vditool /usr/bin/vditool

There, now we have vditool installed. Next, we use it to export our old VirtualBox VDI back to raw disk data. However, if you used VirtualBox’s “Snapshots” with differencing VDI’s, you need to discard all snapshots before the one you want to write out as the raw disk: only the “base” data gets written out, not the “Current State”.

$ cd ~/.VirtualBox/VDI
$ vditool copydd win2000-i386-32gb.vdi win2000-i386-32gb.dd
vditool    Copyright (c) 2004-2008 innotek GmbH.

Copying VDI image file="win2000-i386-32gb.vdi" to DD file="win2000-i386-32gb.dd"...
The operation completed successfully!

Be careful, this could consume a lot of disk space, if you were using compacted VDI’s instead of fixed size as the raw image will be the full size of the disk image, which in my case was 32 GB even though the VDI only took ~6.5 GB on disk.

Once we have the raw data, we can create the VMDK metadata for our DD image. We compute the size of the raw data in sectors by dividing its size in bytes by 512:

$ stat --printf="%s 512/p" win2000-i386-32gb.dd | dc
67108864

We also need to compute the CHS geometry of the virtual disk. I used the assumption of 255 heads and 63 sectors:

$ stat --printf="%s 512/255/63/p" win2000-i386-32gb.dd | dc
4177

Once we have that information, we go ahead and create the VMDK metadata. Change the elements highlighted in blue as appropriate for your system:

$ cat >win2000-i386-32gb-flat.vmdk <<-__EOF__
# Disk DescriptorFile
version=1
CID=4dd210c6
parentCID=ffffffff
createType="monolithicFlat"

# Extent description
RW 67108864 FLAT "win2000-i386-32gb.dd" 0

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "4177"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "buslogic"
__EOF__

There, we now have a VMDK suitable for use in VMware! But, it takes up all 32 GB of space on the disk while only ~6.5 GB is actually in use. Lets use vmware-vdiskmanager to create another VMDK that is growable, instead:

$ vmware-vdiskmanager -r win2000-i386-32gb-flat.vmdk -t 0 win2000-i386-32gb.vmdk
Using log file /tmp/vmware-dossy/vdiskmanager.log
Creating a monolithic growable disk 'win2000-i386-32gb.vmdk'
  Convert: 100% done.
Virtual disk conversion successful.

And there you have it: a growable converted VMDK from VDI:

$ ls -lh win2000-i386-32gb*
-rw------- 1 dossy dossy  32G 2008-05-23 11:26 win2000-i386-32gb.dd
-rw------- 1 dossy dossy  327 2008-05-23 13:40 win2000-i386-32gb-flat.vmdk
-rw------- 1 dossy dossy 6.5G 2008-05-23 14:25 win2000-i386-32gb.vdi
-rw------- 1 dossy dossy 6.3G 2008-05-23 14:20 win2000-i386-32gb.vmdk

From here, I created a new virtual machine under VMware Server, specifying “Custom” and using an existing virtual disk–the one I just created.

Of course, I couldn’t just boot this VM up because the virtualized hardware from VirtualBox differs from the virtualized hardware in VMware, and the particular VM in question is a Microsoft Windows 2000 guest. To fix the Windows install, I performed a “repair installation” of Windows 2000. I guess this is necessary when you change all the hardware out from underneath a Windows machine. After completing the repair installation, the VM booted up! I went ahead and installed VMware Tools, rebooted, and now everything works as expected.

I don’t know how many folks out there want to migrate away from VirtualBox to VMware, but I couldn’t find very much useful information on doing it so hopefully this will help people out who want to do it.

Tags: HOWTO, VirtualBox, VMware

After Callum let me know that the Linux binary of the character counting plugin for Pidgin worked on Fedora 8, I decided to spin a RPM built on Fedora 8 proper. After a bit of reading and hackery, I have produced a x86 RPM for Fedora 8. Here’s the source, which includes the patch and the .spec file, as well as the RPM:

• pidgin-convcharcount-plugin-2.4.1.tar.gz
• pidgin-convcharcount-plugin-2.4.1-1.fc8.i386.rpm

I’ve also spun a new Debian binary, as well:

• pidgin-convcharcount-plugin_2.4.1-1_i386.deb

And, if you’re looking for the Win32 binary, you can still get it off this page.

I’m glad so many of you out there who use Pidgin find this plugin useful. Thanks for all the positive feedback.

Tags: Pidgin, Twitter, Fedora 8, RPM, Debian

I’m setting up a virtual machine using VirtualBox on Ubuntu Gutsy, running Win2000 as the guest OS. I’ve gone and installed Cygwin and MinGW and MSYS in order to build Gnash on Win32. I came across a funny bootstrapping problem trying to install pkg-config: pkg-config 0.22 requires glib 2.x in order to compile. No sweat, I go and download glib 2.13.6 and configure it … and the configure script stops with an error when it can’t find pkg-config installed!

Circular dependencies suck.

Of course, in the README.win32 for pkg-config, Tor Lillqvist acknowledges this at the end of the document:

On Unix, pkg-config is built using its own copy of GLib 1.2.8. On Windows, we use the normal GLib available for Windows (2.0.x). Yes, this does introduce a kind of circular dependency. But, that can be worked around. The circular dependency only appears if one uses the configure mechanism to build GLib. GLib’s configure script checks for pkg-config. pkg-config depends on GLib. Thus, starting from scratch, with no GLib and no pkg-config, using configure, there would indeed be a Catch-22 situation. However, GLib can be built just fine using the manually written makefiles for mingw or MSVC. And if somebody does want to build GLib on Win32 using configure, she can first install a prebuilt pkgconfig.

Unfortunately, as of glib 2.13.6 at least, only the automake files are included–no ordinary makefiles for Win32, either MinGW or MSVC, even. Fortunately, older releases of pkg-config source are still available, and glib 2.13.6 will build with pkg-config 0.14 or newer. pkg-config 0.14 includes glib 1.2.8 and tries to build it as part of its build, so I went ahead and tried to build pkg-config 0.14. Since nothing is ever easy, I ended up having to make a slight change to glib 1.2.8 to get it to compile, adding these lines to the top of glib.h, after the #include <glibconfig.h>:

#undef G_MAXINT
#define G_MAXINT 0xFFFF
#define SIGCHLD 17
#define g_ascii_strcasecmp(a, b) strcmp(a, b)
#include <fcntl.h>
#include <winsock.h>

I also discovered that gthread.o wouldn’t compile right due to some libtool weirdness, so I had to compile everything somewhat manually with this:

$ cd glib-1.2.8/gthread
$ gcc -I.. -DHAVE_CONFIG_H -DG_OS_WIN32 -o gthread.o -c gthread.c
$ touch gthread.lo
$ cd ..
$ make libglib.la
$ cd ..
$ make CFLAGS="-DG_OS_WIN32" parse.o
$ make pkg-config.exe
$ cp pkg-config.exe /mingw/bin

After all that, I finally had a compiled and installed pkg-config 0.14! I went ahead and used it to build glib 2.13.6 and installed that, then went and built pkg-config 0.22 with it.

So, which came first? The chicken or the egg?

Tags: Open Source, MinGW, glib, pkg-config

What have I been furiously hacking on the last few nights? Gnash, the GNU Flash player. Specifically, I’ve been doing a lot of hacking on support for Win32. More specifically, I’ve been working on npgnash, the plugin that embeds Gnash inside Firefox using the Mozilla NPAPI.

I’m not going to get into the ugly details of what I went through to get as far as I have, but I’ll summarize it as: a hell of a lot harder than it ought to have been. I’ll save my rant for why C++ sucks, so badly, for another day. What you really want to see are screenshots, I know!

First, here’s the entry for npgnash from Firefox’s about:plugins page:

Okay, big deal, so I can load a DLL. Here’s npgnash playing gravity.swf from the Gnash testsuite, right in the browser:

Who doesn’t love a big bouncing smiley-face animating across their browser, right? But, the true test is playing my favorite YouTube video … to test with, at least:

Yup, that’s no joke … it’s a screenshot of npgnash playing a YouTube video inside Firefox 2.0.0.12 on my WinXP machine. It’s using the Anti-Grain Geometry (AGG) rendering engine, along with SDL/ffmpeg for audio … and they both work, albeit not very well, yet.  Still, not bad for three or four days of hacking, right?

Despite all this progress and these screenshots, it’s still not ready for general-purpose use, yet. The underlying Gnash code is still isn’t fully re-entrant/thread-safe and the cleanup code isn’t fully baked so I can’t even load one SWF after another without it crashing. I also haven’t implemented any mouse/keyboard support, so you can’t actually use any of the player buttons you see in the YouTube video, etc., yet.

Still, it’s a great start and hopefully by the time the 0.8.3 release is ready in a few months, there will be a lot more forward progress.

Tags: Gnash, GNU Flash, Firefox, Mozilla NPAPI, Win32

Yesterday, Maki asked on Twitter, “I would love to have a ‘Quick unsubscribe’ button for Google Reader…a greasemonkey script would be terrific. Anyone wanna do one?” Of course, it seems I have a thing for hacking out little web toys for people I know on Twitter, so I gave it a whack.  Here’s the result:

• google-reader-unsubscribe.user.js

Here’s a screenshot showing what it does:

It’s a pretty simple script. The hardest part was reverse-engineering Google Reader’s packed/minified JavaScript, but that wasn’t too hard.

Do you have a useful idea for a web toy? Perhaps if you run it by me and it interests me, I’ll hack on it for you, too.

Tags: Google Reader, Greasemonkey, scripting, hacks