build C++ COM for 64-bit platform

[Guest]

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

 

[Jochen Kalmbach [MVP]]

Hi George!

I am developing C++ COM native code (unmanaged C++)

Then a better newsgroup is:
microsoft.public.vc.language

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?

What kind of COM?
InProc-DLL (e.g. ActiveX-Controls)

or OutProc COM-Server (exe)?

The best solution to me is to make a single build for both 32-bit and 64-bit
platforms, is that possible?

In general: A single build is not possible.

If you buildung an OutProc-COM-Server you can simply build the 32-bit
version and use it for both platforms.

If you build dll/ocx, you need to build two versions: one for 32 and one
for 64-Bit.
Simply add a new Configuration to your project.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Guest]

Thanks Jochen,


I am building in-process DLL COM. I think you mean I do not need to change
source code, but only need to make a new configuration in project, right?

If yes, could you recommend me some learning resources about how to create
such 64-bit configuration based on my working 32-bit project please?


regards,
George

 

[Willy Denoyette [MVP]]

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

Keep your COM server DLL 32 bit, unless you really need the 64 bit address.
Your 32 bit DLL will run as expected on 64 bit windows as long as the
clients remain 32bit too.

Willy.

 

[Jochen Kalmbach [MVP]]

Hi Willy!

Keep your COM server DLL 32 bit, unless you really need the 64 bit
address. Your 32 bit DLL will run as expected on 64 bit windows as long
as the clients remain 32bit too.

I thought 64-Bit executable can not consume 32-bit DLLs... so it will
not work if the EXE is 64-bit.
They need to provide two separat DLLs!

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Norman Diamond]

Starting point:
http://msdn2.microsoft.com/en-us/library/h2k70f3s(VS.80).aspx

In my experience, additional tweaking is necessary after changing Visual
Studio 2005's settings. Some changes which were supposed to be made to
individual project configurations weren't made automatically. Also someone
has to remind both MSDN and Visual Studio managers that C++ identifiers
WIN64 and _WIN64 are not identical.

If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264. In my experience, things
still break with some clients. I'm still experimenting.

 

[Guest]

Thanks Willy,


I want to confirm with you that I do not need a separate build for x64
platform, right?


regards,
George

 

[Guest]

Thanks Jochen,


From your reply, I think we are talking about two different things. My
question is whether my x86 32bit DLL could work on 64bit platform, but you
are talking about 64-bit exe can not work on 32-bit platform.

Question again, is it workable and safe to let 32-bit DLL work on 64-bit
platform?


regards,
George

 

[Guest]

Thanks Norman,


I am 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

which one should I select?


regards,
George

 

[Norman Diamond]

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.

I did the same. In my experience, further tweaking was needed after that.

Mixed platforms
Any CPU
x86
x64
Win32

Here is my most recent set of guesses. Since my solution was already Mixed
platforms, I kept that selection the same. In the configuration settings,
the C++ project's platform said Win32, so I changed that to x64. This
choice of settings has been more successful so far than my previous guesses,
but I'm not finished yet.

 

[Norman Diamond]

If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264.

MSDN says that the MIDL and VC++ code should use INT_PTR instead of
__int3264.

In my experience, things still break with some clients. I'm still
experimenting.

In my experience, things still break with clients AND servers.

On the server side (VC++ COM DLL), MSDN says:
* To copy Win32 project settings into a 64-bit project configuration
[...]
* The following project settings are automatically updated on the project
* level:
[...]
* Values of WIN32 are replaced by WIN64 for /D (Preprocessor Definitions).
http://msdn2.microsoft.com/en-us/library/9yb4317s(VS.80).aspx

But that tells two lies. For one, that setting is not automatically
updated. You have to update it manually. And if you update it manually to
WIN64, it still breaks. You have to update it manually to _WIN64.

On the client side (C#), I get error messages like this:
Error CS1503: Parameter '6': cannot convert from 'out System.IntPtr'
to 'out long'.

I can't find any way to fix this. In x86 we get out IntPtr converted to
IntPtr just fine, and they're all 32-bits. In x64, if we change C# source
code to say long instead of IntPtr, then they'll work, they'll all be
64-bits, but they won't work in x86 any more.

 

[David Wilkinson]

Thanks Jochen,


From your reply, I think we are talking about two different things. My
question is whether my x86 32bit DLL could work on 64bit platform, but you
are talking about 64-bit exe can not work on 32-bit platform.

Question again, is it workable and safe to let 32-bit DLL work on 64-bit
platform?

George:

You seem confused.

A 64-bit OS can run both 32-bit and 64-bit executables. 32-bit
executables can only use 32-bit DLL's and 64-bit executables can only
use 64-bit DLL's.

If the executables that are going to use your DLL are 32-bit, then you
not only can, but must, use a 32-bit DLL.

 

[Willy Denoyette [MVP]]

Hi Willy!


I thought 64-Bit executable can not consume 32-bit DLLs... so it will not
work if the EXE is 64-bit.
They need to provide two separat DLLs!

--

That's why I said " as long as your client remains 32bit too. Here client is
the process that loads the COM server DLL.

Willy.

 

[Willy Denoyette [MVP]]

Thanks Willy,


I want to confirm with you that I do not need a separate build for x64
platform, right?

That's right, your 32 bit exe and 32 bit COM servers will happy to run on 64
bit Windows under Wow64. Again, there is no need to recompile 32 bit code to
64 bit if you don't need the extended address space.

Willy.

 

[Guest]

Thanks David,


I think from your reply, I should make two builds for 32-bit DLL and 64-bit
DLL since the application which uses the DLL maybe 32-bit and 64-bit.

I am wondering whether there are any tool to check whether an application
(binary code) is 32-bit or 64-bit?


regards,
George

 

[Guest]

Thanks Norman,


I will choose x64 for my native unmanaged C++ DLL project.


regards,
George

 

[Guest]

Thanks Norman,


Your experience is valuable to me. I am not using INT_PTR or __int3264. So I
think what I should do is to manually change from WIN64 to _WIN64, right?

I think if the x86 configuration could build successfully, it should be
considered almost no problem on 64-bit platform, right?


regards,
George

If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264.

MSDN says that the MIDL and VC++ code should use INT_PTR instead of
__int3264.

In my experience, things still break with some clients. I'm still
experimenting.

In my experience, things still break with clients AND servers.

On the server side (VC++ COM DLL), MSDN says:
* To copy Win32 project settings into a 64-bit project configuration
[...]
* The following project settings are automatically updated on the project
* level:
[...]
* Values of WIN32 are replaced by WIN64 for /D (Preprocessor Definitions).
http://msdn2.microsoft.com/en-us/library/9yb4317s(VS.80).aspx

But that tells two lies. For one, that setting is not automatically
updated. You have to update it manually. And if you update it manually to
WIN64, it still breaks. You have to update it manually to _WIN64.

On the client side (C#), I get error messages like this:
Error CS1503: Parameter '6': cannot convert from 'out System.IntPtr'
to 'out long'.

I can't find any way to fix this. In x86 we get out IntPtr converted to
IntPtr just fine, and they're all 32-bits. In x64, if we change C# source
code to say long instead of IntPtr, then they'll work, they'll all be
64-bits, but they won't work in x86 any more.

Starting point:
http://msdn2.microsoft.com/en-us/library/h2k70f3s(VS.80).aspx

In my experience, additional tweaking is necessary after changing Visual
Studio 2005's settings. Some changes which were supposed to be made to
individual project configurations weren't made automatically. Also
someone has to remind both MSDN and Visual Studio managers that C++
identifiers WIN64 and _WIN64 are not identical.

If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264. In my experience, things
still break with some clients. I'm still experimenting.

 

[Guest]

Thanks Norman,


What is the differences between WIN64 and _WIN64?


regards,
George

 

[Guest]

Thanks Willy,


I think I need to make a separate build since some of the applications which
will use the DLL is 64-bit and I need to have a 64-bit DLL for the
application, since 32-bit DLL is not working with 64-bit application in my
study with you guys.


regards,
George

 

[Guest]

Thanks Willy,


Now I am clear. I think the conclusion is,

A 64-bit OS can run both 32-bit and 64-bit executables;
32-bit executables can only use 32-bit DLL;
64-bit executables can only use 64-bit DLL.


regards,
George