用Vista 64编写的代码是否兼容32位操作系统？

Question

我们正在使用新的开发机器并升级到Vista 64 Ultimate以利用我们的8gb内存。我们的经理希望我们在32位虚拟机中完成所有开发工作，以确保我们的代码不会出现问题。

有没有办法保证结果程序能在32位操作系统上运行？ 我不介意使用虚拟机，但我不喜欢他们如何强迫你回到“单一”监视器类型视图。我喜欢将我的VS工具栏移到我的另一台显示器上。

编辑：我们正在使用Visual Studio 2005和2008，VB.NET和/或C＃

编辑：使用Harpreet的answer，这些是我用来设置Visual Studio IDE以编译x86 / 32bit的步骤：

1. 单击“生成”并打开“配置管理器”
2. 选择Active Solution Platform下拉列表
3. 选择x86（如果它在列表中）并跳至步骤5，如果不是，请选择<New...＆gt;
4. 在New Solution Platform对话框中，选择x86并按OK
5. 验证所有项目的选定平台是否为x86
6. 点击关闭。

享受。

谢谢你， 基思

Answer 1

我在32位Windows的64位计算机上进行开发。这不是一个问题。您应确保将项目设置为在x86模式下编译以保守。您需要浏览解决方案中的每个项目并仔细检查。您也可以使用AnyCPU设置，但风险稍大，因为它在开发机器上的运行方式与32位机器不同。当然，你想避免使用64位模式。

我遇到的问题是当应用程序编译为64位（显式64位或AnyCPU在64位Windows上编译并运行）时不起作用的驱动程序。坚持使用x86编译可以完全避免这些问题。这应该揭示你的开发机器上的所有缺陷。

理想情况下，您可以设置可在32位计算机上频繁执行的构建和测试环境。这应该让您的管理层放心，让您避免将VM作为桌面。

Answer 2

只要将可执行文件编译为32位，它们就可以在32位和64位Windows机器上运行（保证）。使用64开发机器的优势在于，您可以使用64位编译开始测试代码（检查类似于32位整数的指针），这样可以在将来更轻松地转换到64位（如果您的公司选择做64位版本。）

Answer 3

编译64位操作系统是编译器中的一个选项。您绝对可以从Vista 64位内编译为32位exe。当您运行该应用程序时，您可以在TaskManager中看到该进程旁边有一个“* 32”...这意味着它是32位;）

我相信你的经理需要更多关于64位操作系统真正意义的教育：）

Answer 4

不是你的问题的答案，但可能是你的问题的解决方案：VirtualBox（可能还有其他人）支持“无缝集成”模式，它只是为你提供了第二个开始栏，让你可以自由地拖动窗口。

此外，这是您的问题的答案，这取决于您的编译设置。您可以针对不同的环境进行编译，并且可以使用Visual Studio在64位系统上完美地编译32位程序。无法告诉你如何，但我确信一些Visual Studio大师可以帮助你。

Answer 5

我们使用VS 2005（即将于2008年）开发了一个32位应用程序，刚刚购买了一些带有XP Pro x64或Vista Business 64位的新机器，这样我们就可以利用额外的RAM同时观看如果在商业上有必要这样做，可以简要介绍一下64位端口的可能性。除了在我们的开发环境中调整一些脚本等之外，我们没有遇到任何问题。

那些未包含在此升级周期中的开发人员仍然使用32位计算机，因此在单元测试和应用程序测试套件在办理登机手续之前运行时，这些应该会出现问题。< / p>

我们还要做的是确保我们拥有一套“测试构建”机器，这些机器由“典型”配置（XP / Vista，2/4/8内核等）组成，可构建和测试签到 - 我们有各种不同的稳定性，性能等测试套件 - 在它们被正确添加到集成区域之前。同样，这些在运行基于64位操作系统的32位应用程序时没有遇到任何问题。

无论如何，正如其他人已经说过的那样，我不认为这是一个问题，因为编译器会为目标操作系统生成适当的代码，而不管编译器实际运行的操作系统是什么。

Answer 6

是的，就像亚当说的那样。有3个选项：MSIL（默认），x64和x86。您可以定位x64并且它将专门为64位系统生成dll，或者您可以执行将在32位和64位上运行的x86，但在64位系统上具有与32位相同的限制。

MSIL基本上会让JITer发出特定于平台的指令（与原生图像相比会略微降低性能）

编辑：没有语言，所以我说的是.net框架语言，如vb.net和c＃，c ++是一个完全不同的动物。

Answer 7

今天发现：

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

  

x64使用.NET进行开发

     

今年早些时候，我转而使用64位操作系统 - 确切地说是Vista Ultimate x64。在大多数情况下，这个过程一直相对轻松，但是在此过程中出现了一些小问题（x64兼容驱动程序，主要是，但这不是讨论的重点）。

     

在x64开发的世界中，我认为我会在这里概述一些难点。这个清单可能会增长，所以期待未来有关此事的帖子。

     

在.NET开发的精彩世界中，可以编译应用程序和程序集以针对各种平台。默认情况下，应用程序和程序集在Visual Studio中编译为Any CPU。在这种情况下，CLR将加载程序集，无论其正在执行的计算机的默认目标是什么。例如，在x64计算机上运行可执行文件时，它将作为64位进程运行。

     

Visual Studio还提供3个特定的平台目标：x86，x64和Itanium（IA-64）。将可执行文件构建为特定目标时，它将作为该类型的进程加载。例如，在x64计算机上运行的以x86为目标的可执行文件将使用32位CLR和WOW64层作为32位进程运行。在运行时加载程序集时，如果它们的目标与宿主进程的目标匹配，则它们只能由进程加载，或者它被编译为任何CPU。例如，如果将x64设置为程序集的目标，则只能通过x64进程加载。

     

这在我的几个场景中已经发挥作用：

     

  

• XNA - XNA仅作为一组32位程序集提供。因此，在引用XNA程序集时，使用它们的可执行文件/程序集必须以x86平台为目标。如果它的目标是x64（或任何CPU并在64位计算机上运行），则在尝试加载XNA程序集时将引发错误。

  

• Microsoft Robotics Studio - XInputGamepadService在内部使用XNA与Xbox 360控制器通信。见上文。

  

• 托管DirectX - 虽然这已被弃用并被XNA取代，但它仍有其用途。程序集没有标记为特定目标，但是我在内存异常方面遇到了困难，特别是对于Microsoft.DirectX.AudioVideoPlayback程序集。

  

• Phidg​​ets - 根据您下载的库和时间，它可能会也可能不会被标记为32位。当前版本（11/8/07）被标记为这样，因此需要32位进程来托管它。   确定可执行文件或程序集是否针对特定平台的最简单方法是使用corflags应用程序。要使用此功能，请从“开始”菜单中打开Visual Studio命令提示符，然后针对要检查的程序集运行它。

  

     

确定可执行文件或程序集是否针对特定平台的最简单方法是使用corflags应用程序。要使用此功能，请从“开始”菜单中打开Visual Studio命令提示符，然后针对要检查的程序集运行它。