Please note:
- the article does state that you need a valid XP install media - meaning, that you should have a Windows XP license with it. Say, the one that came with the computer you converted to Linux... Moreover, if you happen to install an 'update' version of Windows, you lose the right to install both the older and newer OS on the machine (check EULA) - so you'd need to spring for a 'full' version of either. Linux has no EULA (only the GPL, which essentially says 'use at will') so you can use the former OEM OS (presumably Win XP - lower-end Vista have EULA limitations) in a VM, IF KEPT ON THAT 'REAL' MACHINE.
- DirectX acceleration is available in VirtualBox (this is not the case with VirtualPC), but it is experimental. Essentially, it creates an OpenGL context on the host OS (Linux or Windows), a virtual 3D device on the guest OS, provides a DirectX to OpenGL translator and a WGL to XGL passthrough (think Wine) - giving the guest OS accelerated OpenGL and DirectX capabilities. Note that currently, the OpenGL option is considered more stable than DirectX, because like Wine's WGL to XGL passthrough driver, there's (almost) no code translation required. As far as I know, there is no passthrough option available for DirectX (thus Windows on Windows has no advantage over windows on Linux - it's even worse, due to Windows on Linux making use of Linux's much faster I/O capabilities - my test results, not mine).
- The vbox 'CPU cores' options defines how many cores are emulated on the host; as far as I know, vbox ain't multithreaded yet. Think SMP emulation for the host. You should also enable IO APIC emulation with it, and this may be unstable in WinXP.
About .tar.gz packages: they can contain both binaries and source code; thing is, in Linux, it's often more practical to ship source code and make the user compile it, but the user has to know which is what. If we take Skype's example, there are two .tar.gz available: the 'dynamic' one will make use of local libraries already installed on your machine (mainly Qt), the 'static' is a complete package that doesn't require any extra install (but is a much bigger download). On Xvid's page though, the .tar.gz package only contains source code; you have to enter the directory that contains the UNIX-like source, and do 'magic':
./configure --help ## that parses the 'configure' script and recaps default compilation and install settings. Read it thoroughly. Don't forget the './', required to run the local version; otherwise, Linux will default to 'configure' located in /usr/bin, which is NOT the same.
./configure ## that checks for dependencies on the system and prepares the build; if it can't find a compiler or any other required dependency it'll abort: install GCC and whatever library is missing (you may need the -dev or -devel package). If it can't find NASM, an assembly optimizer, it'll revert to slow 'pure C' implementation - and say so. Thus, read ./configure's output. Install optional dependencies for those features you need. You may need to pass options defined in the --help.
make ## that will actually start the compile job, according to the last ./configure run (some will actually run configure with default settings first; it is also possible that there is no ./configure script). It should take a few minutes depending on how fast your processor is.
make install ## to be run as root. Will add libraries and binaries in default paths on your system, overwriting existing files. If run as user, will probably fail. You may run into dependency hell if you overwrite existing critical files.
For actual, package-dependent instructions, read the README files that are found inside the package. Most will sum up the above, others may give different instructions.
Some packages (mainly daily builds) will actually require tools like 'automake' that parse the current source files, create a ./configure script and run it.