Try looking at the Wine or Cedega games lists. Also, you could try VMWare...

Looks like Cedega does support it, but it might not run well. Hmm... and I can't find the games lists for Wine. Best bet would be to try the free things first (Wine then VMWare) and if those don't work try Cedega.

I did look at their site, but I'm reluctant to draw too many conclusions from a sample size of 2. 1 guy with a soundcard problem setup could throw the rating... and I normally turn sounds off. It does look like they update their product fairly frequently, so the situation could improve with time. I just wondered if any regular players here had tried it.

I don't think that we would make GalCiv3 Vista only.  Most of our users now have Windows XP, so we'd be cutting out a huge part of the market. 

The activation might throw things because it checks to see what version of windows you are running, among other things.  So if the emulation software returned all the correct values, you'd be ok.  You might be able to do the activation itself over e-mail and then you would only have to worry about the emulation software running the check to see if the product is activated correctly.

That and maybe the metaverse submission code might be the only things that might have a lot of windows specific code in them, although not being really familiar with the metaverse submission code, I don't know how platform specific it is.

Genuine support for Windows-based cryptographic security mechanisms in WINE is a pipe dream. As these routines are often implemented either in the kernel, or hardware (TPM), or both, future incarnations of these technologies will be exponentially harder to correctly "mimic". The reason is that it's no longer a matter of WINE providing correct APIs for the routines; WINE is unable to access the cryptographic vault which eventually contains the private key that must be used to unlock or enable the desired functionality. The routine for this access is either embedded in proprietary hardware, or implemented in the Windows kernel -- both of these areas being extremely difficult to inspect. Short of officially-licensed algorithms/technologies, such as TransGaming Cedega's license of MS DirectX, the only way to time-effectively achieve API compatibility with these mechanisms would be to have inside employees break their NDAs to disclose data on them, which puts them at significant personal risk.

VMware, on the other hand, *is* an emulator, and an extraordinary one at that. To my knowledge, their present technology does not enable 3d rendering of any sort from within the guest OS. However, in the past, they have successfully written a 2d-accelerated SVGA driver set called "VMware Tools", which installs itself in the guest OS and provides a low-level link to the underlying SVGA hardware on the host OS. They've been able to overcome pretty steep obstacles before, and I have a feeling they're actively developing 3d rendering support. As for the crypto stuff, that's no problem on VMware -- aside from a few little-known "red pill" hacks, it's impossible for the guest OS to even know it's running in an emulator. VMware considers the red-pills to be bugs, since they don't represent equivalent functionality on real hardware, and will most likely correct them when possible.

Vista and its sins, hardware-based encryption (DRM) and treacherous computing, will ultimately mean the death knell of Linux interoperability with Windows software. The only software that will be able to avoid this is software which chooses not to use the Vista APIs that play to their secure audio/video paths; i.e., legacy Windows NT/2000/XP software.