Does a application in .NET need to be built in 64 bit to take full advantage of a machine with a 64 bit OS on it, or will it take advantage of it just as a 32 bit build. Basically, we have an issue with an out of memory exception and it was suggested to run the console app on a 64 bit box which "may" solve the issue. The question is can we just spin up a 64 box and throw the current app on it or do I need to rebuild the app in a 64 bit way.
If your app is configured to build for the "Any CPU" platform, then it'll run appropriately on either.
Just make sure it doesn't use any 32/64 bit specific stuff, or you'll run into problems.
MSDN docs here.
For some discussion on drawbacks, see here
If it's built for any platform (the default), it will run in 64 bit on 64bit operating systems.
That being said, there are still potential issues to watch for. If you interface with native code (via p/invoke, C++/CLI, or COM), then you will need to port that code to 64 bit. If the application is 100% managed, it just works.
"Any CPU" is your friend.
As an aside:
We had a particularly large Trie structure that exceeded the 2GB memory space of 32bit Windows. Because most of the structure comprised of object references, we found that the memory requirements of the app nearly doubled when moving to 64bit, requiring around 4gb. This is because the memory to store a reference is 64bits wide instead of 32.
Related
I have an application that we're trying to migrate to 64bit from 32bit. It's .NET, compiled using the x64 flags. However, we have a large number of DLLs written in FORTRAN 90 compiled for 32bit. The functions in the FORTRAN DLLs are fairly simple: you put data in, you pull data out; no state of any sort. We also don't spend a lot of time there, a total of maybe 3%, but the calculation logic it performs is invaluable.
Can I somehow call the 32bit DLLs from 64bit code? MSDN suggests that I can't, period. I've done some simple hacking and verified this. Everything throws an invalid entry point exception. The only possible solution i've found so far is to create COM+ wrappers for all of the 32bit DLL functions and invoke COM from the 64bit process. This seems like quite a headache. We can also run the process in WoW emulation, but then the memory ceiling wouldn't be increased, capping at around 1.6gb.
Is there any other way to call the 32bit DLLs from a 64bit CLR process?
You'll need to have the 32-bit dll loaded into a separate 32-bit process, and have your 64 bit process communicate with it via interprocess communication. I don't think there is any way a 32-bit dll can be loaded into a 64 bit process otherwise.
There is a pretty good article here:
Accessing 32-bit DLLs from 64-bit code
You need to write your executable processes as 32-bit processes (versus Any CPU or x64) so that they'll be loaded with WoW32 for Vista. This will load them in the 32-bit emulation mode and you won't have the entry point problem. You can leave you libraries in AnyCPU mode, but your executables have to be compiled as x86.
John's answer is correct if you don't want to recompile your existing dlls; however that might be an option for you as well.
Our team is currently migrating our x86 FORTRAN code to x64 to increase the memory ceiling.
I need to check if an executable programm compiled for 64 bit version or for 32 bit version on a Windows system.
I think this question is hard to answer, because a .NET executable in Windows contains code in two forms:
The first part is a native stub that brings in the system's available runtime (for older Windows systems, when the OS loader didn't natively recognize CLR assemblies). It can be either 32-bit or 64-bit, like other Windows applications. You can find out its target architecture by analyzing its PE header.
As you can tell, this is rather straightforward to determine. However, I suspect it may also be largely irrelevant for your use case (and for most use cases), because this first part does't contain the "useful" part of your program and is there primarily for legacy reasons.
The second part is the IL (bytecode) that will get JIT-compiled and then executed. This is the useful part, but this is largely platform agnostic when not running. It's the runtime JIT-generated code that becomes 32-bit or 64-bit.
Now, if the assembly is explicitly built using the x86 or x64 configuration, it will be marked as such and you can find out programmatically without running it whether it's going to be 32-bit or 64-bit.
However, if it's marked as AnyCPU (like most assemblies are, these days) you can't know beforehand what to expect from the JIT-compiled code. You can only really find out at runtime (by asking the environment or by comparing the size of IntPtr for example). Or you can make an educated guess - if your current program is running under 32-bit Windows (but determining this from unmanaged code may be unreliable), you definitely don't have to expect that a .NET assembly would generate 64-bit CPU instructions. However, if you're running under 64-bit Windows (again, the most likely scenario), it won't be that easy, especially considering that the semantics of the AnyCPU configuration changed with .NET 4.5 and you'll have to account for those changes as well.
Now, here's the catch that you might already have realized: The first part and the second part may not match. And they often don't, because the most common scenario is building with the AnyCPU configuration (which will typically yield a 32-bit PE executable) and deploying on 64-bit systems, where the IL will be JIT-compiled to 64-bit instructions.
In the end, you'll have to decide specifically which of the two you want to know (and whether it's worth the trouble). You may also want to explore other options, like taking advantage of the fact that AnyCPU assemblies can load as either 32-bit or 64-bit and in many cases you can use them without checking.
I have a couple of dlls that are x64, with the x86 versions not being released yet. I want to use these in a x86 environment. There is no way to change any of the platforms of those factors.
I have tried searching the Internet, but to no avail. What I want to do is somehow create a x86 library that can communicate with the x64 ones. Is this possible at all? If so, how?
Preferably, the wrapper will be in C# code, though it has to be able to access C++ dlls. (The x64 libraries are written in unmanaged C++.)
You cannot do this within a single process. That's because a 32 bit process can only load 32 bit modules, and a 64 bit process can only load 64 bit modules.
The only way for your 64 bit code to call 32 bit code, and vice versa, is to use an out-of-proc solution. For example an out-of-proc COM server.
We have a Windows Service app written in C# targeted for AnyCPU. It runs on a Win2003 (32bit) server. Recently it started to run out of memory.
What is involved in redeploying this service to a Win2003 (64bit) box. Do I need to recompile it and will the App get more memory if I do not recompile it?
Nothing special if the exe is set for AnyCPU- the 64-bit CLR will load by default on a 64-bit machine. You just have to make sure you're REALLY AnyCPU ready (no unsafe OR safe 32-bit pointer math assumptions, etc). If you're running all managed code with no PInvokes, you should be in good shape.
Is it wrong to pinvoke user32.dll on 64 bit Windows, from a 64 bit app? I've done this successfully a number of times and never had an error, but it seems contradictory. Should I look for user64.dll instead?
The name user32.dll is misleading. It's the 64 bit version of user32.dll you're calling. The 64 bit version is located at %windir%\System32\user32.dll.
A 32-bit version is included for compatibility with 32-bit applications. It's located at %windir%\SysWOW64\user32.dll. You can inspect them using the dumpbin utility:
System32\user32.dll:
FILE HEADER VALUES
8664 machine (x64)
SysWOW64\user32.dll:
FILE HEADER VALUES
14C machine (x86)
There is no user64.dll for the exact same reason you just described, .NET program can be agnostic to CPU architecture so the same code needs to work on x86 and x64.
If you take your program to x86 platform, it will still run without any modifications.
I guess that when they named user32.dll, they didn't have those scenarios in mind.