mixing 32 and 64 bit code

[nullptr]

hi folks,

i want to make a program for windows which is in the first part for 32 bit CPU and if after check it appears it is a 64 bit CPU i want to execute second 64 bit part. otherwise program will skip the rest. does it is possible to mix 32 and 64 bit code in one program and how to assemble and link such program?

thanks for any help

[Frank Kotler]

I don't really know the answer to this, but I think it'll be a problem. It seems to me that the executable header is going to be for 32-bit or 64-bit... not both.

I have seen a "trick" employed (Herbert Kleebauer) in which we start off as a plain .com file - no executable header at all. One of the functions of this .com file is to write a new disk file with a Windows (PE) executable header on it... and execute it (delete the file afterwards to preserve the illusion of "magic", if you like). A similar trick with a 32-bit file writing and executing a 64-bit file might work. Doesn't seem practical.

The normal "dos stub" in a PE file just says "This program requires Windows" and quits. More functionality can be incorporated into the "dos stub" if you like, producing a file that will run in either OS. I doubt if a PE for a modern OS even has a "dos stub", since dos is no longer supported.

Maybe someone has a better answer to this, but I think if you can do "the necessary" in 32-bit code it would be simpler to leave it as 32-bit code Further discussion welcome - it's an interesting question.

Best,
Frank

[nullptr]

it looks like too much combinations. mess up with headers is rather not for me.

[Sergvov]

I think that's possible , but you will work hard to manage it .

[nullptr]

but you will work hard to manage it .

yes, but the effort is not worth it. its a small project. so I'll have to find a simpler solution, or to give.

[dogman]

This is a sore spot with me about Intel among many others. But I did hear of some technology or plan to allow this to be supported. Does anybody know what it's called or what the status of it is?

[Rob Neff]

Were you thinking of this: http://noggin.intel.com/content/the-x32-abi-a-new-software-convention-for-performance-on-intel%C2%AE-64-processors

[dogman]

Yes, thanks! That's the one. Cannot find a Linux distro that has it although the home page you linked in the other post suggests the system level pieces are being worked on (kernel, gdb etc.)

[iVision]

Its possible sort of, the technique is also known as Heavens Gate. You do a far call to segment 33h, and know you are executing x64 code in a x86 application, a far return and you are back to the x86 space.
Source: http://www.corsix.org/content/dll-injection-and-wow64

Due to their nature, operating systems need to be tailored to the architecture which they run on. Due to x64's backward compatibility, you can run x86 Windows on an x64 chip, and things will behave exactly the same as if you were running on an x86 chip. The more interesting situation is running x64 Windows on an x64 chip, but then running x86 applications within the x64 operating system. This brings us to WoW64 - the component of x64 Windows which allows x86 applications to run, as although the x64 chip can run the x86 code, there is more that has to be done to allow applications to run properly. WoW64 handles the transitioning between running x64 code and running x86 code, and presents a 32-bit view of the world to the x86 process. Due to how x64 is an extension of x86, transitioning from 32-bit code to 64-bit code isn't that conceptually difficult - the attributes of a code segment tell the processor whether to treat the code as x86 code or x64 code, the 32-bit registers are in fact 64-bit registers with the top half ignored, and the 4GB of addressable RAM in 32-bit mode is the same as the bottom 4GB in 64-bit mode. Hence to jump (or technically call) from x86 code to x64 call, all that you need to do is a far (inter-segment) call to an x64 segment, and then do a far return when you're done. The tricky part is finding an x64 code segment, as WoW64 makes everything look 32-bit, and messing with segment descriptors requires the use of undocumented Windows API calls (though this doesn't stop Google's Native Client, NaCl, from calling said APIs). Clearly the WoW64 DLLs must have some way of finding an x64 code segment in order to transition to 64-bit mode, so someone disassembled these DLLs, found how it was code, and called the mechanism "Heaven's Gate". Heaven's Gate is very simple: segment 33h. Do a far call to segment 33h, and suddenly you're executing x64 code within an x86 process. For a far return, and you're back to x86 code which you left. With this portion of WoW64 dealt with, we can return to its other main purpose: making the 64-bit world look and behave like a 32-bit world. WoW64 does some clever things with the registry and the filesystem, but these are not relevant to this discussion (though developers might find it useful to read how to launch the x86 registry editor under Windows x64).

[dogman]

Thank you, that is a very interesting link. I don't know enough to understand whether it's OS specific but I think it is. I would also expect you can't do any sys or libc calls in the wrong mode, on any x86 OS. Some OS have kernels that support x86 and x86_64 but on the ones that support only one or the other I would expect things would go bad very fast when syscalled in the wrong mode if you could even switch to it in the first place- I would expect there would be protection against doing that also, but who knows.

[iVision]

Thank you, that is a very interesting link. I don't know enough to understand whether it's OS specific but I think it is. I would also expect you can't do any sys or libc calls in the wrong mode, on any x86 OS. Some OS have kernels that support x86 and x86_64 but on the ones that support only one or the other I would expect things would go bad very fast when syscalled in the wrong mode if you could even switch to it in the first place- I would expect there would be protection against doing that also, but who knows.

Well that article is about Windows DLL Injection. (I didn't even know it was able on linux too to run x84 code in 64bit OS.) Anyway I guess you should just try it?
Let me know if it works!

Regards

[dogman]

The limitations are well known. Not to me, to people who work on this stuff You cannot mix 32 and 64 bit code in any existing UNIX OS or Linux distro.  Part of the problem is because of the elf format. Some of it is because of the kernel designs. Some of it is because of Intel's limitations. Rob points out there is work being done on this. It has to be solved in hardware and software. And it is going to require a lot of work to get it right. I will be surprised if it's ever actually 100% supported.

[iVision]

Hmm not to me either haha, also I don't think it needs to be solved in hardware but in the drivers? I mean my Windows 8 laptop can perfectly run Ubuntu, and in Windows I can mix 32 and 64bit code (using the heaven's gate, cool name) so my hardware doesn't stop me from running 32 and 64 bit code. (Well at least I think, or is the 32 bit translated to 64 bit then??)

[dogman]

No the problem is not running 32 bit code or 64 bit code on Intel. The problem is running 32 bit code and 64 bit code in the same program on Intel or linking programs in 32 bit and 64 bit mode together. AFAIK this is not possible because of hardware and software issues on that platform and the commonly-implemented OS that run on it.

For a specific example, you can't link a 64 bit shared library with a 32 bit program nor can you link a 32 bit shared library with a 64 bit program on Intel *NIX. This is software problem and I think it's also a hardware problem. You can also not change from 32 bit mode to 64 bit mode or from 64 bit mode to 32 bit mode without using the info from the webpage you mentioned And even if you do use that technique I expect there are many scenarios in UNIX where that will fail for example changing from 64 bit to 32 bit code under a 64-bit only kernel.

[nullptr]

thanks for replies and links. dont know i'll manage to do something with it but it's interesting anyway.