build C++ COM for 64-bit platform

  • Thread starter Thread starter Guest
  • Start date Start date
G

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
 
Hi George!
I am developing C++ COM native code (unmanaged C++)
Click to expand...

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?
Click to expand...

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?
Click to expand...

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/
 
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
 
George said:
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
Click to expand...


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.
 
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.
Click to expand...

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/
 
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.
 
Thanks Willy,


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


regards,
George
 
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
 
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
 
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.
Click to expand...

I did the same. In my experience, further tweaking was needed after that.
Mixed platforms
Any CPU
x86
x64
Win32
Click to expand...

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.
 
Half said:
If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264.
Click to expand...

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.
Click to expand...

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.
 
George said:
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? :-)
Click to expand...

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.
 
Jochen Kalmbach said:
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!

--
Click to expand...

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.
 
George said:
Thanks Willy,


I want to confirm with you that I do not need a separate build for x64
platform, right?
Click to expand...
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.
 
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
 
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

Norman Diamond said:
Half said:
If client code uses type IntPtr (or if you have 64-bit clients which need
64-bit pointers) then the idl type is __int3264.
Click to expand...

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.
Click to expand...

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.


Norman Diamond said:
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.
Click to expand...
Click to expand...
 
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
 
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
 
Back
Top