By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,600 Members | 1,666 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,600 IT Pros & Developers. It's quick & easy.

build C++ COM for 64-bit platform

P: n/a
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
Oct 14 '07 #1
Share this Question
Share on Google+
28 Replies


P: n/a
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/
Oct 14 '07 #2

P: n/a
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

"Jochen Kalmbach [MVP]" wrote:
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/
Oct 14 '07 #3

P: n/a
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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.
Oct 14 '07 #4

P: n/a
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/
Oct 14 '07 #5

P: n/a
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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
Oct 15 '07 #6

P: n/a
Thanks Willy,
I want to confirm with you that I do not need a separate build for x64
platform, right?
regards,
George

"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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.
Oct 15 '07 #7

P: n/a
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

"Jochen Kalmbach [MVP]" wrote:
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/
Oct 15 '07 #8

P: n/a
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" wrote:
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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

Oct 15 '07 #9

P: n/a
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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:40**********************************@microsof t.com...
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" wrote:
>Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microso ft.com...
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

Oct 15 '07 #10

P: n/a
Half of a correction. I wrote:
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.

Half of a correction. I wrote:
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/lib...7s(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" <nd******@community.nospamwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
>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
Oct 15 '07 #11

P: n/a
George wrote:
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.

--
David Wilkinson
Visual C++ MVP
Oct 15 '07 #12

P: n/a
"Jochen Kalmbach [MVP]" <no********************@holzma.dewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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!

--
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.

Oct 15 '07 #13

P: n/a
"George" <Ge****@discussions.microsoft.comwrote in message
news:D0**********************************@microsof t.com...
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.

Oct 15 '07 #14

P: n/a
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

"David Wilkinson" wrote:
George wrote:
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.

--
David Wilkinson
Visual C++ MVP
Oct 16 '07 #15

P: n/a
Thanks Norman,
I will choose x64 for my native unmanaged C++ DLL project.
regards,
George

"Norman Diamond" wrote:
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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:40**********************************@microsof t.com...
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" wrote:
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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


Oct 16 '07 #16

P: n/a
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" wrote:
Half of a correction. I wrote:
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.

Half of a correction. I wrote:
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/lib...7s(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" <nd******@community.nospamwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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

Oct 16 '07 #17

P: n/a
Thanks Norman,
What is the differences between WIN64 and _WIN64?
regards,
George

"Norman Diamond" wrote:
Starting point:
http://msdn2.microsoft.com/en-us/lib...3s(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.
"George" <Ge****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...
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

Oct 16 '07 #18

P: n/a
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

"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:D0**********************************@microsof t.com...
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.

Oct 16 '07 #19

P: n/a
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

"Willy Denoyette [MVP]" wrote:
"Jochen Kalmbach [MVP]" <no********************@holzma.dewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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!

--

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.

Oct 16 '07 #20

P: n/a
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
"David Wilkinson" wrote:
George wrote:
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.

--
David Wilkinson
Visual C++ MVP
Oct 16 '07 #21

P: n/a
"George" <Ge****@discussions.microsoft.comwrote in message
news:E6**********************************@microsof t.com...
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?
Check the dumpbin utility in VS2005 or in the Windows SDK.
dumpbin /headers ... will show you all this and more.
Willy.

Oct 16 '07 #22

P: n/a
Hi Willy,
I have tried dumpbin. Here is result,

Do you mean this line indicate it is 32-bit? I do not have a 64-bit DLL at
hand so I do not know what is the output for 64-bit DLL,

32 bit word machine

here is the total output

14C machine (x86)
3 number of sections
471755F1 time date stamp Thu Oct 18 20:47:45 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL
regards,
George

"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:E6**********************************@microsof t.com...
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?

Check the dumpbin utility in VS2005 or in the Windows SDK.
dumpbin /headers ... will show you all this and more.
Willy.

Oct 21 '07 #23

P: n/a
"George" <Ge****@discussions.microsoft.comwrote in message
news:0F**********************************@microsof t.com...
Hi Willy,
I have tried dumpbin. Here is result,

Do you mean this line indicate it is 32-bit? I do not have a 64-bit DLL at
hand so I do not know what is the output for 64-bit DLL,

32 bit word machine

here is the total output

14C machine (x86)
3 number of sections
471755F1 time date stamp Thu Oct 18 20:47:45 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL

This is a native 32bit module, as indicated by :
14C machine (x86)

A 64bit module includes this:
8664 machine (x64)

in the header.

Willy.

Oct 21 '07 #24

P: n/a
Thanks Willy,
Your reply is very helpful. I want to check that when people mentioned *x86*
it seems that it is for 32-bit only, and there is no x86-64bit, right?

And also when people mentioned *x64* it seems that it is for 64-bit only,
and there is no x64-32bit, right?
regards,
George

"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:0F**********************************@microsof t.com...
Hi Willy,
I have tried dumpbin. Here is result,

Do you mean this line indicate it is 32-bit? I do not have a 64-bit DLL at
hand so I do not know what is the output for 64-bit DLL,

32 bit word machine

here is the total output

14C machine (x86)
3 number of sections
471755F1 time date stamp Thu Oct 18 20:47:45 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL

This is a native 32bit module, as indicated by :
14C machine (x86)

A 64bit module includes this:
8664 machine (x64)

in the header.

Willy.

Oct 21 '07 #25

P: n/a
>Your reply is very helpful. I want to check that when people mentioned *x86*
>it seems that it is for 32-bit only, and there is no x86-64bit, right?
x86 usually means Intel 80x86/Pentium/etc. style 32-bit architecture.
x64 usually means the 64-bit x86 architecture - as opposed to Itanium
IA64 architecture.

Dave
Oct 21 '07 #26

P: n/a
Thanks Dave,
I am clear now.
regards,
George

"David Lowndes" wrote:
Your reply is very helpful. I want to check that when people mentioned *x86*
it seems that it is for 32-bit only, and there is no x86-64bit, right?

x86 usually means Intel 80x86/Pentium/etc. style 32-bit architecture.
x64 usually means the 64-bit x86 architecture - as opposed to Itanium
IA64 architecture.

Dave
Oct 21 '07 #27

P: n/a

"George" <Ge****@discussions.microsoft.comwrote in message
news:A4**********************************@microsof t.com...
Thanks Willy,
Your reply is very helpful. I want to check that when people mentioned
*x86*
it seems that it is for 32-bit only, and there is no x86-64bit, right?

And also when people mentioned *x64* it seems that it is for 64-bit only,
and there is no x64-32bit, right?
There are several names used interchangably (the minor differences aren't
important for user-mode Windows programs):

32-bit: x86, i386, i486, i586, i686
64-bit: AMD64, EM64T, x64, x86_64 <- this last one is potentially confusing
>

regards,
George

"Willy Denoyette [MVP]" wrote:
>"George" <Ge****@discussions.microsoft.comwrote in message
news:0F**********************************@microso ft.com...
Hi Willy,
I have tried dumpbin. Here is result,

Do you mean this line indicate it is 32-bit? I do not have a 64-bit DLL
at
hand so I do not know what is the output for 64-bit DLL,

32 bit word machine

here is the total output

14C machine (x86)
3 number of sections
471755F1 time date stamp Thu Oct 18 20:47:45 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL


This is a native 32bit module, as indicated by :
14C machine (x86)

A 64bit module includes this:
8664 machine (x64)

in the header.

Willy.


Oct 22 '07 #28

P: n/a
Thanks Ben,
Good to learn from you again!
regards,
George

"Ben Voigt [C++ MVP]" wrote:
>
"George" <Ge****@discussions.microsoft.comwrote in message
news:A4**********************************@microsof t.com...
Thanks Willy,
Your reply is very helpful. I want to check that when people mentioned
*x86*
it seems that it is for 32-bit only, and there is no x86-64bit, right?

And also when people mentioned *x64* it seems that it is for 64-bit only,
and there is no x64-32bit, right?

There are several names used interchangably (the minor differences aren't
important for user-mode Windows programs):

32-bit: x86, i386, i486, i586, i686
64-bit: AMD64, EM64T, x64, x86_64 <- this last one is potentially confusing


regards,
George

"Willy Denoyette [MVP]" wrote:
"George" <Ge****@discussions.microsoft.comwrote in message
news:0F**********************************@microsof t.com...
Hi Willy,
I have tried dumpbin. Here is result,

Do you mean this line indicate it is 32-bit? I do not have a 64-bit DLL
at
hand so I do not know what is the output for 64-bit DLL,

32 bit word machine

here is the total output

14C machine (x86)
3 number of sections
471755F1 time date stamp Thu Oct 18 20:47:45 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL



This is a native 32bit module, as indicated by :
14C machine (x86)

A 64bit module includes this:
8664 machine (x64)

in the header.

Willy.



Oct 23 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.