PureBasic Survival Guide XII - VirtualBox
PureBasic Survival Guide
a tutorial for using purebasic for windows 4.60

Part 0 - TOC
Part I - General
Part II - Converts
Part III - Primer I
Part IV - Primer II
Part V - Advanced
Part VI - 2D Graphics I
Part VII - 2D Graphics II
Part X - Assembly
Part XI - Debugger
Part XII - VirtualBox
Part XIII - Databases
Part XIV - Networking
Part XV - Regular Expressions
Part XVI - Application Data
Part XXVII - Irregular Expressions
Part XXIX - Projects

Part XII - VirtualBox
v1.15 23.03.2012

12.1 That. Which. Is. Not. Pure.
12.2 Sample network.
12.3 Installing VirtualBox.
12.4 Creating and cloning VM's.
12.5 Installing host and guest.
12.6 Why? (Reprise)

12.1 That. Which. Is. Not. Pure.

This section has pretty much nothing to do with PureBasic, however I've found VirtualBox so essential in my work that I can't hold it away from you. Of course, you could also choose MicroSoft's VirtualPC, or VMWare, but I just happen to like this one.

Keep in mind that I'm not trying to create a VirtualBox support page... Everything on this page is in pursuit of PureBasic happiness! :-)

I've been using different versions over time, and I decided to leave some comments on older versions in here. There may be reasons to keep using an older one (such as Sun's horrid nag screen) or some of the information concerning an older version may apply to a yet to be released future version. Hmm. Yes. Some creative interpretation may be required.


Many people asked the same question. Well, "just because" might be one, but (un)fortunately it isn't :-)

Why? Because it can make life a lot easier when testing network code, or testing your application on different OS'es. Do you want to have multiple PC's around just to check if your code works on all those different configurations? No, you don't. (Although you still may need to if you're doing graphics, or doing other hardware dependent things. In which case VM's may not work but multibooting may be a solution for you.) VM's are also a great way to develop network applications on a single machine, as long as things do not get time critical (the VM's may not be fast enough to handle multiple instances of a game at once, and you can forget about mulitiple 3D capable clients on the same host).

A VM or Virtual Machine is like a PC running in its own little world / window inside your PC. If you are developing a client / server application you can simulate two PC's on your machine, all within immediate reach. No need to get up and walk to the other PC (the one which the kids are using MSN on, or the other one your wife is using to browse the net, or the third one, the one that you are using to download... euh... just dowload... things.. you know).

You can't expect the impossible from a VM. It's slower (as parts of it are emulated), and it'll eat up memory and diskspace. But it allows you to run multiple configurations / OS'es on the same machine simultaneously. And there's no rebooting (as is necessary with multiboot solutions).

Once our VM's are up and running, we can start fooling around with it... some suggestions at the bottom of this page.


Get a copy of VirtualBox and install it...

On most machines it will work without a hitch, though I've seen some problems with the floppy drive handling, where it lists the contents fine, but the actual files itself contain nonsense. This may be hardware related, but it certainly is an issue on my Dell XPS710. No problems with VMWare here... Also on my old Asus K8N-E with an Amd64 there were no problems. Oh well, the problem only shows up when using the physical floppy drive, everything else seems to work fine. (If you try to load up your old MSDos programs from good ol' floppy disks it's a pain in the but though, but that's where my old Dell Lattitude with media bay and 3.5 FDD came in handy :-)) So MSDos 5.0 didn't work at all, but somehow that seems irrelevant when it comes to PureBasic :-)

Update: hardware dependencies may play a bigger role than I expected. Windows 98 ran fluently on my old Amd64 box, yet is unresponsive on my Dell. Interesting, but as I'm focussing on Windows XP not totally relevant for now.

During installation some pop-ups may do a pop-under... I.e. they stay invisible unless you move the top window out of the way, a rather confusing feature...

What you are testing and how you're testing defines how you have to setup your system and VirtualBox.

And here comes the first challenge: what version of VirtualBox? The latest, of course. Well... perhaps. Just to illustrate that latest is not always the greatest here's my pitfall with 2.2.2...

2.0.2 and 2.2.2

The latest may not always be the greatest. 2.2.2 is an improvement over 2.0.2, but not in all aspects. There's probably something broken in vboxmanage.exe. In 2.0.2 cloning works fine, but in 2.2.2 cloning Windows 98 failed. Digging a little deeper showed that newly cloned files became truncated sometimes. I couldn't get a Windows 98 .vdi cloned, and I did not trust the Windows XP clones that suddenly lost 200 MB in comparison with the original... (Although thatmight be explained by VirtualBox not just cloning the drive but actually rebuilding it.)You have to decide for yourself.

Note: if you downgrade from 2.2.2 to 2.0.2, you may have to empty some folders under 'Application Data'. 2.0.2 however is less comfy about bridging, where it takes a little handy work.


And then there was 3.0.4. After my troubles with 2.2.2 I was reluctant to install it, but couldn't help myself :-) I've been able to install this over an older version, and it automatically updated my VM's, but could not find the associated discs. To avoid problems it may be better to first deinstall any older versions of VirtualBox before installing 3.0.4. Make sure you don't throw away your virtual disks or virtual machines!

3.04 still would not read from my old 3.5" floppy diskdrive, but I suppose that's a hardware issue on my machine. (Hey, don't worry, I know diskettes are a thing of the past. But sometimes they're required when dealing with older hard and software...

Fortunately there are two ways around:

  • use another computer :-)


Move forward in time, it's 2012 and there's 4.1.4 now. I can definitely spot some improvements. 1. I can finally read my 3.5" disks properly, in spite of my silly (Dell XPS710) hardware. 2. I can clone VM's with a mouseclick. 3. I can clone my VDI images without having to resort to the command line. (It still takes ages though...)


New version, seems to work well.


New version, worked poorly on a new Windows 7 64 bit install. I went back to 4.1.8.


EMT4WIN is a tool that allows the creation of diskimages from floppydisks, and the other way around. If you're into old stuff, then here's your change to relive the old MSDos days! It's also the only way for me to feed VirtualBox any floppydisks, as the bloody thing messes up reading from the real physical drive A:... sigh. On the other hand, reinstalling from a bunch of images is way faster than reinstalling using original floppydisks :-)

Just for fun here's MSDos 5.00 and Norton Desktop running in VirtualBox. And wow, did I forget Norton Desktop for Dos came on 9 720 KB disks, those were the days...

One day I am going to find out how to access the network from that MSDos VM machine... I admit not very useful, but fun in a sort of sadomasochistic way :-)

12.2 Sample network

The trigger for me to experiment with VM's and VirtualBox was MySQL. I wanted to simulate a 'real life' situation. Have a look at the picture below.

The top half shows a network similar to my own. My primary PC is a Dell XPS710 (called 'workstation 1' in the sample above), quadcore, with sufficient RAM and a good graphic card. I also have an old PC called 'server 1'. Everything together is hiding behind a router / firewall / wifi hub.

'Server 1' is an old Compaq Deskpro, with a an old slot A Pentium III, 384 MB RAM, a 40 GB and a 60 GB harddrive . It has one advantage though: when it's not under load, the power supply fan goes silent. I added a single, very quiet fan to the case, and most of the time that machine stays silent. It's running a torrent client (so I don't have to keep my big machine up and running), a spam filter (K9), and contains whatever I want to share over all machines at home. In the future I plan to replace it with something more modern with a lot of diskspace, but for now it will do. The OS running on it is XP Pro, though a bit stripped and patched. It's not the kind of machine I would put a heavy MySQL burden on.

In the sample above, I've assigned fixed IP adresses to each of my machines. This makes life easier for simple people like me, that know little about DHCP, DNS, and so on... is my 'server 1'. It's a physical server with its own network card and IP address. is my 'workstation 1'. It's a big machine, and this is where I can install some VM's on, in the example above 3 called 'server 2', 'server 3' and 'server 4'.

Think of each VM as 'another PC' that will run inside my 'workstation'. For all practical purposes, each VM IS another PC, with its own IP address and so on. My 'workstation 1' is called the host, and each VM is called a 'guest'. The drawing above is a bit wrong, as I'm actually using adresses in the range for virtual machines with fixed IP's.

12.3 Installing VirtualBox

Download VirtualBox from http://www.virtualbox.org/ and install it. I'm using Windows XP everywhere, but nothing is going to stop you using something different. Settings differ, details differ, but the concept stays the same. Decide on which version.


Note that if you upgrade to 3.0.4 your VM's will be converted. But when you do a clean install there seems to be no way to import them... However the disk images are valid and a machine is easily made again, so not a big issue.


I had too many troubles with 2.2.2 and went back to 2.0.2. (2.2.2 caused me uninstall problems, left some data behind, and did not properly clode a .vdi file.)

(Non) certified drivers

During installation Windowx XP might complain about drivers that have not passed certification... too bad, just accept 'm. These messages pop-UNDER-ed on my machine so if everything seems to freeze you may have to move some windows around to reveal what's underneath.

Each VM uses two sets of information: a folder with its settings, and a folder with the used hard disk images. I think it's wise to put these on another harddrive, at least in some place where they are not automatically copied / backupped. Running Acronis TrueImage or something similar and then backup-ing all those VM hard drive images may be a waste of space, who knows... You can change the paths to these files from the File / Preferences menu in the VirtualBox application.

VM's and VDI's

When you delete a VM this may not automatically remove any associated disk images (.vdi files) so you may want to check this folder now and again and delete what you no longer need, to conserve disk space.

You cannot simply copy these files to create another VM, read the next section on cloning VM's and VDI's.

12.4 Creating and cloning VM's

Creating VM's

Create a new VM using 'New' and follow the wizzard. Give a sensible name, and specify the OS you are going to install on the VM. Specify how much memory you allocate to the VM (make sure you keep enough memory available for the host). I've been playing around with XP on low-end systems and found 192 MB to be the bottom for XP on real hardware. 256 MB of RAM seems to be optimal unless the applications you need are memory hungry. On a virtual machine it seems to need a little less, yet I do not know why.

Also decide on a harddisk size. Note that on slower machines 'dynamically expanding' drives may cause problems. (Though I've never run into it myself personally I'd rather be safe than sorry and just tried the regular settings.)

Remember that VirtualBox simulates a whole PC, it simulates graphic card, the whole chipset, network cards, hard drives, everything. When you install XP, XP is going to recognize some of those simulated devices, but not all. Don't worry. Just install XP, then after you've installed XP you will find a 'simulated CD' in the 'simulated CD rom drive' called 'VirtualBox Guest Additons'. Run that one and you have all the (remaining) drivers you need. It will also 'seamlessly' integrate the mouse and keyboard into your host machine.

If you install an OS on the VM for which there are no 'VirtualBox Guest Additions' then you'll have to use a key to have VirtualBox stop capturing your mouse actions. If I recall correctly this is by default the right Control key on your keyboard.

Key element is the network card and configuration, especially the field 'Attached to'. The older 2.x.x and 3.x.x have slightly different names options with quite different meanings, and without a doubt things will change in newer versions, be aware.


3.0.4's behavioiur confused me a little. (But I'm not the expert in these things so the probably root cause is me :-)) I had some troubles getting the VM's and the host to see each other, which turned out to be something I overlooked... the clients firewall. Sigh. Here are the steps I took:

  1. VirtualBox / File / Preferences / Networks: remove all 'Host Only Adapters', unless you need them for something :-)
  2. Windows XP / Control Panel / Network Connections: remove all network bridges and 'VIrtualBox Host Only Adapters'. You may have to use View / Refresh to see if anything is left.
  3. For each of your VM's set the network adapter to 'Attached to: Bridged Adapter'.
  4. Check if all OS'es (the host as well as the client) allow 'ICMP Echo' packages, otherwise 'ping' won't work. (Took me ages...)
No additional bridged adapters or anything else that shows up on the host, a vast improvement over the older versions.

Note: I had an old Windows 98 VM that wouldn't work in 3.0.4 until I disabled in the VM the option System / Acceleration / Enable VT-c/AMD-V.


Select 'Host-Only Interface', as in 2.2.2 things are easy: VirtualBox creates the bridge(s) for you. (But when you uninstall it it does not remove them, be aware.)


In 2.0.2 you have to do everything yourself. Take the following steps:

  1. In VirtualBox, first create one or more 'Host Interfaces', just as many as you want to run VM's.
  2. 'Attach' each VM to it's own Host Interface.
  3. In XP go to Control Panel / Network Connections.
  4. Select the 'Local Area Connection' and any 'Virtual Box Host Interfaces' (with Shift pressed)...
  5. Using the Right Mouse Button pick either 'Create Bridge' or 'Add To Bridge'.
Creating bridges may overwrite the IP settings of the host. Recheck your IP address after creating or removing a bridge.


Ever tried cloning / copying a working Windows XP install from one machine to another PC? You may have been in for a surprise (and not a pleasant one): your copy would not work. Windows would crash, or two cloned machines would not work (well) together on your network.

First the hardware issue: unless you're a huge company there's a pretty good chance each of your PC's differs from the other PC's in your home. Different brands / models all have different components on board. Windows XP uses specific drivers for each of those PC's. So, if you create an image using Ghost or TrueImage and restore that image on another machine with different hardware, you're got a 99.9% chance of Windows not working. There's however one good side to that story: as a VM uses simulated hardware, that simulated hardware is the same for each VM guest, no matter what the host platform is running (memory size and disk size won't matter). This means that you can create one VM / image and use it for multiple machines.
But... that's not the whole story. If you try to run a 'cloned' VM it'll work. But, if you try to run TWO 'cloned' VM's, they won't play nice when residing on the same network. This is because each and every install of Windows XP generates a SID, a unique number that uniquely identifies the machine, and which is different for each installation, even when hardware is identical. Re-install means you will get a new SID.


It's that easy to clone a VM machine that I won't even mention that you only have to press the right mouse button and select 'clone'... It even allows you to clone the associated VDI. Cloning the OS might take a bit more effort...


Cloning didn't seem to work well under 2.2.2. See here.

Cloning XP

So you need an unique SID for each WIndows XP install. MicroSoft has a solution for that called SysPrep. I hate it. But a little (unsupported) tool by SysInternals (now taken over by MicroSoft, duh?) fixes that. It's called NewSID. Copy it to your VM, run it, then reboot, and your VM will have received a new SID, which fixes potential interoperating problems on the network.

Cloning VDI

We're almost there. We've got one more problem: VirtualBox puts a unique identifier on each .vdi file. In other words: if we have one .vdi file called 'server1.vdi' and we simply copy it to 'server2.vdi' then VirtualBox is refusing to accept that .vdi file. Why? Who knows... 


Go into the Virtual Media Manager, select an image, and do a 'copy'.
Unfortunately, I have experienced some issues with cloned VDI's, couldn't figure out why yet. Cloning a whole VM including copying the VDI seemed to work fine, beats me...

2.0.2 / 2.2.2 / 3.0.4

The solution here is a utility called vboxmanage.exe. Unfortunately, that thing has a ton of options (check the different pages on the web to see what you can do with it). However, PureBasic to the rescue... The following little tool will allow you to pick a .vdi file, and clone it. Create an executable, copy it into your VirtualBox folder and run it. (It's just a wrapper but it makes life easier.)

; survival guide 12_4_300 clonevdi
; pb 4.40b3
; - simple wrapper for vboxmanage.exe to clone .dvi files
clonevdi_path.s = GetPathPart(ProgramFilename())
vdi_path.s = ReadPreferenceString("vdi_path","")
virtualbox_path.s = ReadPreferenceString(virtualbox_path,"c:\program files\sun\xvm virtualbox\")
create_prefs = #False
If virtualbox_path = "" Or FileSize(virtualbox_path+"vboxmanage.exe") < 0
  virtualbox_path = GetPathPart(OpenFileRequester("CloneVDI - Select vboxmanage.exe","c:\","Executable|*.exe",0))
If FileSize(virtualbox_path+"vboxmanage.exe") > 0
    vdi_source.s = OpenFileRequester("CloneVDI - Select source",vdi_path,"Virtual Disks|*.vdi|All|*.*",0)
    If vdi_source <> ""
      vdi_destination.s = SaveFileRequester("CloneVDI - Select destination",vdi_path,"Virtual Disks|*.vdi|All|*.*",0)
      If LCase(Right(vdi_destination,4)) <> ".vdi"
        vdi_destination = vdi_destination+".vdi"
      If vdi_source = vdi_destination
        result = MessageRequester("CloneVDI - Failed!","Source and destination cannot be the same!", 
        _ #PB_MessageRequester_Ok|#MB_ICONWARNING)
        If FileSize(vdi_destination) > -1
          result = MessageRequester("CloneVDI - Please confirm.","The file "+vdi_destination+" already exists." +
          _ "Overwrite?",#PB_MessageRequester_YesNo|#MB_ICONWARNING)
          If result = #PB_MessageRequester_No
           vdi_destination.s = ""
        If vdi_destination <> ""
          RunProgram(virtualbox_path+"vboxmanage.exe","clonevdi "+#DQUOTE$+vdi_source+#DQUOTE$ + 
          _ " "+#DQUOTE$+vdi_destination+#DQUOTE$,virtualbox_path,#PB_Program_Wait)
          If FileSize(clonevdi_path+"clonevdi.prefs") < 0
  Until vdi_source = ""

Now you know the steps, it's time to try!

  1. Launch VirtualBox.
  2. Create a VM and call it 'server1', name the virtual harddisk image 'server1.vdi'.
  3. Install Windows XP on it.
  4. Install the VirtualBox Guest Additions.
  5. Copy 'newsid.exe' to this VM.
  6. Exit VirtualBox.
  7. Run CloneVDI, clone the 'server1.vdi' file to 'server2.vdi'.
  8. Launch VirtualBox.
  9. Go to File / Virtual Media Manager and add the file 'server2.vdi'.
  10. Create a new VM, call it 'server2' and use an existing harddisk image 'server2.vdi'.
  11. Make sure the VM 'server1' isn't running.
  12. Start 'server2'.
  13. Inside the VM 'server2' launch 'newsid.exe'.
  14. Exit and restart 'server2'.
Yeah, it's a long road to salvation... When you have followed the steps above you now have a second VM with a unique .vdi file and a unique SID. It's actually amazing that you can't do that through the regular GUI... Perhaps too easy, huh? :-)

I've heard about people using imaging tools and dumping all data to an external USB harddisk, creating a new VM and .vdi and then restoring the data from the external USB to a newly created .vdi. It may be an option, but somehow it sounds awfully wrong... I've never tried it myself.

Identifying VM's

A little tip: put a file notes.txt on the desktop of your VM, create a shortcut to it and drag that shortcut into Start / Programs / Startup. That way you have a standard place to make some notes about the VM you're working with, which always pops up when you start the VM. I make some notes in the description field, but found this notes.txt approach a good way to give myself an addional heads-up... before I do yet another stupid thing :-) Another way is to create a unique desktop background of each VM.

See WallX for a little tool that will create a suitable background image to quickly identify your VM's...

And here's a running configuration, where I'm developing something in PureBasic, on my dual screen machine 'dev2' on, with a dedicated MySQL server 'mysqlserver' on running in a VM, using backgrounds generated by WallX.


Delete VM's and VDI's

As I've mentioned before, deleting a VM does not delete the corresponding .vdi file. So don't forget to delete any left-over .vdi files if you no longer need them, otherwise you're going to be out of diskspace very soon.

Resizing VDI's

You can't resize VDI's from within VirtualBox. There is a way to do it, but it's a pain... When I installed Vista 64 and upgraded it to SP1 and SP2 I ran into a problem: the virtual disk was too small.

First of all, there is no real problem :-) You could create your .vdi files using 'dynamically expanding storage', and set the size really large. As diskspace is only allocated when it actually is required, you'd only be eating up real diskspace on the host equal to the actual space the guest OS is using on its VDI.

Some people report problems with installing certain OS'es on dynamically expanding VDI's but I've never seen any problems with this approach. Thus far :-)

But if you did start out with fixed sized virtual drives you have to take a workaround. Here's how I did it:

  1. Get TrueImage Home 2010. (Older versions may work, but it looked like I needed to go up to the 2010 version to do a Vista 64 clone.) If there's other disk duplication software you prefer then use that. (A freeware suggestion is very welcome!)
  2. Create from within TrueImage an ISO rescue media and store it somewhere on the host's harddisk.
  3. Create a new VDI of the required size. Add it to your VM as the secondary harddisk.
  4. Mount the iso file containing the TrueImage rescue media as the CD in your VM.
  5. Boot your VM. Instead of booting from the guest OS on the .vdi harddisk it should now boot from the bootlable ISO image containing TrueImage.
  6. Clone your primary harddisk (your old undersized VDI) to your secondary harddisk (your new properly sized VDI).
  7. Shut down the VM. Remove the old primary drive in your VM with your new secondary drive. And voila, your guest OS now has a bigger harddisk.

So, your job for today: build one master VM, clone it a few times, resize 'm, and have the machines in the different VM's talk to each other. Then go out, buy an icecream for your girlfriend, and you two have some fun together.

12.5 Installing host and guest


You have multiple choices for host and many more for guest. Take your pick :-) I'll add some things here where I ran into problems... There are too many options, so make sure you know what you are doing. Hey, you got this far, so you should be smarter than I am :-) which is rather easy :-(...

Host - Windows XP

Sorry, only Windows XP here. With 3.0.4 there are no longer any bridge issues, so that saves a lot of configuring. If you have a DHCP server then do not specify IP adresses, as you may run into conflicts if you have too many VM's up and running. If you're new at VirtualBox, networking, or if you are intending to develop database programs or network aware applications you might go for fixed IP's.

Make sure your firewall (whatever you use) doesn't throw a spanner in the wheel...


Too many variations and possiblities to cover them all, so only a few remarks...

Guest - MSDos 5.0

Would only run if I set the IDE Controller Type to PIIX3.

Remember to use fdisk to format your virtual disk. MSDos 5.0 is not very much aware of 'newer' disk formats either :-) Some applications get confused by the speed of the virtual machine, Norton Desktop for example would only install in 'full' mode and would exit to Dos whenever I tried a custom installation. (It installed fine on a slower machine, go figure.)

Still have to figure out how to do networking and sharing. Haven't tried any mouse drivers, audio or graphical stuff yet. Feel free to send me your tips :-) Forget about integration into your host's desktop. There's not much reason, BTW, to install MSDos 5.0, the version of Dos that comes with Windows 98 should work just as well.

Guest - Windows 98

Installs and runs fine. Changes in the VM System tab would block rebooting, or even damage the image.

Direct folder sharing didn't work, but sharing through network access does.

Haven't tried any audio stuff yet. Feel free to send me your tips :-) Forget about integration into your host's desktop.

Guest - Windows XP SP3

Stil my favourite OS. Installs and runs fine.

Direct folder sharing did work 99.9% of the time, sharing through network access did a better job though. Don't forget to allow ICMP Echo in the client's firewall if you need to be able to ping the VM from the outside world...

Integrates nicely into the desktop, and does enough 3D these days to allow me to install XBMC and mess around with media servers, clients and players... Impressive!

Guest - Windows Vista 32

Works... Interestingly, my Vista 32 copy by Dell installed without a hitch inside a VM, without even asking for a license or activation... weird...

Guest - Windows Vista 64

Vista 64 works, though not lightning fast. It even runs as a (64 bit) VM on a 32 bit host (Windowx XP). Admittedly I've run into a few crashes so I would advise not to use this combination for 'production' purposes... as for testing, it works great :-)

Make the virtual disk file large enough! Vista 64 plus SP1 plus SP2 barely fits on a 20 GB, so when you create a Vista VM I suggest to set the disksize larger than suggested, for example to 40 GB. It is possible to resize a VDI but it's a pain... see here.

(Totally off-topic :-) What I noticed is that running a multi-core machine makes life a lot easier in day-to-day life... I have two DVD burners simultenaously burning a DVD, am installing Vista 64 under VirtualBox in a VM, unpacking a Windows XP Performance edition, and working on the Survival Guide... Silly? Yes. But it works :-))

12.6 Why? (Reprise)

But... why? Why go through all these troubles, and why even talk about VM's if this whole thing is about PureBasic? That's because a VM is a dandy handy tool when it comes to...