- #IPHONE EMULATOR MAC OS FULL#
- #IPHONE EMULATOR MAC OS CODE#
- #IPHONE EMULATOR MAC OS PC#
- #IPHONE EMULATOR MAC OS SIMULATOR#
#IPHONE EMULATOR MAC OS PC#
Many problems people see with Windows Phone Emulator performance are due to poorly performing host PC graphics adapters or drivers. In the Windows Phone Emulator the low-level D3D graphics are "passed through" to the host PC's D3D implementation. The core OS and all graphics all the way up to the Silverlight and XNA runtimes use Direct3D. Windows Phone 7 is built from the ground up on a Direct3D stack. However, GRAPHICS performance is a whole 'nother story.
#IPHONE EMULATOR MAC OS CODE#
So code performance on a typical PC (~1.5 - 3GHz) should typically exceed what is found on an actual ARM based WP7 device. Applications written in managed (.NET) code are executed by the x86 based. The strategy of using visualization allows the OS to execute at native x86 speed. Emulating (as in CPU emulation) of an ARM processor requires a very powerful x86 processor. The typical Windows Phone 7 device will be running an ARM processor at close to 1GHz. Thus it is really neither emulation (there is no ARM to x86 emulation going on) nor pure simulation. It uses a derivative technology from Microsoft's VirtualPC/VirtualServer/Hyper-V.
The Windows Phone Emulator is actually the Windows Phone 7 operating system compiled for x86 running in a virtualized environment. Personally, even on my "bottom of the line MacMini", my build times are so small that its just not an issue to rebuild whenever I switch platform.
#IPHONE EMULATOR MAC OS SIMULATOR#
Apples simulator approach requires you to rebuild the binaries for each platform. The only advantage that this cpu-emulation approach has, to my mind, is that you can take the exact same binary and move it between device and PC and run it on both. I'm sure there are other problems in this space, its not ideal (though its pretty cool)Īnyway, unless Microsoft have a compiler-toolset that can target both the Phone CPU and the regular Windows PC CPU, they are stuck with emulation at the CPU level, rather than at the Operating System Level. There are some APIs that Apple have let bleed into the wrong SDKs, I recall there were issues with NSTask being available in the SDK even though it wasn't on the iPhone itself, for example. The problems that Rob Napier mentions are probably related to using native headers and libraries in his build (call those AppKit). There is no notion of "emulating a CPU" which is presumably what the Windows Phone 7 Emulator is doing, something similiar to the MacOS Virtual PC product of years ago (that Microsoft bought from Connectix, as I recall)
#IPHONE EMULATOR MAC OS FULL#
This means that your code runs at full "machine" speed in both environments.
You link against special libraries that are for an ARM CPU, again which implement the UIKit. When you build for the device, you are compiling for an ARM CPU. You link against special libraries that are for an x86 CPU but which implement the functions that are part of the iPhone operating system (call that UIKit) When you build for the simulator, you are compiling for an Intel x86 CPU. What you need to understand is that the iPhone Simulator is an OPERATING-SYSTEM simulator, not a DEVICE simulator. Boy, there's a lot of "emulators are this, simulators are that" in some of those answers and I feel more confused after reading them, especially when we get into suggestions that things are "re-written for that computer"
0 kommentar(er)
