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.
Related
Can functions in a 32 bit dll be called from a 64 bit dll using the LoadLibrary function?
Technically, it happens all the time when 32-bit processes are running on a 64-bit Windows. There's 64-bit ntdll.dll, which loads Wow64 layer DLLs and 32-bit ntdll.dll.
So it is hypothetically possible. If OS does this, you also should be able to do this.
In practice this may be not feasible without OS internals knowledge. Use a 32-bit process for that 32-bit DLL, and some sort of inter-process communication.
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 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)
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.)