So, after all, can 32bit code call into 64bit code?
Q: A 32bit app, can run on a 64bit OS, so it must be able to access 64bit, right? So can a 32bit app access my 64bit library component/library/dll. Should I test this scenario?
Short answer is “most likely no”, the long answer is:
Communication between 32bit and 64bit code is a complicated matter. Consider a case where a function from 64bit foo.dll returns a 64bit pointer or a handle that is not even representable in a 32bit number. How can this be safely passed to/from 32bit code? To avoid these problems OS prevents 32bit and 64bit code from even being loaded in the same process. The only exception are the 64bit dlls that are required by WOW64 ( Wow64.dll, Wow64win.dll, 64bit version of Ntdll.dll and Wow64cpu.dll on Itanium).
COM and .Net add more layers on top of this, but the idea is the same – 32bit and 64bit user code cannot be mixed in the same app. Note that you still can communicate between 32bit and 64bit code in different processes (via various IPCs, DCOM, remoting, sockets etc).
Indeed When 32bit code makes a system call (CreateFile, VirtualAlloc etc), your call will eventually end up in 64bit code because the OS is 64bit, but before that it will be intercepted by WOW64 layer and translated into a corresponding 64bit system call. WOW64 will take care of pointer and handle translation. So if your code is a kernel driver, then yes, it could be accessed by a 32bit app indirectly (via WOW64).
When 32bit code tries to call into some arbitrary 64bit code (3rd party 64bit dll, COM32 object etc) it will not be able to do this. WOW64 cannot help here since it does not know how to deal with 3rd party components. The loader will not even load a 64bit dll in the address space of a 32bit process.