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! :-)
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.
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.
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:
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...)
version, seems to work well.
version, worked poorly on a new Windows 7 64 bit install. I went back to
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 :-)
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 :-)
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...
192.168.0.1 is my 'server 1'. It's a physical server with its own network card and IP address.
192.168.0.21 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 192.168.0.7x for virtual machines with fixed IP's.
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.
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.
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.
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:
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:
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.
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.
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...
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.
into the Virtual Media Manager, select an image, and do a 'copy'.
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
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.
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 192.168.0.22, with a dedicated MySQL server 'mysqlserver' on 192.168.0.71 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.
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:
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.
sure your firewall (whatever you use) doesn't throw a spanner in the wheel...
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.)
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.
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...
Guest - Windows Vista 32.
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 :-))