/usr/libexec and /usr/local/libexec do not (and should not, I suppose) exist under a standard Ubuntu install, and yet the packages contain references to them.

In particular, replacing them by /usr/lib/ and /usr/local/lib in

/usr/lib/python2.6/winswitch/utils/paths.py at lines 126 and 128 (+/- 1) is needed for the server to start.

There are a number of obstacles which prevent us from following the instructions on ​dev/win32.

For some dependencies, it is just a question of doing more manual work than running the 64-bit version of the installer, as is the case for ​setuptools and ​python wmi.

Then there's the problem that by default, you can't compile 64-bit programs with distutils and VC 2008... (see ​http://bugs.python.org/issue7511 and use this patch: ​http://bugs.python.org/file17959/vcvars4.diff - why isn't this merged and released??)

Unfortunately, other dependencies are even harder to deal with:

• ​pygtk (or even just plain GTK for that matter) do not provide 64-bit installers at present, and building from source is too tedious: see ​this discussion for details.
• ​gstreamer does not provide a 64-bit version, all the bindings are for 32-bit python only at present...

Xvfb is old and it is missing a number of useful X11 extensions, also the alternatives may offer better keyboard support? The idea of using those as an alternative to Xvfb is not new either, see ​x11vnc faq-xvfb

Information about dummy driver is scarce, but there is some in ​XorgTesting

The easiest way (which seems to work ok) is to use ​Xdummy (GPLv2+)

One of the most important benefits is that these alternatives also support randr so we could envisage resizing the buffer to the size needed by the client currently connected rather than the default huge size we have at the moment.