32-bit vs. 64-bit Windows
in [CSharp]
|
From: Michael Covington on 9 Dec 2009 19:22 What differences between 32-bit and 64-bit Windows should a .NET C# programmer be aware of? I understand .NET endeavors to work exactly the same way in both milieux. Does it succeed at this?
From: Peter Duniho on 9 Dec 2009 19:41 Michael Covington wrote: > What differences between 32-bit and 64-bit Windows should a .NET C# > programmer be aware of? You can allocate more memory before running out (in fact, on a 64-bit system you'll likely run out of disk space before you run out virtual address space). > I understand .NET endeavors to work exactly the same way in both > milieux. Does it succeed at this? Yes. No. It depends. If your program is entirely managed, then you should see no difference other than the ability to allocate more objects (unfortunately, 64-bit doesn't mean you can allocate _larger_ objects...just more of them). If you have to call native code, then there may be issues, as you have to match the managed code with the native code, word-size-wise (e.g. if you're calling native 32-bit code, you have to mark your managed assembly as "x86", not "Any"). Pete
From: Family Tree Mike on 9 Dec 2009 22:17 On 12/9/2009 7:41 PM, Peter Duniho wrote: > Michael Covington wrote: >> What differences between 32-bit and 64-bit Windows should a .NET C# >> programmer be aware of? > > You can allocate more memory before running out (in fact, on a 64-bit > system you'll likely run out of disk space before you run out virtual > address space). > >> I understand .NET endeavors to work exactly the same way in both >> milieux. Does it succeed at this? > > Yes. No. It depends. If your program is entirely managed, then you > should see no difference other than the ability to allocate more objects > (unfortunately, 64-bit doesn't mean you can allocate _larger_ > objects...just more of them). If you have to call native code, then > there may be issues, as you have to match the managed code with the > native code, word-size-wise (e.g. if you're calling native 32-bit code, > you have to mark your managed assembly as "x86", not "Any"). > > Pete Just a small addition to Pete's note. If your code is "called by" code that must run 32-bit, you also could have issues. We have a code that is used as a plug-in to a 32-bit app, and are thus stuck at 32-bits. -- Mike
From: Michael Ober on 9 Dec 2009 23:03 "Family Tree Mike" <FamilyTreeMike(a)ThisOldHouse.com> wrote in message news:OLefXdUeKHA.2596(a)TK2MSFTNGP04.phx.gbl... > On 12/9/2009 7:41 PM, Peter Duniho wrote: >> Michael Covington wrote: >>> What differences between 32-bit and 64-bit Windows should a .NET C# >>> programmer be aware of? >> >> You can allocate more memory before running out (in fact, on a 64-bit >> system you'll likely run out of disk space before you run out virtual >> address space). >> >>> I understand .NET endeavors to work exactly the same way in both >>> milieux. Does it succeed at this? >> >> Yes. No. It depends. If your program is entirely managed, then you >> should see no difference other than the ability to allocate more objects >> (unfortunately, 64-bit doesn't mean you can allocate _larger_ >> objects...just more of them). If you have to call native code, then >> there may be issues, as you have to match the managed code with the >> native code, word-size-wise (e.g. if you're calling native 32-bit code, >> you have to mark your managed assembly as "x86", not "Any"). >> >> Pete > > Just a small addition to Pete's note. If your code is "called by" code > that must run 32-bit, you also could have issues. We have a code that is > used as a plug-in to a 32-bit app, and are thus stuck at 32-bits. > > -- > Mike These aren't issues with dotNet itself. Rather, they are restrictions Windows puts on its WOW64 (Windows 32 on Windows 64) subsystem. Mike Ober.
From: Tim Roberts on 10 Dec 2009 01:43
"Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote: > >These aren't issues with dotNet itself. Rather, they are restrictions >Windows puts on its WOW64 (Windows 32 on Windows 64) subsystem. Well, that's a matter of semantics. It becomes a .NET issue in the sense that managed programmers are accustomed to setting "AnyCPU" as their platform, and don't think about the fact that the same binary will be a 64-bit application on 64-bit systems, and a 32-bit application on 32-bit systems. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |