Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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.</p> <p>Anyway, here are a few useful references:</p> <ul> <li>See <a href="http://msdn.microsoft.com/en-us/library/ms973190.aspx" rel="nofollow noreferrer">MSDN: Migrating 32-bit Managed Code to 64-bit</a>. Quote:</li> </ul> <blockquote> <p>"[...] Consider a .NET application that is 100% type safe code. In this scenario it is possible to take your .NET executable that you run on your 32-bit machine and move it to the 64-bit system and have it run successfully. Why does this work? Since the assembly is 100% type safe we know that there are no dependencies on native code or COM objects and that there is no 'unsafe' code which means that the application runs entirely under the control of the CLR. The CLR guarantees that while the binary code that is generated as the result of Just-in-time (JIT) compilation will be different between 32-bit and 64-bit, the code that executes will both be semantically the same. [...]"</p> </blockquote> <ul> <li><p>Also see <a href="http://blogs.msdn.com/maoni/archive/2007/05/15/64-bit-vs-32-bit.aspx" rel="nofollow noreferrer">Maoni's WebLog : 64-bit vs 32-bit</a></p></li> <li><p>Also see <a href="http://www.hanselman.com/blog/BackToBasics32bitAnd64bitConfusionAroundX86AndX64AndTheNETFrameworkAndCLR.aspx" rel="nofollow noreferrer">Scott Hanselman's Computer Zen - Back to Basics: 32-bit and 64-bit confusion around x86 and x64</a></p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload