The Lone C++ Coder's Blog

The Lone C++ Coder's Blog

The continued diary of an experienced C++ programmer. Thoughts on C++ and other languages I play with, Emacs, functional, non functional and sometimes non-functioning programming.

Timo Geusch

4-Minute Read

I had been thinking about setting myself up with a way to work from home in a disconnected fashion. Most of the places I’ve worked at in the past required me to remote into the work desktop, which is a good idea if both sides have 100% uptime on their network connection and no issues with them being affected by adverse weather. Which in reality means that the connections tended to be unstable if the weather dictated that one really, really wanted to work from home on a particular day because snowfall was horizontal, for example. My current employer is more enlightened in this matter so my suggestion of locking all the necessary tools and source code inside a VM that would allow me to work from home even if the Internet connection was unavailable at either end was given the go ahead. Given that my desktop here is plenty powerful for most development tasks (it’s an older Intel Mac Pro with dual Xeons), this should be an idea solution.

Only, with the VM software I was trying out, the virtualised disk throughput was lacking a little. The product I’m working on uses Qt and it took a day to build the commercial version of 4.7.4 inside the VM, with one of the Xeons allocated to VM duty. Oops. Some more digging pretty much confirmed that the main issues was the disk throughput or lack thereof. At this point I came across Scott Hanselman’s article on how to boot Windows off a VHD. My understanding is that Bootcamp only supports booting of a single Windows partition so this sounded ideal to me - just put a VHD with all the tools and the source code on the boot partition I already have, then boot from the VHD if I need to. Donn Felker’s blog entry on booting off a VHD on a Bootcamp’d Mac added the one missing piece of information, namely that one should ignore the warning from the Windows 7 installer that the disk (VHD) you’re about to install on isn’t support and that there might be driver issues. Just go ahead and do it anyway.

After the installation and dropping all the tools on the VHD - I’m getting a little too familiar with the Visual Studio installer by now - Qt built pretty much in the expected time and the project itself can also be build within a reasonable amount of time. My guess the build is 5%-10% slower than on the work machine, but the work machine is building on an SSD and obviously hasn’t got a virtualised hard disk to deal with either. On the other hand my own machine has the benefit of 8 real cores.

Why all the effort? I don’t like mixing work projects and my own stuff, for starters. If I can lock work into a VM or at least some kind of a sandbox, there’s less of a chance of accidental cross-pollination between the two and no licensing headaches either. The latter is especially important to me as there are some software licenses that are “duplicated” in the sense that I have both a work and a personal license. And of course there’s the little detail that the work VM data can simply be destroyed by deleting the VM/VHD if it proves necessary.

Even though I did originally intend to only set up a single VHD for work purposes and keep all the personal software and data on my main disk, I’ve ended up creating a second VHD specifically for a couple of car racing simulators that I use (iRacing and rFactor). I’m not a big gamer but I do like track driving in the real world and using the simulators tends to help with familiarising yourself with a track, plus it helps in the off season, too. iRacing had a bit of a problem with the various bits of security software I have installed on my main Windows and given that I had a spare license anyway, it made sense to put it in its own “virgin Windows” sandbox. No issues since. Well, none related to the software…

Recent Posts



A developer's journey. Still trying to figure out this software thing after several decades.