I have an old project which uses a 32 bit dll. This works fine on 32 bit processor, however when I install the same project on a 64 bit OS it does not work.
Is there any way to convert 32 bit dll to 64 bit? Is there an alternative solution solution to make my 32 bit dll work in a 64 bit OS?
Your 32 bit dll should work just fine on a 64 bit machine as long as it is loaded into a 32 bit process - attempting to load a 32 bit dll into a 64 bit process will fail.
If your project is a .Net (e.g. C#) application then you should be able to target your assembly at x86 in order to get your 32 bit dll working correclty:
Right click on your project in Visual Studio and select Properties
On the Build project properties tab ensure that the Platform target drop down reads "x86" instead of "Any CPU"
If you platform target is "Any CPU" then your project will normally be targeted at whatever platform is available, i.e. x64 on a 64 bit OS - this will prevent your 32 bit dll from being loaded.
If your project is not a .Net assembly then the equivalent steps needed to do the above will be different.
Alternatively you can attempt to obtain a 64 bit version of your dll - if it is a dll that you have produced then you will need to migrate it to 64 bit yourself. If not then you are dependent on the original suppliers providing a 64 bit compatible version.
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 came across a problem yesterday where my program failed as 32 bit process.
I had a dylib compiled as 64 bit and I was using it on 64 bit application. But when I turned it to 32 bit for testing and tried to load it, it did not worked. dlopen() returned NULL?
Do I need to have 32 bit and 64 bit dylib for 32 bit and 64 bit binary respectively? Is there any work around?
Yes, you need 32bit libs for 32bit processes, and 64bit libs for 64bit processes. There is no workaround.
You can build 32-bit binaries with a 64-bit compiler, and vice
versa.
You can build and run 64-bit binaries when booted on a
32-bit kernel, and vice versa.
You can't link 32-bit builds
against 64-bit binaries or vice versa.
I am working on an application which is in 32 bit. This app is working fine in 32 bit machine .
But when I install it in 64 bit machine it does not work properly. So we planned to compile it in 64 bit configuration. We could compile it and tried to run, It works properly.
But problem is; we have a 3ed party library which is in 32 bit. If I try to call that library from 64 bit, will it create problem, will it work?
I am running it in windows 7 64 bit amchine.
Please guide me to supporting my application to 64 bit.
The JET database engine will never be ported to 64-bit. You will have to consider a different engine. SQL Server Compact or Express are excellent choices.
If I develop a 64 bit webpart DLL does it work with SharePoint 2007 32 bit?
No can do. You can't load 64-bit DLL in a 32-bit process.
By default a .NET assembly will target "Any CPU" (see Build > Configuration manager in Visual Studio).
This means that the Intermediate Language (IL) code produced will be Just In Time (JIT) compiled into 32bit code when running on a 32 bit OS and 64 bit code when running on a 64 bit OS.
Unless you are doing something very funky (which is unlikely in a SharePoint web part) then you should leave it as "Any CPU" and simply not worry about it any more - it will just automagically work.
SO - Visual Studio “Any CPU” target
Visual Studio .NET Platform Target Explained
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.