Hi,

I have been mixing x64 code in x86 applications. I need to include a whole function as a x64 code instead of making x64 code inside the function. The reason for this is because I do not want to keep converting the whole assembly and architecture of one Function into x64 because I need to literally export every function and such which mean I end up writing double the code just for x64 format.

This may not seem hard, but I am working on a 100,000+ lines of code project. This means for me to port this to x64 from x86 is quite a lot of code to write. I cannot change the whole code to x64 because it is for hot-patching and injecting and so I need to make it System-Wide in all architecture(s).

The code I am using to convert from x86 to x64:



I know I am putting un-wanted data into the stack if I use this incorrectly but I can use a union with DWORD and DWORD64 in it.

Can someone explain to me how I can change the Define to allow outer usage of X64_START() rather than use it in a function space because it is too cumbersome for obvious reasons.

Don't worry of how I will export the x64 functions, I got that covered.

Thanks.

Why don't you leave the compiler take care of that?

Thanks! But if you understood my question properly, you would understand how can I convert the a whole function into x64 rather than the internal of it.

Thanks for the help though.

Maybe I didn't understand the question? I don't know o.O

You're better off asking this on an ASM specific community forum. But you need to consider larger issues you're going to have when moving a large code-base from x86 to x64. Testing is going to be the biggest issue.

I take it there's a reason you don't have a 64bit version for 64bit environments and a 32bit version for 32 bit environments?

Yes because doing so will mean I need to port and change all the inline assembly I used which is around 20,000 lines of code.

Then there is me to change some of the stack breaking and such which would normally crash a x64 OS.

All together it is too dangerous and too cumbersome as my project uses a self programmed MBR emulator only for x64 bit and there is no way I will change it because that alone is 60,000 lines of code and changing is will take so much time.

Next reason is most of the Debuggers out "there" do not have emulations to debug x86 application with x64 which would mean that debuggers will not be able to track me after I jump code segments.

@Zaita

I did ask some ASM community but they are rarely ever active and most of the members are the newbies. Therefore I also got PM suggesting to ask C++ community because of the inline asm usage.

I do consider moving such projects but as I said I cannot move the project directly to x64 because it has lot of stack breaking and such so I am simply jumping code segments from time to time.

You are right, testing is not my strong points, but I do still do it but I hate testing stages. Currently I have estimated of 400 breakpoints set around the entire project .

The reason I use VS is solely because of the debugging sophistication, all the other IDE do not have the debug tool-set like VS and I am not strong at testing therefore I need best debug set to at least do some decent levels of testing.

Thanks

Anyone have a idea for my question.

What you're trying to do is hack a port from 32bit to 64bit. Unfortunately you're trying to trivialise a problem that is not trivial. A port is a port.

@Zaita

Are you sure? If you understand Assembly and Windows API inside out you should know Within the WoW64 environment, threads that wish to switch between compatibility mode ( 32bit mode ) to 64bit mode, in order to request the invocation of kernel mode functions, have to go through the Heaven Gate located at code segment selector 0×0033 that identifies the call gate inside the GDT. The process of context switching occurs multiple times throughout the lifespan of a WoW64 process and is essential for their compatibility with the Windows 64bit kernel.

It is possible and trust me I did do this a lot of times, but not at this level and doing a full scale function conversion.

It's not a matter of whether it's technically feasible or not (even if we ignore efficiency). It's a question of using the right approach.