x64 code in 32 bit process

[qWord]

While googling, I found some very interesting site, which pointed out that you can call 64 bit code within a 32 Bit applications. This can be done by making a far call using a (undocumented) code selector, which is used by Windows to made transactions between 32 bit code and the  kernel.
Admittedly there is not much use of this, because all API's in the process are 32Bit, thus you can't made any API call from 64 bit code - but maybe it is useful for fooling debuggers  :bg

I find this very intersting, so I share the following example, which requires jwasm and polink. (tested on Win7, x64  :dance:)

regards, qWord

[sinsi]

Works in win8 consumer preview too.

[Ficko]

Just a question.

Did you used polink maybe for link it ?

I am getting "mix32_64.obj : fatal error LNK1190: invalid fixup found, type 0x0001".  :eek

[qWord]

Did you used polink maybe for link it ?

yes

[Ghostly]

Reminds me of something I read about Linux a while back, apparently they have created a special ABI called x32 which allows programs to use 32-bit pointers while still being able to utilize the 64-bit extended registers from standard 64bit mode. Using 64-bit address references makes the code larger and thus fills up the cpu caches faster, so by using 32-bit adress references while still using the extra registers from 64-bit mode they were apparently able to get the same code to run ~15% faster in x32 abi mode compared to pure 64bit mode. Obviously this limits each program to using a maximum of 4gb addressable ram. Likely this is mostly targeted at the embedded Linux world but I still found it interesting.

[qWord]

Reminds me of something I read about Linux a while back, apparently they have created a special ABI called x32 which allows programs to use 32-bit pointers while still being able to utilize the 64-bit extended registers from standard 64bit mode.

you can still use 32bit pointers in x64 by design: the pointers then are signed extend to 64 bits. For windows it is also no problem to address code using 32 Bit pointers, because common kernel- and user-code is placed in the range (2^31-1) to (-2^31).

[jj2007]

you can still use 32bit pointers in x64 by design: the pointers then are signed extend to 64 bits. For windows it is also no problem to address code using 32 Bit pointers, because common kernel- and user-code is placed in the range (2^31-1) to (-2^31).

Hey, you are calling Raymond Chen a liar :bg

[sinsi]

jj, "mov rax,[esi]" is still valid in long mode.

[jj2007]

Sinsi,

I haven't yet started with 64-bit, not only because my OS is 32-bit, but one thing is for sure: What Raymond Chen writes will not contradict M$'s decision to drop support for older code, be it 16 or 32bit :bg

[sinsi]

I think Mr Chen is talking about two way communication, 32 to 64 is easy but the opposite is hard.

[qWord]

M$'s decision to drop support for older code, be it 16 or 32bit :bg

that's not their decision, because they follow the hadware requirements. Allowing 32 bit code to be execute in a 64 bit environment without any adaption would mean to kick the advantage of the larger address space.
You can use 32 Bit code as long as it's pointers only points inside your module (e.g. .data,.data?,...). For dynamic allocation and most API code an adaption to x64 is required...