在开发WP8时，Win32和ARM目标平台有什么区别？(What are the differences between Win32 and ARM target platform when deve

在开发WP8时，Win32和ARM目标平台有什么区别？(What are the differences between Win32 and ARM target platform when developing for WP8?)

我知道对于WP8项目，我们必须在部署到模拟器时定位Win32，并在部署到真实设备时定位ARM。

查看VC++ Directories ，我们可以看到每个目标平台有不同的路径。 例如Library Directories

Win32的

$(WP80ToolSetPath)lib $(WindowsSDK_LibraryPath_x86)

臂

$(WP80ToolSetPath)lib\arm $(WindowsSDK_LibraryPath_ARM)

部署到真实设备非常棒，但并非每个人都有机会使用真实设备。 那么选择目标平台（Win32 vs ARM）会影响所支持的API吗？ （特别是在Windows Phone运行时组件中）

它们之间有什么不同吗？

I know that for a WP8 project, we must target Win32 when deploying to the emulator, and target ARM when deploying to the real device.

Looking into VC++ Directories, we can see that there are different paths for each target platform. For example Library Directories

Win32

$(WP80ToolSetPath)lib $(WindowsSDK_LibraryPath_x86)

ARM

$(WP80ToolSetPath)lib\arm $(WindowsSDK_LibraryPath_ARM)

Deploying to a real device is great, but not everyone has chance to work with real device. So does selecting target platform (Win32 vs ARM) affect the APIs supported? (especially in the Windows Phone Runtime Component)

Are there any differences between them ?

最满意答案

实际上，您通常可以认为ARM和Win32的API都是相同的。 即代码应该在设备和模拟器上编译，链接和运行相同的代码。

两个API之间的主要区别在于x86是仿真器，而ARM是设备，每个都具有微妙的不同特征。 然而，在考虑.NET API时，没有什么不同，比如网络。

（当然有不同的路径 - 这些是本机二进制库，因此一个目录包含x86库，另一个目录包含ARM库。库的文件名称相同，因此将它们放在其他目录中是一个明显的解决方案）

In practice you can usually consider the APIs to be the same for both ARM and Win32. I.e. the code should compile, link and run the same on both device and emulator.

The main difference between the two APIs are dictated by the fact that x86 is the emulator, and ARM is the device, each of which have subtly different characteristics. However that's no different when considering the .NET APIs, say for networking.

(Naturally there are different paths - these are native binary libraries, so one directory contains the x86 libraries, the other the ARM ones. The library's files will have identical names, so putting them in other directories is an obvious solution)