 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / October 2007build 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 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.  SignatureGreetings 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 > Hi George! > [quoted text clipped - 26 lines] > for 64-Bit. > Simply add a new Configuration to your project. > Hello everyone, > [quoted text clipped - 12 lines] > 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. 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! SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ 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 > Hi Willy! > [quoted text clipped - 5 lines] > not work if the EXE is 64-bit. > They need to provide two separat DLLs! > Thanks Jochen, > [quoted text clipped - 4 lines] > 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. SignatureDavid Wilkinson Visual C++ MVP 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 Jochen, > > [quoted text clipped - 15 lines] > 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. 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 Jochen, > > [quoted text clipped - 15 lines] > 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. > Thanks David, > [quoted text clipped - 4 lines] > 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. 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 > > Thanks David, > > [quoted text clipped - 8 lines] > dumpbin /headers ... will show you all this and more. > Willy. > Hi Willy, > [quoted text clipped - 19 lines] > 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. 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 > > Hi Willy, > > [quoted text clipped - 29 lines] > > 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? 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 Thanks Dave, I am clear now. regards, George > >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? [quoted text clipped - 4 lines] > > Dave > Thanks Willy, > [quoted text clipped - 4 lines] > 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 [quoted text clipped - 33 lines] >> >> Willy. Thanks Ben, Good to learn from you again! regards, George > > Thanks Willy, > > [quoted text clipped - 48 lines] > >> > >> Willy. > Hi Willy! > [quoted text clipped - 7 lines] > > -- 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. 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 > > Hi Willy! > > [quoted text clipped - 12 lines] > > Willy. Thanks Willy, I want to confirm with you that I do not need a separate build for x64 platform, right? regards, George > > Hello everyone, > > [quoted text clipped - 18 lines] > > Willy. > 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. 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, > > [quoted text clipped - 6 lines] > > Willy. 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. > Hello everyone, > [quoted text clipped - 12 lines] > thanks in advance, > 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 > Starting point: > http://msdn2.microsoft.com/en-us/library/h2k70f3s(VS.80).aspx [quoted text clipped - 25 lines] > > thanks in advance, > > 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. 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. > Thanks Norman, > [quoted text clipped - 53 lines] >> > thanks in advance, >> > George Thanks Norman, I will choose x64 for my native unmanaged C++ DLL project. 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. [quoted text clipped - 70 lines] > >> > thanks in advance, > >> > George 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/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 [quoted text clipped - 25 lines] >> thanks in advance, >> 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 > Half of a correction. I wrote: > > If client code uses type IntPtr (or if you have 64-bit clients which need [quoted text clipped - 60 lines] > >> thanks in advance, > >> George Thanks Norman, What is the differences between WIN64 and _WIN64? regards, George > Starting point: > http://msdn2.microsoft.com/en-us/library/h2k70f3s(VS.80).aspx [quoted text clipped - 25 lines] > > thanks in advance, > > George In my latest experiment, in the project properties where some preprocessor identifiers are defined, MSDN says that identifier WIN32 is replaced by identifier WIN64 automatically, but Visual Studio 2005 does not do so. In my latest experiments, in the project properties for C++, I kept the setting of WIN32 and added additional definitions of both WIN64 and _WIN64. _WIN64 affects some include files so that some datatypes will be correct for 64-bit execution. I don't know if it's necessary to keep WIN32 defined and/or define WIN64 the same way, but so far they haven't caused any visible problems. In my latest experiments, in the project properties for MIDL, I didn't add definitions of WIN64 and _WIN64. As far as I can tell, this omission causes Visual Studio 2005 to display inappropriate portions of some MIDL include files, but MIDL compilation seems to be correct for 64-bit execution. As far as I can tell, this is because Visual Studio 2005 automatically added a different MIDL compilation option, which isn't documented in MSDN but which seems to work halfway. The problem with the C# client trying to retrieve IntPtr values (working in 32-bits but failing to compile in 64-bits) has remained unchanged in all of these experiments. > Thanks Norman, > [quoted text clipped - 35 lines] >> > thanks in advance, >> > George Thanks Norman, What is the differences between WIN64 and _WIN64? Any official documents? regards, George > In my latest experiment, in the project properties where some preprocessor > identifiers are defined, MSDN says that identifier WIN32 is replaced by [quoted text clipped - 58 lines] > >> > thanks in advance, > >> > George I haven't seen any documents on the intended meanings of these preprocessor symbols, only one document (already mentioned) with a false assertion that this conversion will be applied automatically. I saw some source code in Microsoft's headers which depended on _WIN64 being defined. I don't know if some other source code might depend on WIN64 being defined. In my latest experiments, I defined both, and also kept the existing definition of WIN32 (the one which a document falsely asserted would be converted), and haven't seen any ill effects from this combination of three definitions. Of course this is only for x64 builds. > Thanks Norman, > [quoted text clipped - 83 lines] >> >> > thanks in advance, >> >> > George Thanks Norman, I will follow the same way as yours. :-) regards, George > I haven't seen any documents on the intended meanings of these preprocessor > symbols, only one document (already mentioned) with a false assertion that [quoted text clipped - 94 lines] > >> >> > thanks in advance, > >> >> > George Thanks Norman, I will follow the same way as yours. :-) regards, George > I haven't seen any documents on the intended meanings of these preprocessor > symbols, only one document (already mentioned) with a false assertion that [quoted text clipped - 94 lines] > >> >> > thanks in advance, > >> >> > George
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.