Coffeehouse Thread

10 posts

confused by 32 bit vs 64 bit

Back to Forum: Coffeehouse
  • User profile image
    SteveRichter

    when I build a .net, c# app, is the resulting assembly 64 bit? I had always assumed it was, but never looked into it. Now that I am doing some C++ work I am finding the 32 bit vs 64 bit thing kind of confusing and time wasting.  I just assumed that a 64 bit app would be backwards compatible with 32 bit somehow. And I also assume that a 64 bit OS would run a 64 bit app better than it runs a 32 bit one. So better to build an app as 64 bit.

    The VS11 C++ project wizards start your project as 32 bit. To change to 64 bit is a little bit clumsy. And then when you run a 64 bit c++ app in debug you get a doughnut for about 6 seconds. This on a 64 bit windows 7 install. http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/31561136-89a4-41ec-ab62-4e35be42b6bc

    Now I am getting a link error with a 32bit 3rd party DLL and LIB. So I have to change my project from 64 bit to 32 bit. Which means I have to change a common code DLL I am using in all my projects from 64 to 32 bit. Not that I know what I am doing or anything, so nothing I am saying is definitive. Just pointing out that if Microsoft is touting a c++ revival, there is still work to do in making it easy for hack programmers like myself to get some work done in C++.

     

  • User profile image
    lensman

    When you compile a C#/ VB.NET application you get a .DLL/.EXE which can be either 32 bit, 64 bit, or either.

    It really boils down to where the resulting code is run.  If you specify 32 bit, you get a .DLL/.exe which can only run in 32 bit mode.  That means also if you attempt to link/call/invoke a method which is in 64 bit world you get an error.  The same is true if you do the reverse.  If you do not specify which your code can run on either assuming it does not invoke a library in a different format.

    For example if you were writing a application which needed to use crystal reports XI-R2, you cannot code a 64 bit application.  Crystal XI-R2 is pure 32 bit and knows nothing about 64 bit worlds.  In my opinion this requires you specify 32 bit as the "either" method could result in an unexpected error should your application be run on a 64 bit client.

     

    One interesting quirk:  .DLL's appear to run based upon the caller's method of use.  The same .DLL can be used by both 32 and 64 bit applications.  They will be in different application memory spaces but they will function.  I tend to code my .DLL's as "either" unless I am coding a module which must interface to a 32bit library.  This allows my "either" .DLL's to be used on 64 bit web servers or 32 bit web servers without recompilation.

     

     

     

  • User profile image
    blowdart

    So C# and VB.NET and F# all default to Any Cpu - they're neither 32 nor 64bit, the .NET framework they run under takes care of that. They can be targetted to a platform though, you generally do this when you're interacting with COM where the objects are only available on one platform.


    Visual C++ however doesn't have Any CPU, it only produces 32 or 64bit code. And yea, that's a pain, that bit me a few weeks back.

  • User profile image
    SteveRichter

    , lensman wrote

    When you compile a C#/ VB.NET application you get a .DLL/.EXE which can be either 32 bit, 64 bit, or either.

     

    That is interesting.  The 32 bit DLL that I had trouble with in C++ was useable from C# thru P/Invoke.  Another C++ annoyance is the .LIB file requirement. To link in C++ you need the .LIB file. And to run, the .DLL.  With C# P/Invoke, only the .DLL is necessary.

     

  • User profile image
    blowdart

    , SteveRichter wrote

    *snip*

    That is interesting.  The 32 bit DLL that I had trouble with in C++ was useable from C# thru P/Invoke.  Another C++ annoyance is the .LIB file requirement. To link in C++ you need the .LIB file. And to run, the .DLL.  With C# P/Invoke, only the .DLL is necessary.

    Actually you can create a LIB file using TLBImport if you don't have one, or if you can browse it to via the Add Reference / COM tab then you get it without needing the LIB, however if you want that then you need to have both the 32bit and 64bit COM objects registered, or target your app to 32 bit only (VS can't see 64bit only COM objects as it's 32bit)

    Or you can write manual imports, as you discovered.

     

  • User profile image
    Sven Groot

    @blowdart: What are you talking about? TLBImport is for COM, not P/Invoke, and it doesn't generate a LIB file.

    Also, you don't need the LIB file to use a plain DLL with exports in C++, you can use LoadLibrary/GetProcAddress, which is what C# does behind the scenes. In either case you do need to know the function signatures.

  • User profile image
    blowdart

    , Sven Groot wrote

    @blowdart: What are you talking about? TLBImport is for COM, not P/Invoke, and it doesn't generate a LIB file.

    Also, you don't need the LIB file to use a plain DLL with exports in C++, you can use LoadLibrary/GetProcAddress, which is what C# does behind the scenes. In either case you do need to know the function signatures.

    That was my point, you can use pinvoke without one, but if you try to add something that isn't viewable via Add Reference you need the lib, or a PIA.

     

  • User profile image
    Sven Groot

    @blowdart: LIBs are entirely useless for C#. You never need a lib for C#, in fact, you cannot use them. And I still don't understand what tlbimp has to do with it. Lib files and type libraries are not the same thing.

  • User profile image
    blowdart

    , Sven Groot wrote

    @blowdart: LIBs are entirely useless for C#. You never need a lib for C#, in fact, you cannot use them. And I still don't understand what tlbimp has to do with it. Lib files and type libraries are not the same thing.

    Argh, you're right, I'm getting seriously confused. I can only blame it on my current project of managed COM objects calling TLBImported COM objects, talking to a C++ DLL which uses libs.

    It makes me cry.

     

  • User profile image
    AndyC

    , SteveRichter wrote

    *snip*

    That is interesting.  The 32 bit DLL that I had trouble with in C++ was useable from C# thru P/Invoke.  Another C++ annoyance is the .LIB file requirement. To link in C++ you need the .LIB file. And to run, the .DLL.  With C# P/Invoke, only the .DLL is necessary.

    The thing you need to be careful with in that case it what CPU you're C# assembly is set to. Since your .dll is obviously 32-bit, it will appear to work fine if the C# is set to AnyCPU and you test on a 32-bit system. If you subsequently move to a 64-bit machine, it'll suddenly break. However if you explicitly set the CPU to 32-bit in the project, it'll always work (though obviously won't take full advantage of a 64-bit CPU).

    IIRC the default CPU type in Visual Studio changed around VS2010 from AnyCPU to 32-bit, precisely because people weren't realising this.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.