Is there a way for application on Windows 64 bit to execute code both under 64 bit and 32 bit emulation layer?

Question

I am interested whether I can write an application which will be able to call some code without emulation layer and some code inside of 32 bit emulation layer.

The main reason for that is that I will need to use API SetWindowHook and I want to set hook both for 64 bit and 32 bit applications.

Sure, I can create 2 application (one for 32 bit and another for 64 bit) and launch them simultaneously. However, I will need more code to manage them (start, stop, upgrade and etc).

So, I am looking whether it's possible at all to have one application.

The only idea which I have is to have one application and 2 COM DLL's (32bit and 64bit) and use a surrogate process to run code of 32 bit. However, it will require some additional COM wrappers and so on.

Answer 1

The biggest reason for the emulation layer is that your 64-bit code is going to have a larger address space. Say, for example, you have data addressed at 0x12345678aa000000. If you pass that pointer straight to 32-bit code, it will get truncated to 32-bit address space. That is, to say, that the high-order 32 bits get removed. So the address to your data looks like 0x00000000aa000000 to your 32-bit code. This is clearly a completely different area and not what you intended.

Yes, it's possible. No you shouldn't do it unless you're extremely experience with x86 and x64 assembly, and have access to the 32-bit source code to ensure that it knows that its actually running in 64-bit space and also have access to 64-bit code to ensure that all of the data it passes to the 32-bit code is only in the 32-bit address range.

No, executing 32-bit code without the emulation layer is undesirable unless you are trying to make an UBER UGLY hack.

Answer 2

I cannot suggest a better way of doing it but what I can do is give you the source to a simple hook-based tool which does exactly the same kind of thing. Feel free to the bits that are useful to you:

http://www.pretentiousname.com/NoBarTab/NoBarTab_poc3.zip

(If this URL breaks in the future, just go up a level; it'd probably because I've finished it and put a real page up for the tool and its source.)

It's a VS2010 C++ project but should be easy to compile in older IDEs. (Writing this actually put me off using VS2010 any further for now, heh.)

Obviously, if you use it, please rename any window classes and binary names to avoid conflicts with my tool. (Anything with "NoBarTab" in the name.)

FWIW, this is a tool I started writing a few weeks ago but haven't got around to finishing. The hooking part is finished, though. It hooks window creation so that it can, for specific processes, remove tabs from the Windows 7 taskbar. (I hate the way that feature is used by VMware, in particular.) I was going to release the source code anyway when I finished it...

The 32/64-bit hooking part is all done. The only thing I haven't got around to is adding a config UI so you can specify which processes it should care about, but that's not important for what you are doing.

(I should say that the way I remove tabs from the Win7 taskbar is a complete hack and might break with future versions of Windows. There's no documented way to do that so I had to settle on a nasty kludge. The actual hooking code that you'd be interested in is all "proper", though.)

Also, I made it so that almost all of the real logic is within the main 64-bit exe. The 32-bit EXE just exists to install the 32-bit hook DLL and both the 32-bit and 64-bit hook DLLs just post a message to the main 64-bit exe's hidden window. Whether that is suitable for what you're doing I leave to you to decide, but I figure it probably fits with your desire to have everything in one place as much as possible.

Hope it's useful!

Answer 3

SetWinEventHook is a higher-level hooking API which handles the 32-bit/64-bit stuff for you. This came up in the answers to another question today and I thought it'd be worth mentioning here in case that solved your problem. Full credit to @atzz for his answer over there.

Whether or not SetWinEventHook is as suitable to you as the lower-level SetWindowsHookEx will depend on exactly what you're doing. (In my case, I could probably re-write the NoBarTab code in my other answer to use the more simple API. Haven't looked in detail yet, though.)

Answer 4

I think your only hope is to do it through something like out-of-process COM because each process has to be all 32 bit or all 64 bit.