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)
Related
I'm about to do a clean get of 32 bit source code onto my new Windows 7 64 bit machine. Is there anything special I need to do (switch to 32 bit mode, etc) or will Windows detect this and adapt accordingly?
The "bitness" of the operating system has nothing to do with getting source code. Your IDE determines what the target is of your compile of the source code, and most IDEs now can target either.
In other words, Windows doesn't have to do anything, and neither do you. Your development environment uses the source code, and determines what happens with it. Windows has absolutely nothing to do with it, except to run any resulting executable that's produced if it's compatible with that version of Windows. (And Win64 runs 32-bit applications just fine.)
Just as a note: You can't "switch to 32-bit mode" with a 64-bit operating system. It's always going to be a 64-bit operating system, even if you're running a 32-bit application. The application may not know it's running on a 64-bit OS, but it will be despite it's ignorance of that fact. :)
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.
All WoW64 apps go through WoW64 emulation layer.
I'd like to know what happen in this layer.(especially, how they can convert address space)
Please give me some important points.
Since you have already posted the diagram it is clear that you know why WOW64 exists. Now to answer your question:
I'd like to know what happen in this layer.
I think you want to know how it is implemented.
Process startup: The loader loads 64-bit user-mode part 'Ntdll.dll' as usual, but also loads 32-bit Ntdll.dll in case the process is for 32-bit execution. It is now the loaders responsibility to initialize using Wow64.dll, which sets up process and thread contexts in 32-bit Ntdll and 'switches the CPU to 32-bit mode' for execution.
System Call: Everything is now running in 32-bit mode, until a system call. We know that system calls go through Ntdll.dll, User32.dll, and Gdi32.dll etc; in this case the 32-bit versions. There is a separate 32-bit version of these libraries located in \Windows\Syswow64 bit folder. These are just stubs that instead of issuing 'native system calls,' actually call in Wow64.dll. Now, it's simple for Wow64.dll to transition to 64-bit mode, convert parameters to their 64-bit counterparts, issue the system call using 64-bit versions, get the result, and reconvert the output to 32-bit. It then transitions CPU back to 32-bit mode and returns the output.
Exception dispatching, user callbacks, file system and registry operations, and I/O is handled in the same way, using hooks somewhere down the line. Read the book prescribed below.
(especially, how they can convert address space).
64-bit address space is a superset of 32-bit address space. Plus, the same pointer (actually PTE) in 32-bit/64-bit isn't used to refer to the whole address space, but there are separate page tables for user-space and for system space.
Please give me some important points.
To know windows, the most important point I can give you is to read 'Windows Internals' -- Russinovich
MSDN says:
WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. WOW64 is provided with the operating system and does not have to be explicitly enabled.
The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. The system provides interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution.
What specifically do you not understand? Have you already read the Wikipedia article on the WoW64 subsystem? I think you'll find that it provides a fairly comprehensive overview.
And Microsoft provides some additional details here: WOW64 Implementation Details
"especially, how they can convert address space"
the key to that is knowing that amd and intel x64 processors have support for running 32bit and 64bit code side by side. this allows the os (when running native x64) to create a context for a 32bit thread that has 32bit addressing that coexists with the 64bit threads
in a similar way when the host os is running 32bit, it can create 16bit threads for running win16 and dos applications.
note, I don't think when running in the os 64bit that it can create 32bit AND 16bit threads - I guess amd decided that was just too much backwards compatability :-)
I'm developing a network redirector using RDBSS.
In our network redirector volume, a executable file which is packed from Inno Setup(Open source packer) can not be run.
When we do double-click the file in Windows Explorer, the Explorer shows this messagebox.
It works well on 32bit Windows. Only 64bit Windows is problem.
I guess it is related with npdll or MUP.
We have implemented npdll, and I thought it doesn't have any bug now. - Of course we also have npdll 64bit version.
Other executable files and any files work well for both 32 and 64OS.
If we run this file in 64bit Windows SMB volume, it runs fine.
So, I'm pretty sure some our codes have a bug.(npdll or redirector driver)
Could you guess anything about this?
P.S Is there a good document describing how MUP works? If you know, let me know please.
Thanks.
The other executables which work, are they 64-bit or 32-bit?
If only 32-bit processes (like InnoSetup) fail, could it be that you need to install both the 64- and 32-bit versions of your DLL on x64 systems? That's required for some DLL types (e.g. video codecs) if you want their functionality to be available to all programs, but I'm not familiar with RDBSS and thus don't know if it applies in this case.
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.)