Thread: build C++ COM for 64-bit platform

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    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

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Quote Originally Posted by CornedBee View Post
    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

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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.

    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.
    Last edited by CornedBee; 10-14-2007 at 09:22 AM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by CornedBee View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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 View Post
    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

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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 View Post
    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.

  9. #9
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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 View Post
    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

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #12
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    Quote Originally Posted by matsp View Post
    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

  13. #13
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Quote Originally Posted by CornedBee View Post
    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

  14. #14
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by George2 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  15. #15
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    Quote Originally Posted by matsp View Post
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 16 bit compilar or 32 bit compilar
    By rajkumarmadhani in forum C Programming
    Replies: 16
    Last Post: 12-04-2007, 09:48 AM
  2. Bit processing in C
    By eliomancini in forum C Programming
    Replies: 8
    Last Post: 06-07-2005, 10:54 AM
  3. Porting from 32 bit machine to 64 bit machine!
    By anoopks in forum C Programming
    Replies: 10
    Last Post: 02-25-2005, 08:02 PM
  4. Question..
    By pode in forum Windows Programming
    Replies: 12
    Last Post: 12-19-2004, 07:05 PM
  5. Array of boolean
    By DMaxJ in forum C++ Programming
    Replies: 11
    Last Post: 10-25-2001, 11:45 PM