Slashdot Mirror
VirtualPC 2004 Versus VMWare 4.5?
BackNBlack writes "Ars Technica has an interesting comparison shootout between Microsoft's VirtualPC 2004 and VMWare Workstation 4.5. Has VirtualPC improved since Microsoft bought it from Connectix? It looks as though VMWare is really the choice of those who can afford it. I'm also a little surprised that Microsoft is not as compatible as it could be, given the competition."
I've used both and I have to say that Microsoft's Virtual PC is ASS-slow. VMWare is actually usable and has far more features and compatibility.
VMWare is superior in all regards. I've had significant problems running Linux under Virtual PC where VMWare handles it without any problems at all. Also, I've found that VMWare has drivers for most host operating systems to enable drive sharing, video, and sound. VirtualPC's guest os driver set is pretty bad. Virtual PC is a lot cheaper (free for us, as Solution Providers) but if I ever really need to get something done, VMWare is the only way to go.
Ok mine's slightly different, I've used the previous version of Virtual PC and VMware 3.1. I found Linux easier to install on Virtual PC. First of all since Virtual PC emulates a real video card (s3 Trio64 iirc) the Vesa framebuffer works. You can use the bootsplash kernel patch or just have a high resolution console. The network card was a DEC Tulip as well which is well supported. For whatever reason the fake video card in VMware always seems to have some issues working in my experience. The network card is an AMD PCnet32 card which seems equally well supported (even solaris picks it up). The feature that is in VMware that I really missed in Virtual PC was the ability to boot from real hard drives. If you dual boot windows and linux, you could boot into windows and then boot up your linux partition as well. Both offerred excelent performance provided you had enough ram. VMware 3.1 though seems to crash with 2.6 series kernels but I suspect that has been fixed in newer versions. So if I were VMware, I'd offer VESA compatable video card rather than their made up one.
The article is incorrect in stating that VirtualPC 2004 does not support using ISOs as optical drives. It certainly supports this functionality and I use it all of the time. There is a menu item called Capture ISO which lets you select an ISO and mount it like a CD-ROM or DVD-ROM drive.
I've used both products a good deal, mostly for the purpose of beta testing operating systems and development software. I've not noticed any serious speed differences. VMWare is most definitely more configurable. However I get VirtualPC 2004 for "free" with my MSDN Universal subscription so I can't really beat that.
It should also be noted that while VMWare does run on Linux, VirtualPC runs on Macintosh. It is still supported, although a hardware difference causes it to fail on G5 CPUs because these CPUs do not permit little-endian mode. A new version will be out shortly to accomodate.
Also, configuring bochs is a major pain in the ass. I have a 2.6 kernel and (I misremember some details but) I tried to use the method recommended for 2.6, had all appropriate support compiled in as far as I could tell, and it still wouldn't work, but the method recommended for 2.4 worked fine. Bochs may fit some needs, but anyone willing to look at virtual pc is surely not someone who will be using bochs.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
There are some bug reports about it on the slashcode bugtracker, report 1002074 and 1002056. It appears that it primarily affects people using Firefox and Mozilla, while Microsoft IE works fine (conspiracy?).
Both products can boot off raw hard disks. I even setup a new Gentoo system that way. VPC does however have a 137GB limit on raw disks which VMWare doesn't. Both products run quite slowly when installing an OS - they have to run in a maximum compatibility mode because of all the probing and other stuff OS installs do. Once the guest OS is installed they run faster.
Both products allow you to modify the virtual hardware (adding/removing ports, drives, images etc) after installation. Both products have undoable disks and various forms of networking (host only, share real NIC etc).
The last Connectix version of VPC had VNC access to your guests which was really neat. Microsoft removed that for VPC 2004 on "security" grounds. Technically that is true (VNC is an unecrypted protocol) but I suspect they would have removed it for marketing reasons anyway.
VPC does have a restriction that access to the host from the guest has to be done from kernel mode in the guest. That means for example that the Additions (VPC speak) / Tools (VMWare speak) have to be loaded into the OS in the guest. This prevents random user space programs in the guest from getting host access. I don't know if VMWare does something similar or not. It is however something to consider if untrusted software will be running in your guest.
The 2.6 kernel used in some distros doesn't work on VPC 2004 due to some self modifying code allegedly used in conjunction with the X server. Of course the VPC folks claim it is a Linux problem and the Linux folks say it is a VPC problem. Just remember that Linux is not a supported guest for VPC even though it usually works and MS haven't done anything (yet) to prevent it.
I have never had a response ever to a support issue raised with VMWare. I have had way more compatibility issues with VMWare. For example I have a bootcd that works on every real machine (I have tried over 10) and in VPC but fails in VMWare. With VPC I haven't had to raise support issues since it just works. There is a Microsoft newsgroup for VPC that works well.
Fundamentally both products work well. VPC is simpler and cheaper and does what it does well. VMWare is larger and more complicated and has lots more knobs for fine tuning and is also available for a Linux host.
We can thank MS for buying VPC as it resulted in VMWare dropping their price by almost 40%.
VMWare - Nonpersistent Disk Mode Changes to disks in nonpersistent mode are not saved to the disks, but are lost when the virtual machine is powered off or reset. Nonpersistent mode is convenient for people who always want to start with a virtual machine in the same state. Example uses include providing known environments for software test and technical support users as well as doing demonstrations of software.
The review's introduction says that the Mac version is an emulator but the PC version is simply a VM like VMWare.
Microsoft's VirtualPC site calls the PC version "a powerful software virtualization solution" (not that these sorts of blurbs are noted for their technical accuracy, but take it for what it's worth).
Not only that, but they can run previous versions of Windows -- or at least some of the sub-systems -- under Longhorn, thereby allowing backwards compatibility without having to design it directly into Longhorn's own APIs. (Like Apple did when they went to OS X, I believe).
Just to clarify, what Apple did was make these available:
1) A complete API set called Cocoa, derived from NeXTStep (which GNUStep is also based on)
2) Another complete API called Carbon, derived from the classic Mac OS Toolbox with some things taken out (e.g. stuff that directly touches the hardware) and some new things added in
3) CarbonLib for classic Mac OS, which is the new things added as mentioned above. Carbon applications can, in theory, run completely natively on either Mac OS X or Mac OS 9 with CarbonLib.
4) Classic is an emulation environment that runs on Mac OS X and boots Mac OS 9 inside the emulator. It's integrated into the OS so it doesn't run inside a window (except while booting), things like drag&drop between native and emulated apps works, and the Mac OS 9 Finder doesn't run. Any classic Mac OS apps that aren't Carbon-compatible, and don't try to touch the hardware too much, should work fine inside Classic, because it's really a hacked up Mac OS 9.
Owning VirtualPC would allow Microsoft to implement an emulation layer similar to Classic on Mac OS X. To make it appear seamless to the user would require quite a bit of hacking, of course.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
You need to hard-code your virtual Ethernet MAC addresses and all will be well. VMware's support pages have instructions on how to do this.