Is it possible to load a 64-bit dll into a 32-bit process ?
Generally speaking, I know it can not happen.
Yet, maybe there are some exceptions ?
No, and neither a 64-bit process can load a 32-bit DLL.
If you're on a 64 bit OS, you can load the DLL in a 64-bit process and have it communicate with your 32-bit process through IPC.
If you're on a 32 bit OS, you're out of luck.
In .NET, it is possible to load a 64-bit DLL into a 32-bit process for reflection only. For details please check "Analyze 64-bit DLL from within T4 template in Visual Studio (32-bit) using Reflection".
I know that this is a special case, but I thought I'd add it anyway because it might help others looking for a similar solution as me.
Yes, you can load 64 code in 32 bit module. example:
vmprotect
metatrader4
above software mixed x86 and x64 in one process.
I found metatrade4 for win7 has a function it exeucte a instruction like :
jmp 0x33:0x175328
segment selector 33 is a 64bit segment. after execution this instruction, cpu will switch to 64bit mode from 32bit mode.
if you use windbg to trace some windows api on windows x64 OS, you will find similar code.
for example:
NtQueryInformationProcess
But new computer bought today at least have 4G ram. We cannot prevent using 64-bit OS to avoid problem. We must face 64-bit positively! Server 2008 R2 only have 64-bit.
Issues around EXE AnyCPU / x86, 32-bit COM / C++ dll must be handled.
Ideally compile both 32 and 64 bit COM / C++ dll.
Related
I am working currently in Labview(64-bit) and want to connect a device that has a dll attached. This dll file is written in 32-bit, and now I encounter a problem with since 64-bit can't run the 32-bit.
So is there an option so I can execute the fil or any conversion of the 32-bit to 64-bit?
If you can't recompile the DLL to 64 bit or the vendor doesn't supply a 64 bit DLL there is no (easy) way.
The obvious easiest way for you would be to use Labview 32-bit.
If you know all of the entry points into the 32 bit DLL, you could create a sort of "in-process" server that is a stand-alone 32 bit app which loads the 32 bit DLL. Then you crate a 64 bit DLL that gets loaded into LabVIEW 64 which uses a method of inter-process communications to shuttle the data back and forth between the 32 bit and 64 bit processes. This is a clunky solution, but should work if all else fails.
Read the following article to learn how to create a .lib file for linking to the 32 bit DLL:
http://adrianhenke.wordpress.com/2008/12/05/create-lib-file-from-dll/
I am excited to know that what is the specific purpose to put 32 behind regsvr. why not regsvr64 ? In explain what is the significance of this 32 here ?
COM already existed back in the days of 16-bit Windows. The "32" got appended to distinguish the 32-bit version of regsvr.exe, which is only capable of registering 32-bit COM servers.
They didn't do it the same way for the 64-bit version, that was solved another way by keeping the 32-bit and 64-bit components strictly separate. Both in the registry and the file system. The 32-bit version is in c:\windows\syswow64, the 64-bit version is in c:\windows\system32.
It's just the same historical name, but you actually have two versions of regsvr32.exe on your 64-bit system:
C:\Windows\System32\regsvr32.exe - can register both 32 and 64 bit COM DLLs
C:\Windows\SysWOW64\regsvr32.exe - can only register 32 bit COM DLLs
I am working in a 64-bit Windows 7 environment and running a 32-bit version of LabVIEW.
I need to link up a specific instrument to LabVIEW, using a LabVIEW library which was given to me by the company that made the instrument. The library includes calls to a couple 32-bit DLL files which were also given to me by the company.
LabVIEW is having trouble reading those DLL files, and whenever I try to open a file I get a popup message that says "Error loading DLL". Is this because of a 32-bit/64-bit incompatibility, or is it due to something else altogether ?
Thanks,
Check the DLL in the dependency walker, there must be a DLL dependency problem.
You should be able to call at 32 bit DLL from 32 bit LabVIEW in a 64 bit OS. I believe the issue is something else.
I have a 32 bit COM component that is used mostly by ASP, we also have the 64 bit version.
The 64 bit version is functionally identical and it also uses the same ProgID (and as far as I know the same CLSID's etc).
Can I install/regsvr the 64 bit version on the same machine as the 32 bit version (obviously in a different folder) and have my existing 32 bit applications continue to use the 32 bit component, whilst my 64 bit applications consume the 64 bit version?
These are native code components written in C++ and not .NET.
This should be possible.
On 64-bit windows, the registry and file system is redirected for 32-bit applications. Registration for the 32-bit COM dll's will be under a separate location in the registry (HKLM\Software\Wow6432Node\Classes), and your COM components should live in separate folders, 64-bit under Program Files and 32-bit under Program Files (x86). The registry/file redirection for 32-bit apps should make this work transparently.
It is possible that the component itself could prevent this - for instance, if it creates global resources that would wind up conflicting between the 32-bit and 64-bit versions.
This situation already exists on 64-bit Windows. On my 64-bit system I have:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{8856F961-340A-11D0-A96B-00C04FD705A2}\InProcServer32\Default = C:\Windows\SysWow64\ieframe.dll
And
HKEY_CLASSES_ROOT\CLSID{8856F961-340A-11D0-A96B-00C04FD705A2}\InProcServer32\Default = C:\Windows\System32\ieframe.dll
32-bit and 64-bit version of WebBrowser control on the same system.
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.