I just need to install Windows 2008 64Bit on a virtual machine. How to??? Do I need a special type of processor? Do I need a "special" virtualization tool? Actually installation fails on startup with the message that the CPU is not able to handle a 64Bit system.
host system: Windows 7 64Bit
CPU: Pentium D (seems to be Smithfield 805)
You need a 64-bit capable processor. VMware / Hyper-V don't emulate CPUs, they execute on them. You don't mention what hypervisor you're using.
I tried Virtual PC 2007 and VirtualBox. Installation stopped with following information:
File: \windows\system32\boot\winload.exe
Status: 0xc000035a
Info: Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode.
Related
On a remote machine, I have qemu-x86_64 installed. Upon trying to find the version of the same I'm presented with the following information.
$ qemu-x86_64 -version
qemu-x86_64 version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
I'm trying to understand what qemu-kvm is. We will not discuss whole system emulation but only qemu user level emulation.
QEMU supports 2 kinds of emulation : system and user level. In System level emulation the whole system is emulated, and you see that an OS can be booted up using the same. In User level emulation, I'm able to run binaries compiled for an architecture on another architecture. eg: I end up being able to run Linux MIPS binaries on an x86-64 machine.
The version information for qemu-x86_64 on my machine is as follows.
qemu-x86_64 version 2.2.0 (Debian 1:2.2+dfsg-5expubuntu9.2), Copyright (c) 2003-2008 Fabrice Bellard
I'm trying to understand what kind of a qemu-x86_64 is running on the remote machine. Where does kvm fit in? The remote machine is also a 64-bit machine.
When I run a 64-bit binary on the remote machine using its qemu-x86_64, there is no binary translation going on, instead qemu is using KVM to execute the instructions on actual hardware. If so, what part does qemu play? Does it handle privileged instructions? I'm trying to understand where exactly kvm comes into the picture.
In essential binary-translation allows you to run instructions of another architecture (e.g., MIPS) on your physical machine. The target architecture is simulated. For example, the registers in the simulated MIPS machine are just some variables in the QEMU process.
It is true that QEMU can use binary-translation to simulate a x86_64 machine on your computer. However because it's simulating a same architecture, the instructions can actually be directly executed by the host machine without translation! QEMU employs some techniques which use the hardware supports from CPU and OS/software supports such as KVM/Xen. It's still simulation, or you can call it virtualization.
I currently use a Windows 7 Home Basic. I need to run a certain application, which is, as of now not supported, i.e. compatible with/by W7HB. I tried downloading Virtual PC with XP mode, which does not support W7HB. Hence, I have installed Fedora as a dual boot, as there exists a separate edition of the application for Linux. As I am new to Linux CLI, I would like to install a version of XP in Fedora, i.e. via Virtual XP, assuming it supports. However, I am not able to find any suitable article for the same. Any suggestions...???
The easiest way to do this is to use VirtualBox.
There are 2 options:
run W7HB as the 'host' and install VirtualBox.Then install a guest operating system such as Fedora or WXP inside virtualbox.
OR
run Fedora as the host and install VirtualBox. Then install a guest operating system such as W7HB or WXP.
Be warned that if you install Windows in any form in a virtual machine you will need a Windows installation key. This may require a phone call to Windows support.
There are other solutions - VMWare, KVM, ... but IMHO VirtualBox is the simplest
When compiling code with VC++, MSDN gives you the option between using the x86_amd64 toolset or the amd64 toolset (when calling vcvarsall.bat).
How do I choose between those two when compile x64 code? Will the amd64 option churn out more efficient x64 machine code than the cross compiler?
It has nothing to do with efficiency. The native and cross-compiler will both generate the same machine code. You will however gain some benefits by running a native 64-bit compiler process on a 64-bit workstation (larger registers, larger memory space, etc...).
The native compiler will only run on an 64-bit copy of Windows, so if your workstation is 32-bit this compiler won't even run.
The cross-compiler is meant to run on x86 machines even though it will run on a 64-bit copy of Windows via WoW; however, there is no reason to do this.
The page you link says it quite well:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Thanks to Brian R. Bondy for the quote formatting
From what you linked:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Paraphrased:
If you use x86_amd64, then you are typically developing on an x86 machine and you want to create x64 files that run natively on x64. You could also use this option on an x64 machine but your compiler will be running under WOW64 emulation.
If you use AMD64, then you are developing on an x64 machine and you want to create x64 files that run natively on x64. The compiler is running natively in x64. This option is more efficient to build x64 programs.
You may wonder why you would ever develop an x64 program on an x86 computer, since you can't run it you can't debug it. Well it's still useful for example if you have a build server which is x86 and that build server needs to generate both x86 and x64 outputs.
How is it possible for a compiler to run under x64 if it is an x86 based program (x86_amd64)? That is the same reason you can run any x86 program on your x64 machine... Thanks to WOW64 emulation.
What is WOW64 emulation:
WOW64 emulation happens when you run an x86 program on an x64 computer (or IA64). WOW64 stands for Windows 32 on Windows 64. It is an emulation layer on top of x64 machines which allow you to execute x86 programs.
Your file system operations will be redirected to WOW64 folders and your registry will be redirected to a subnode as well. For example when you try to obtain the folder for program files it will return c:\program files (x86)\ if you are using WOW64 but it will return c:\program files\ if you are using x64.
Another example, for the registry if you try to write to HKLM\Software\Something it will really redirect you to HKLM\SOFTWARE\Wow6432Node\Something without your x86 program's knowledge.
Running a native x64 build will be more efficient than running through WOW64 emulation Why? Because you don't have that extra emulation layer of transforming your 32bit calls into 64bit ones.
By the way if you are running the x64 version of Windows you can see which processes are running through WOW64 because they will have a *32 appended to the process name in the process list.
How is Linux simultaneously 32bit and 64bit? Or is that something handled in glibc?
I run CentOS 5.3 and it is a "64 bit" version; although I build things for 64 bit and 32 bit. From what I think I know, Windows supposedly has a 32bit emulator. Does Linux do the same thing? Is it in userspace or kernel space?
If libc handles it, is it kind of like a emulator that says, I'll link with 32 bit apps, but speak 64 bit to the kernel?
The cpu can execute both 64 and 32bit instructions and the kernel can switch between modes. The only limitation is that you cannot link 32bit programs against 64bit libraries so you must have both 32 and 64bit versions of libc, etc. installed.
Nothing is stopping the cpu from switching from 64bit to 32bit. It just switches.
You can have a 64 bit kernel, and run 32bit apps. You can even have a 32bit kernel and run 64bit apps(Mac os x).
However you need the libaries they use to also be 32bit or or 64bit, which is why you might see files called lib64 or lib32 on linux for the 64bit or 32bit libaries.
Because x86_64 processors are designed over x86 technology, they are still able to support 32-bit programs without any hardware emulation, like what you would need to run x86 programs in a PowerPC or Sparc environment. In Linux, all you need to do is install the necessary software libraries to run the 32-bit software.
Host OS is x64 Win 2003.
Trying to load x64 iso (Ultrabac) and get the following:
"Attempting to load an x64 operating system, however this CPU is not compatible with x64 mode. Please install a 32-bit X86 operating system. Setup cannot continue. Press any key to exit."
So I ran Processor Check for 64-Bit Compatibility and it came up ok.
Anyone have any ideas?
You also need a BIOS that supports virtualisation extensions - checkso
a) that your BIOS has this setting
b) that it is set to ON