What to do when x86/ x64 have different structures and/or methods..

[WetCode]

I got a question that Google have not been able to explain for me.

What do you do when you need to determine what platform you application is running on. So you can use the correct methods from the Windows API?

For the sake of being clear on what I mean.
You have two functions in the Windows API.
Void DoSomthing() and void DoSomtingWOW64()

Or you have some structure.
struct SomeStruct; and struct SomeStructWOW64;

What is the "correct" / best method of achieving this?
I know i can use http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139%28v=vs.85%29.aspx
BOOL IsWow64Process(HANDLE hProcess, PBOOL Wow64Process); To determine if its running under WOW64 but not how I will deal with this at runtime.
Thanks for any help.

Cheers
WetCode.

[Factors]

This is going to be a bit weird but here we go.
Most programmers will have a header file specifying things for specific OS. What's in this header? Here's my example

#ifdef _WIN32//32 bit windows
#include <windows.h>
#endif
#ifdef _WIN64//64 bit windows
#include <windows.h>
#endif
#ifdef __gnu_linux__
#include <X11\X.h>//I forgot if that's the directory, it's been a while
#endif 

Basically macros are defined within your compiler to assist you in this. Get the idea?

[WetCode]

But this will define the functions at build time won`t it?
Don`t I need to check this at runtime?

If the 32 bit executable is running on a 32 bit Windows I need one set of methods/ structures.
And if its running as WOW64 on a 64 bit Windows version I need a different set of methods/ structures

EDIT: (See answered Apr 13 '12 at 8:47
rubenvb): http://stackoverflow.com/questions/10137800/problems-in-migrating-32bit-application-on-64-bit So this means by doing the above Windows will determine this at runtime for me?

Or am I not getting the idea?
Thanks for your reply btw Factors.

[Factors]

Ah you want it at run time.Ups, it is true that the macros are only good during build time. If you want run time then your only option is IsWow64Process.

Edit: Oh wait GetNativeSystemInfo is also useful.

[WetCode]

Would the correct way be something like this?

	BOOL bIsWOW;
	IsWow64Process( GetCurrentProcess(), &bIsWOW);
	if ( bIsWOW )
	{ 
		WOW64_STRUCT nameWOW64;
		SomeWOWFunction(nameWOW64)
	} else {
		W32_STRUCT name32;
		SomeFunction( name32 );
	}

This seems to me to be a uneficent way of doing things. ?

[Factors]

Yup, that's one way of doing it. I used to just use DLL's for these sort of things also.

BOOL bIsWOW;
int HLibrary;
IsWow64Process( GetCurrentProcess(), &bIsWOW);
if ( bIsWOW )
{ 
HLibrary=LoadLibrary("HelloWorld64.dll");
} else {
HLibrary=LoadLibrary("HelloWorld32.dll");
}

I believe another way of doing it is

SYSTEM_INFO System;
GetNativeSystemInfo(&System);
if(System.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_AMD64)
{
//64bit
}else if(System.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_INTEL)
{
//32bit
}

[WetCode]

I think this answers my question actually.
Thanks for your help Factors much appreciated.

Conclusion: I need to implement two execution paths for the application.
One for 32 bit and one for WOW64, and determine the platform its running on at runtime.

[andywestken]

A 32-bit DLL cannot be loaded into a 64-bit process (except as just a data file); nor can a 64-bit DLL be loaded into a 32-bit process. So deciding whether to load a 32-bit or 64-bit DLL at runtime is invalid.

IsWow64Process returns TRUE if you're running a 32-bit process on a 64-bit version of Windows, using WOW64. It's still a 32-bit process and can therefore only load 32-bit DLLs.

The decision on whether to load the 32-bit or 64-bit version of the DLL needs to be made at compile time.

Andy

[WetCode]

What I mean is that sometimes you will need to use a different function or structure.
When running a 32 bit executable under WOW64. And that's when I need to know what platform I am on.

I Found a example here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679362(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681665(v=vs.85).aspx

Hope this makes it clear andywestken, and thanks for your reply.

[andywestken]

<snip - decided my response didn't make enough sense>