I notice there are two version of Windows Server 2008 w/ Hyper-V available for download on the MSDN Subscription License site:
Windows Server 2008 Datacenter, Enterprise and Standard (x64)
Windows Server 2008 Datacenter, Enterprise and Standard (x86)
I want to set up a development server for testing/developing using the Hyper-V software. According to the pre-requisites, you can only run Hyper-V on x64 based processor. Can a run Hyper-V on a x86 based processer? If not, why do Microsoft offer a x86 and x64 download?
This is a follow up to this question
Update:
The MSDN subscription site also offers a download for Windows Server 2008 Datacenter, Enterprise and Standard without Hyper-V (x64 and x86). Why don't they just offer one download for x86 version on Windows Server 2008, it is just confusing trying to determine the correct installion ISO....
Hyper-V only is supported for x64 CPU. In addition to it 64 bit CPU should support Intel or AMD virtualization hardware. Guest OS can be 32 or 64 bit. There is simple application SecurAble http://www.grc.com/securable.htm that you can use to test you hardware without actually installing Windows 2008/Hyper-V. In many cases you should enable hardware virtualization in BIOS.
There are several problems with Hyper-V. One of the most annoying is luck of USB support in guest OS.
Other than that it’s a very good tool.
x86 Does Not require 64-bit hardware. It exists to allow installation of Windows Server 2008 on legacy x86 hardware.
Legacy x86 hardware in my experiences has often times not had Hardware Virtualization support, and these flavors of Windows work great in this case.
You should only install the 32-bit version if you have applications that absolutely will not run in 64-bit and you cannot host those applications in a Hyper-V 32-bit guest OS or you have hardware that you must run that does not provide a 64-bit driver. For all other cases, you get substantial advantages running the 64-bit version of the os. (Both versions require 64-bit hardware, but the x86 version of the OS is still 32-bit -- like running any other 32-bit app. on a 64-bit machine, except this app. happens to be your OS).
Related
I need to set up a Virtual Machine using HyperV for programming purposes. Software like Visual Studio 2015 must run well on this VM. So, the first step is to know what Windows version I have to install on this VM.
In your opinion and experience: what version of Windows would be more optimized to run in a virtual machine: Windows 7, 8.1, 10, Server 2012?
Host PC is running on Windows 8.1 (i7, 8GB RAM, SSD&HDD).
This is not a discussion or debate. My only goal is to have a comparison, based on tangible arguments!
A simpler question is which OS provides best performance on raw hardware. There is lots of info on this. Generally that Win 8.1 is better than Win 7 and Win 10 is roughly the same as Win 8.1. Then assume the answer is the same for a Hyper-V guest. This is what I do anyway, and I run Visual Studio only in VM's.
There is a custom built software that has been developed and tested for Win XP and currently is in use on Win XP systems, there are instrumentation hardwares that interface with the software. Everything is working as designed so far.
Now there is a plan to migrate all Win XP to Win 7. In the scenerio that updates may not be available for the the software to work on Win 7, I have identified the following options
Run the software in XP mode on Win 7
Run the software from XP virtual machine on Win 7
I would like to know
If there are other options to consider
How would it affect interfacing with the instrumentation hardware?
a. Would the instrumentation hardware still be able to send the data to the software if the software is running in XP mode?
b. Would the instrumentation hardware still be able to send the data to the software if it is in a Win XP virtual machine on Win 7?
The software might or might not work under Windows 7. You should try it and see.
XP Mode (or another VM solution) works quite well to keep legacy user applications running. Basically, you are "cheating" the upgrade path by running the application under XP. However, since your application interfaces to a hardware device, you may have trouble. Your typical VM solution "hides" the underlying host PC hardware from the software.
How does the instrumentation hardware interface to the host PC? Is it a PCI/USB device with special drivers?
Some VM Solutions allow PCI or USB passthrough, which would allow your device to continue to work even through it is in a VM. However, this is still not Windows 7 upgrade. (You would probably be running an XP VM under VMware ESX.)
So what about upgrading to Windows 7 and forgetting the VM?
If you need drivers for your hardware device, your new system is Windows 7 x64, and your old system is Windows XP 32-bit, you will have a problem. A 64-bit build of Windows needs 64-bit drivers.
If your Win7 system is 32-bit, a 32-bit Windows XP driver might work. It depends on how the driver was written. You may very well run into issues, but you will not know until you try.
I use windows 7 x64 with intel cpu. which windbg works fine and should I use for debugging x86 apps ?
and another similar question, I install windows XP x86 as vmware guest for kernel debugging.My host is x64 windows 7.which windbg should I use?, windbg x86 or x64 for kernel debugging ?
I don't want to say RTFM, but in this case that's where the answer is.
This is an extract from WinDbg help:
Host computer running a 32-bit version of Windows
If your host computer is running a 32-bit version of Windows, use the 32-bit debugging tools. (This situation applies to both x86-based and x64-based targets.)
x64-based host computer running a 64-bit version of Windows
If your host computer uses an x64-based processor and is running a 64-bit version of Windows, the following rules apply:
If you are analyzing a dump file, you can use either the 32-bit debugging tools or the 64-bit debugging tools. (It is not important whether the dump file is a user-mode dump file or a kernel-mode dump file, and it is not important whether the dump file was made on an x86-based or an x64-based platform.)
If you are performing live kernel-mode debugging, you can use either the 32-bit debugging tools or the x64 debugging tools. (This situation applies to both x86-based and x64-based targets.)
If you are debugging live user-mode code that is running on the same computer as the debugger, use the 64-bit tools for debugging 64-bit code and 32-bit code running on WOW64. To set the debugger for 32-bit or 64-bit mode, use the .effmach command.
If you are debugging live 32-bit user-mode code that is running on a separate target computer, use the 32-bit debugging tools.
It is usually best to match the debugger to the architecture of the application being debugged (sometimes even required). For debugging 32-bit applications, even on a 64-bit windows OS I would suggest the x86 version of WinDbg. I would use the x64 version of WinDbg only if I wanted to debug part of the WOW64 part of the 32-bit application, which shouldn't happen often.
For any VS project it is possible to set the platform target in the build properties of that project. You can set this to Any CPU, x86, x64 or Itanium. My question is, if I set this value to x86 does that mean I cannot run that project on a x64 machine? If so, why is this even used? Is it not better to just always use Any CPU?
if I set this value to x86 does that mean I cannot run that project on a x64 machine?
No, 32-bit applications (x86) run just fine on 64-bit Windows (x64). All 64-bit versions of Windows include a 32-bit compatibility layer called Windows on Windows 64 (WOW64). This is usually what you want, in fact, as most applications do not benefit from being complied for 64-bit.
However, compiling for 64-bit (x64) does mean that your app will not run on a 32-bit (x86) machine. You can go backwards (64-bit can run 32-bit), but you cannot go forwards (32-bit cannot run 64-bit).
Compiling for Any CPU is always an option, as you point out. That will allow the application to run as a 32-bit application (x86) on a 32-bit machine, and as a 64-bit application (x64) on a 64-bit machine. This sounds like a panacea, but there are costs. Most notably, you'll need to test your application extensively in both 32-bit and 64-bit environments, whereas if you only target 32-bit environments (including 32-bit environments on a 64-bit host), you only have to test one build. And the additional workload is rarely worth it—most business applications do not benefit from the extra memory space of a 64-bit environment, and probably end up defeating any potential gains by the increased overhead of 64-bit pointers.
Visual Studio itself is a good example of an application that is fully 32-bit. There is no 64-bit version, yet it runs fine on a 64-bit host. This blog post helps to shed some light on why the decision has been made to keep VS 32-bit. You might find the reasoning helpful in making the decision yourself.
Likewise, although Microsoft Office is now available in a 64-bit package, Microsoft is still recommending that most customers stick with the 32-bit version. There are compatibility problems with the 64-bit version, and there just isn't much benefit.
If you do not specify 32 bit platform the Microsoft application compatibility toolkit cannot determine the app is 32 bit and will not allow you to create a 32 bit solution file to allow an application to run without requiring admin credentials when user account control is turned on
i have a 64-bit machine with 64-bit OS...
how can i compile programs with Visual Studio 2010 so that they work on 32-bit system
if i install 32-bit OS on my 64-bit machine than i thinks it won't be a problem
If you are talking about .NET applications simply verify that you are targeting x86 in the properties of your project (this is the default setting) or Any CPU:
This is a nice property of just-in-time compiled code. It runs just as well on a 32-bit machine (using the x86 jitter) as a 64-bit machine (x64 jitter). The only time you get in trouble is when you need to use legacy unmanaged code that's only available as 32-bit machine code. Not uncommon with old dbase providers (like Jet) and COM servers. You've got the right kind of machine to detect these problems early.
Emphasizing: you don't have a problem if the target machine is 32-bit, only if it is a 64-bit machine.