32 位或 64 位系统中的 .NET 有什么区别？
想象一个不使用 COM 组件也不使用 PInvoke 的纯 .NET 应用程序。 目标系统是 32 位还是 64 位有关系吗？
Imagine a pure .NET application which do not uses COM components nor PInvoke. Does it matters if the target system is 32 or 64 bits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果应用程序面向 AnyCPU，则运行时行为将会有所不同，特别是内存使用和限制。
在 64 位上，不会有与 32 位相同的内存限制（理论上最大内存为 2GB，但实际上为 1.2-1.6）。 然而，所有对象引用都是两倍大，因此 64 位系统将使用更多内存。
另外，64位系统通常有额外的寄存器等，因此有时性能可以略有提高。 不过，这是特定于平台的。
如果应用程序面向 x86，它将在 WoW64 下运行，并且其行为几乎与在 32 位系统中的行为相同。
If the application is targetting AnyCPU, the runtime behavior will be different, in particular, the memory usage and limitations.
On 64bit, there will not be the same 32bit memory limitations (2GB max memory theoretical, but 1.2-1.6 in practice). However, all object references are twice as large, so 64bit systems will use more memory.
Also, 64bit systems often have extra registers, etc, so sometimes performance can improve slightly. This is platform specific, though.
If the application is targetting x86, it will run under WoW64 and act nearly identically to how it will act in 32bit systems.
假设没有 COM 组件、P/Invoke 等的安全代码应该不存在语义差异，但性能可能会受到影响。 考虑：64 位下内存更多，但引用更大。 赢得一些，失去一些。
无论如何，这里有一些有用的参考：
另请参阅 Maoni 的 WebLog ： 64位 vs
32 位
另请参阅Scott Hanselman 的计算机禅 -
回到基础：32 位和 64 位
x86 和 x64 的混淆
Assuming safe code with no COM components, P/Invoke, etc. there should be no semantic difference, but performance may be impacted. Consider: More memory under 64-bit, but references are bigger. Win some, lose some.
Anyway, here are a few useful references:
Also see Maoni's WebLog : 64-bit vs
32-bit
Also see Scott Hanselman's Computer Zen -
Back to Basics: 32-bit and 64-bit
confusion around x86 and x64
除了 Reed Copsey 指出的那些之外，另一种可能很重要的方式是，您的“纯”应用程序是否碰巧使用 System.IntPtr 结构进行某些操作，或者它是否使用不安全的代码（这与 P/Invoke 不同） ) 和指针算术。
另一个需要注意的大问题是对 System.Runtime.InteropServices.Marshal 类。 那里有各种很棒的方法可以搬起石头砸自己的脚（当然，当你需要时非常有用）。
Another way it can matter, apart from those identified by Reed Copsey, is if your "pure" application happens to use the System.IntPtr struct for something, or if it uses unsafe code (which isn't the same thing as P/Invoke) and pointer arithmetic.
Another big one to look out for would be calls to pretty much anything in the System.Runtime.InteropServices.Marshal class. There are all kinds of awesome ways to shoot yourself in the foot in there (extremely useful when you need it, of course).