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.
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 have a application which implements Geckofx web browser control. I have 64 bit compiled geckofx.dlls(compiled from a 64 bit OS). But currently i don't have access to 64 bit OS and i want to compile the whole application with the 64bit geckofx.dlls targetting 64 bit OS. How can i do that from my 32 bit OS?
I need a good tutorial to do this. Do i need to download and install 64 bit compilers in my pc? if so, how? and how to check if i already have that compilers?
I don't think I've ever done this, but can't you just set the code generation ("platform target") as x64 in the project's "Build" configuration?
Or, in the command line: csc.exe /platform:x64?
As far as I know, the C# compiler (csc) is a 32bit application, it should be able to generate code for any supported platform
I am trying to run this project in my VisualStudio 2010.
it build and run fine on my 64 bit Machine.
NOTE:I have to change build Platform of my project to x86.
my problem is when I try to run compiled assembly (after moving Debug Folder to another 64 Bit machine) I couldn't run my project. my exe breaks down when I open it.
as per my understanding problem is because of three DLL used in project are 32 BIT and Machine is 64Bit.
NOTE: below is three DLL
Interop.Office.dll
Interop.VBIDE.dll
Interop.Word.dll
I googled much but couldn't found any solution?
one solution comes in my mind is manage to get 64BIT version of above DLL for that also I have googled much but couldn't get anything.
could you please help me to find solution for this problem? or is there any way to found 64BIT version of above DLL?
If you have to use 32 bit dlls, probably you cannot run your application, compiled on 64 bits.
So you need to compile all your project (as you did for debug) in the 32 bits mode before release to another pc.
You can ensure your dlls compiled right (32 bits only), using Microsoft CorFlags.exe utility.
If you'll find that dll is not 32bits, you can also try to change it with same utility (/32BITS falg).
More information:
The default version of Office is 32 bit version.
To get 64 bit versions of the assemblies you need to specifically install 64 bit office (see here.)
The 64 bit version of Office should be able to use your 32 bit program (using WoW)
but it's best if you create (and test) two versions of it: one for 32 bit and one for 64 bit.
Unfortunately this means two development environments as the 32 bit Office cannot be installed along side the 64 bit one.
Are you positive that the office interOps are the problem?
What is the error message you are receiving? You have stated that you are compiling with x86 platform build mode. Therefore your dlls will run as 32 bit processes even on the other 64bit machine and will therefore call the 32bit office dlls.
If you had of compiled as AnyCPU then I could see how the error you are getting relates to office dll bitness, because your application would start in 64bit (on a 64bit machine) and then attempt to call into the 32bit office dlls.
But I fail to understand how you're finding that the 32bit dlls are the problem on any 32 or 64bit machine since you are compiling to 32bit (x86). So your assembly manifest is telling the JIT compiler, "hey Im a 32bit process".
Remember, ngen aside, the bitness of your code isn't determined till it's run. Post compilation the code is just IL waiting to be compiled and it's the same IL regardless of whether you had a build platform of x86 or x64 or AnyCPU.
When it's run the runtime looks at the manifest and compiles it to the platform of choice... which in this case is x86... from what you have said.
So the problem is not that:
three DLL used in project are 32 BIT and Machine is 64Bit.
32bit dlls are used all over the place on 64bit machines. Visual Studio itself is a 32bit application and runs just fine on 64bit machine. The problem (IMHO) is either
Not the office dlls at all but something else... Office is installed on the other machine I assume.
You've accidentally changed the target platform of the last build you did before deploying to something other than x86.
I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I'm expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I'm stuck with using Visual Studio's deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
it is marked as a x64 installer
it writes the entries under HKLM/Software/Blablah for the benefit of 64-bit processes
it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablah for the benefit of 32-bit processes on the same machine.
I'm guessing that because I've marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.
The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it's much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You've got to produce the 32 bit package anyway for 32 bit machines, so it's no extra work.
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.