I ask because I noticed that many 64 bit EXEs link against what appear to be 32-bit DLLs.
For example, my 64 bit MFC app links against user32.dll, urlmon.dll, wininet.dll - all of which are 32 bit DLLs that reside in windows\system32.
So is this some MS specific wizardry that applies to these DLLs, or is there backward compatability, as it were, for 64 bit EXEs that need to use legacy 32 bit DLLs?
You cannot link 64-bit EXEs to 32-bit DLLs or vice versa. On a 64-bit Windows OS, the DLLs in Windows\System32 are actually 64-bit DLLs. The 32-bit versions are in Windows\SysWow64.
Call 32 from 64, Sure It can. (In windows this is called WOW wich means Windows on Windows). But, viceversa It doesn't work.
Here you have the explanation of how:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Hope it serves.
The latest version of Dependency Walker (found here: http://www.dependencywalker.com/) fixes this issue. It finds the correct DLLs, and avoids the inaccurate errors.
(I'm late to the party, but google still found this question when I had a similar problem.)
Related
Doing 'sizeof(char *)' from in 'C' programs shows pointers to be 4 bytes long rather than 8 bytes long in 64-bit Windows using Cygwin64's MinGW compiler. I'm specifically using the compiler 'i686-w64-mingw32-gcc.exe', which is the only MinGW compiler that I've found so far in Cygwin64. I've read about the 'WOW64' system in Windows that emulates a 32-bit environment but doubt that this is connected to the issue. Everything I've read so far states that pointers from 64-bit MinGW compilers should be 8 bytes long. So I'm confused about this and of course wondering how I might therefore be able to compile programs that use 64-bit pointers with Cygwin64's MinGW.
There is no default cross compiler, but instead there
are 2 sets for 64 and 32 bit.
mingw64-x86_64-*
mingw64-i686-*
https://cygwin.com/ml/cygwin-announce/2017-01/msg00035.html
I've decided to simply use a different MinGW compiler that I've downloaded. After I'd isolated the specific Cygwin64 download-file that provides the MinGW compiler and then unpacked and searched it for its executables, I found that it only contains the one compiler mentioned above that is a 32-bit MinGW compiler. So being that I can't yet make helpful sense out of the reference kindly provided below this by matzeri to that webpage information, I'm considering the following as my best solution so far to this problem. I've found a NON-Cygwin 64-bit MinGW compiler that's available online and have installed it to use in addition to Cygwin's various compilers whenever I need to create true 64-bit executables. I downloaded it from the website 'https://sourceforge.net/projects/mingw-w64/', and it seems to work great with it producing 64-bit pointers! (WARNING: A more heavily-referenced 64-bit MinGW compiler named "Dev-Cpp 5.11 TDM-GCC 4.9.2 Orwell+Mingw" that I looked into before this one shows as containing a Trojan-Horse virus when scanned with the antivirus App ClamWin!)
I have a 32-bit dll that I have gotten from a third party. They have no 64 bit version. I wish to load this dll into 64 bit python. To do this, I need a 64 bit dll. Is there a tool to convert a 32 bit dll to a 64 bit dll or is this impossible? If it impossible then I must use 32 bit python I guess.
Only the vendor can do this, unless you get access to the DLL's source code. It must be recompiled for 64 bit.
I guess you'll have to use 32-bit python...
32 and 64bit DLLS have different ABIs and calling conventions. You just can't load a 32bit DLL into a 64bit process or the other way around.
As mentioned in the comments, you have to recompile from source.
You can't create a 64-bit DLL from 32-bit one without the source code.
But you can create an adapter as a native 32-bit application that loads the 32-bit DLL and provides access to it's functions via some kind of inter-process communications (e.g. named pipes)
Of course, that's may be senseless in some cases and you may prefer to use 32-bit python.
So it depends.
I think under windows x64, it still uses user32.dll and a bunch of other 32 bit libraries. Why there is no user64.dll?
C:\Windows\System32\user32.dll is a 64-bit library.
The 32-bit version is in C:\Windows\SysWOW64\user32.dll.
They can't change any names because that would break all sorts of programs with hard-coded paths.
The names "user32" and "system32" and so on existed long before the modern 64-bit editions of Windows. The names were intended to distinguish them from the 16-bit versions, not from the 64-bit versions. On 64-bit Windows, it's still not 16-bit, so it's still "system32", "user32", and so on.
Nobody planned it that way, it just happened.
I have a program built with VB6 and using some 32-bit DLL's. Will this program run on a 64-bit machine? This page suggests that it should run fine on the Windows on Windows layer, but what about the DLL's?
Yes, both the VB 6 program and the DLLs will work just fine on a 64-bit version of Windows.
Since both are 32-bit, they will run under the Windows-on-Windows 64 (WoW64) subsystem, which effectively emulates a 32-bit operating system on the 64-bit versions of Windows.
I've run many such programs myself with nary a hitch.
Beyond Explorer extensions and kernel mode drivers (neither of which you've written in VB 6), any compatibility problems that you might experience are almost certainly the result of bugs in your own code, which are easily fixed upon detection. Ask more questions about that when you find them.
Are the DLLs built with VB6 as well? Or are they native?
If you are dealing with 100% VB6, then in my experience, yes they tend to run with minimal problems (I maintained a number of plug-ins for another program that were mostly implemented as VB6 COM components, around the time that Windows 7 came out).
It will all of course depend on what libraries your code is using, whether or not you are accessing locations such as %PROGRAMFILES% etc, calling code in native libraries. These things can cause small problems but it is possible to work around them.
Microsoft are still supporting the VB6 runtime on 64-bit windows
Yes, it works, and if you have any problems they will help you.
I was looking at some libraries with dumpbin and I noticed that all the 64-bit versions were linked to KERNEL32. Is there no KERNEL64 on 64-bit Windows? If not, why?
All my operating systems are 32-bit so I can't just look. A google search brings up nothing worthwhile so I suspect that there is no KERNEL64 but I'm still curious as to why this is.
EDIT: I found this later which is pretty useful. MSDN guide to x64
It's always called kernel32.dll, even on 64-bit windows. This is for the same compatibility reasons that system32 contains 64-bit binaries, while syswow64 contains 32-bit binaries.
On the 64-bit versions of Windows one of the "kernel32.dll"s contains 64-bit code but is still called kernel32.dll. This is at least misleading
Hope the following links will give the solution for this
http://www.howzatt.demon.co.uk/articles/DebuggingInWin64.html
http://www.viva64.com/en/l/0002/
http://blogs.msdn.com/b/aaron_margosis/archive/2012/12/10/using-ntfs-junctions-to-fix-application-compatibility-issues-on-64-bit-editions-of-windows.aspx
64-bit Windows provides such an environment "out of the box" and supports 32-bit applications using the 'Windows on Windows 64' subsystem, abbreviated to WOW64, which runs in user mode and maps the 32-bit calls to the operating system kernel into an equivalent 64-bit call. This is normally almost invisible to the calling program.Windows provides a set of 64-bit DLLs in %windir%\system32 and an equivalent set of 32-bit DLLs in %windir%\syswow64. In fact the bulk of the binary images in this directory are identical to the same files in the system32 directory on a 32-bit Windows installation. (It seems to me an unfortunate naming issue that the 64-bit DLLs live in system32 and the 32-bit ones live in syswow64, but there it is)