Menu
I recently upgraded a c# windows service to run as a 64 bit .net process. Normally, this would be trivial, but the system makes use of a 32-bit DLL written in C++. It is not an option to convert this DLL to 64 bit, so I wrapped the DLL in a separate 32 bit .net process and exposed a .net interface via remoting.
This is quite a reliable solution, but I would prefer to run the system as a single process. Is there any way I can load my 32 bit DLL into a 64 bit process and access it directly (perhaps through some sort of thunking layer)?
622
You can not run a 32-bit DLL inside a 64-bit process, no matter how hard you try, so you need to run it in a 32-bit process. If compiling your application for 32-bit only is not an option, you have no choice but to create a host application.
If the first DLL in the path is 32 bit and your app is 32 bit, then the DLL load will work. If the app is 64 bit, it will fail to load the DLL and the process will abort. If you want two DLLs to coexist on the system path, you need to give them unique file names.
Both a 32 and 64 bit OS can run on a 64 bit processor, but the 64 bit OS can use full-power of the 64bit processor (larger registers, more instructions) - in short it can do more work in same time. A 32 bit processor supports only 32 bit Windows OS. This is incorrect generally, though correct for x64 specifically.
No, you can't.
Both 16-bit and 32-bit Windows lived in a 32-bit linear address space. The terms 16 and 32 refer to the size of the offset relative to the selector.
...
First, notice that a full-sized 16-bit pointer and a 32-bit flat pointer are the same size. The value 0x0123:0x467 requires 32 bits, and wow, so too does a 32-bit pointer. This means that data structures containing pointers do not change size between their 16-bit and 32-bit counterparts. A very handy coincidence.
Neither of these two observations holds true for 32-bit to 64-bit thunking. The size of the pointer has changed, which means that converting a 32-bit structure to a 64-bit structure and vice versa changes the size of the structure. And the 64-bit address space is four billion times larger than the 32-bit address space. If there is some memory in the 64-bit address space at offset 0x000006fb`01234567, 32-bit code will be unable to access it. It's not like you can build a temporary address window, because 32-bit flat code doesn't know about these temporary address windows; they abandoned selectors, remember?
http://blogs.msdn.com/oldnewthing/archive/2008/10/20/9006720.aspx
153
If your .NET application is a website running in IIS you can circumvent it.
An ASP.NET webpage running on IIS on a 64-bit machine will be hosted by a 64-bit version of the w3wp.exe process, and if your webpage uses 32-bit dlls your site will fail.
However in IIS you can go into the Advanced Settings of the Application Pool running the site, and change "Enable 32-bit applications" to true.
So it's still not able to run 32-bit dll inside 64-bit process, but rather it is running w3wp.exe as a 32-bit process instead.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
