build C++ COM for 64-bit platform

Hello everyone,


I am developing C++ COM native code (unmanaged C++) using Visual Studio 2005. I do not take any new features of 64-bit platform, and currently my code runs fine on 32-bit platform (e.g. Windows XP SP2).

Now I am researching how to build my code for 64-bit platform (e.g. Windows 2003 Server 64-bit R2)? Any options I need to specify in Visual Studio 2005? The best solution to me is to make a single build for both 32-bit and 64-bit platforms, is that possible?


thanks in advance,
George

You can generally use 32-bit code on Win64 pretty well, but of course there's a performance price for the marshaling to pay.

You cannot have a single executable for 32-bit and 64-bit. Windows doesn't have something like Universal Binaries.

To generate 64-bit code, all you have to do is create new configurations (copy the Debug and Release configurations to Debug64 and Release64) and change their target to the platform you want.

Look at the feature matrix: http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx
You need at least the Standard edition of 2005 to generate 64-bit code for the x86-64 (AMD Athlon64 series and later, and Intel EM64-T extensions (some P4s, Core2 and later)), and the full Team System edition to generate code for IA-64 (Intel Itanium and Itanium 2) chips.

Thanks CornedBee,

Quote:

---

Originally Posted by CornedBee

You can generally use 32-bit code on Win64 pretty well, but of course there's a performance price for the marshaling to pay.

You cannot have a single executable for 32-bit and 64-bit. Windows doesn't have something like Universal Binaries.

---

I am confused about your above two statements.

Statement 1, seems 32-bit DLL could work on 64-bit platform;

Statement 2, seems 32-bit DLL can not work for 64-bit platform since you mentioned * Windows doesn't have something like Universal Binaries*.

What is your real points? :-)


regards,
George

The answer to your first question is that unless there's a good reason to make your application 64-bit (e.g. it could benefit from LARGE data space ... more than about 4GB), then there's no reason that you should even recompile it for 64-bit.

As for binaries and compatibility: for most 64-bit platforms also supporting 32-bit [in fact, all of the ones I'm aware of], the entire executable, including DLL's, must be EITHER 32-bit or 64-bit. So any DLL that you use for 32-bit apps must be a 32-bit DLL, and any 64-bit apps must use a 64-bit DLL. Mixing and matching 32 and 64-bit executables and DLL's is not allowed. This is not very strange:
- How would you deal with a 64-bit pointer being passed from the .exe to the 32-bit DLL?
- How would you deal with a 64-bit pointer beign returned by a 64-bit DLL to a 32-bit .exe?

There are other things that complicate matters TOO, but the size of a pointer would be sufficiently complicated to solve without adding half a dozen other things to the list...

The OS supports 32-bit apps by having special modes for the memory allocation (etc) to say "make sure this pointer fits in 32-bits" and when calls are made to the OS, the pointers are extended from 32 to 64-bit format by a "shim" (that is, a small set of translation functions).

This applies to both Windows and Linux, although the exact way it's implemented may be slightly different (I haven't seen any Windows source code, so I can't say how similar or dissimilar it is).

--
Mats

From what I've heard WoW64 is perfectly capable of doing the marshaling between 32-bit DLLs and 64-bit executables, and vice versa. It's just slow.
But I haven't actually tried it, so I might be wrong.

Edit: Meh, seems I'm wrong. And there I was, thinking MS had actually made something cool.

Quote:

---

Statement 2, seems 32-bit DLL can not work for 64-bit platform since you mentioned * Windows doesn't have something like Universal Binaries*.

---

No, no. Universal Binaries are a MacOS X invention where multiple versions of a program, compiled for different environments, are stored in a single file and the loader selects the appropriate one. It's used for programs that should run on both old PowerPC and new Intel-based Mac systems, without the need for an emulator.
You can have a 32-bit version of a DLL. You can have a 64-bit version of a DLL. But you cannot have one DLL that provides both 32-bit and 64-bit versions.

Quote:

---

Originally Posted by CornedBee

From what I've heard WoW64 is perfectly capable of doing the marshaling between 32-bit DLLs and 64-bit executables, and vice versa. It's just slow.
But I haven't actually tried it, so I might be wrong.

Edit: Meh, seems I'm wrong. And there I was, thinking MS had actually made something cool.

---

I'm 99% sure that your edit is correct. There may be some of the Wow64 code to support some user-mode stuff is implemented by making a dedicated shim 32-bit to 64-bit DLL, such that:
dll32.dll:

Code:

---

foo(...)
{
  foo64(...)
}

---

But as a general rule, there are two DLL's of almost identical content, one that is 32-bit and one that is 64-bit.

[In fact, this is probably easier to produce, since (hopefully) most of the code just has to be compiled once for 32-bit and once for 64-bit, whilst if you have different source-code, then you have potential bugs in two places].

--
Mats

Thanks matsp,


Your reply is great! I want to confirm with you that,

if the application which uses my DLL is 64-bit, I need to rebuild the DLL into 64-bit, right?

I am also trying to create new configuration for 64-bit platform in Visual Studio 2005. I have tried that I could copy settings from existing configurations, so I copy 32-bit debug configuration to a new 64-bit debug configuration. Is it the correct operation?

What makes me confused is what platform should I select if I want to create a build for 64-bit platform, in my environment, the choices are,

Mixed platforms
Any CPU
x86
x64
Win32

I think I should select x64, but what is the function of Mixed platforms and Any CPU?


regards,
George

Quote:

---

Originally Posted by matsp

The answer to your first question is that unless there's a good reason to make your application 64-bit (e.g. it could benefit from LARGE data space ... more than about 4GB), then there's no reason that you should even recompile it for 64-bit.

As for binaries and compatibility: for most 64-bit platforms also supporting 32-bit [in fact, all of the ones I'm aware of], the entire executable, including DLL's, must be EITHER 32-bit or 64-bit. So any DLL that you use for 32-bit apps must be a 32-bit DLL, and any 64-bit apps must use a 64-bit DLL. Mixing and matching 32 and 64-bit executables and DLL's is not allowed. This is not very strange:
- How would you deal with a 64-bit pointer being passed from the .exe to the 32-bit DLL?
- How would you deal with a 64-bit pointer beign returned by a 64-bit DLL to a 32-bit .exe?

There are other things that complicate matters TOO, but the size of a pointer would be sufficiently complicated to solve without adding half a dozen other things to the list...

The OS supports 32-bit apps by having special modes for the memory allocation (etc) to say "make sure this pointer fits in 32-bits" and when calls are made to the OS, the pointers are extended from 32 to 64-bit format by a "shim" (that is, a small set of translation functions).

This applies to both Windows and Linux, although the exact way it's implemented may be slightly different (I haven't seen any Windows source code, so I can't say how similar or dissimilar it is).

--
Mats

---

Thanks CornedBee,


I am working on x86 platform only. I want to confirm with you that 32-bit DLL could work on 64-bit platform if the application which uses the DLL is 32-bit, right?

Do you have any official document about whether on x86 64-bit platform, 64-bit application could work with 32-bit DLL?


regards,
George

Quote:

---

Originally Posted by CornedBee

From what I've heard WoW64 is perfectly capable of doing the marshaling between 32-bit DLLs and 64-bit executables, and vice versa. It's just slow.
But I haven't actually tried it, so I might be wrong.

Edit: Meh, seems I'm wrong. And there I was, thinking MS had actually made something cool.


No, no. Universal Binaries are a MacOS X invention where multiple versions of a program, compiled for different environments, are stored in a single file and the loader selects the appropriate one. It's used for programs that should run on both old PowerPC and new Intel-based Mac systems, without the need for an emulator.
You can have a 32-bit version of a DLL. You can have a 64-bit version of a DLL. But you cannot have one DLL that provides both 32-bit and 64-bit versions.

---

Hi matsp,


I am confused. I think in your previous reply, you mean 32-bit DLL could not work with 64-bit application (process) on 64-bit platform. Right?

But in this reply, you mentioned 64-bit application could also use 32-bit DLL?

What are your real points? :-)


regards,
George

Quote:

---

Originally Posted by matsp

I'm 99% sure that your edit is correct. There may be some of the Wow64 code to support some user-mode stuff is implemented by making a dedicated shim 32-bit to 64-bit DLL, such that:
dll32.dll:

Code:

---

foo(...)
{
  foo64(...)
}

---

But as a general rule, there are two DLL's of almost identical content, one that is 32-bit and one that is 64-bit.

[In fact, this is probably easier to produce, since (hopefully) most of the code just has to be compiled once for 32-bit and once for 64-bit, whilst if you have different source-code, then you have potential bugs in two places].

--
Mats

---

No, you CAN NOT use "mixed size DLL's and executables": The executabe and all the DLL's used by it should be EITHER 64-bit or 32-bit, you can NOT mix 32-bit DLL's with 64-bit executables or 64-bit DLL's with 32-bit executables.

My post was more towards a possible implementation of 32-bit DLL's that use 64-bit DLL (which would require a bunch of trickery pokery in the linking of the two DLL's and it may not actually work in real life because it offers so little value), which, if they are designed correctly, COULD be done - but in general, it's more hard work and no real value.

--
Mats

It's what was done for the system DLLs, simply because there isn't any alternative. The kernel is 64-bit, so you need shims.

For everything else, it would be a waste of effort and performance.

Thanks Mats,

Quote:

---

Originally Posted by matsp

No, you CAN NOT use "mixed size DLL's and executables": The executabe and all the DLL's used by it should be EITHER 64-bit or 32-bit, you can NOT mix 32-bit DLL's with 64-bit executables or 64-bit DLL's with 32-bit executables.

My post was more towards a possible implementation of 32-bit DLL's that use 64-bit DLL (which would require a bunch of trickery pokery in the linking of the two DLL's and it may not actually work in real life because it offers so little value), which, if they are designed correctly, COULD be done - but in general, it's more hard work and no real value.

--
Mats

---

Your answer is clear.


regards,
George

Thanks CornedBee,

Quote:

---

Originally Posted by CornedBee

It's what was done for the system DLLs, simply because there isn't any alternative. The kernel is 64-bit, so you need shims.

---

I am confused. What do you mean is done for System DLLs? Your context please? I am confused with *it* always. :-)


regards,
George

Quote:

---

Originally Posted by George2

Thanks CornedBee,




I am confused. What do you mean is done for System DLLs? Your context please? I am confused with *it* always. :-)


regards,
George

---

System DLL's would be for example Kernel32.dll (whcih is a shim for Kernel64.dll) or ntdll.dll (which also has a 64-bit corresponding version). These HAVE to be implemented in a different way, because they essentially can only exist in a 64-bit compatible sense. All other DLL's are just "the same code compiled for either 32- or 64-bit".

No matter what DLL's you use, they still have to match the size of all other components. So all DLL's used by your application will have to be 64-bit, or they have to be 32-bit.

The only difference is that some system DLL's aren't in fact identical copies, but rather some "translation" to their 64-bit counter-parts. This applies only to SOME of the system DLL's, and many will actually just be 32-bit counterparts of the 64-bit version, calling on the 32-bit system functions in the 32-bit System DLL's (that then translates to 64-bit).

--
Mats

Thanks Mats,

Quote:

---

Originally Posted by matsp

System DLL's would be for example Kernel32.dll (whcih is a shim for Kernel64.dll) or ntdll.dll (which also has a 64-bit corresponding version). These HAVE to be implemented in a different way, because they essentially can only exist in a 64-bit compatible sense. All other DLL's are just "the same code compiled for either 32- or 64-bit".

No matter what DLL's you use, they still have to match the size of all other components. So all DLL's used by your application will have to be 64-bit, or they have to be 32-bit.

The only difference is that some system DLL's aren't in fact identical copies, but rather some "translation" to their 64-bit counter-parts. This applies only to SOME of the system DLL's, and many will actually just be 32-bit counterparts of the 64-bit version, calling on the 32-bit system functions in the 32-bit System DLL's (that then translates to 64-bit).

--
Mats

---

Your answer is clear.


regards,
George