none
How can I cross a 32/64 bit boundary within an application? RRS feed

  • Question

  • Hi,

    I developed an application for a customer, which consists of a .NET 4 / WPF module which calls an unmanaged C++ DLL (developed by the customer).  Within my module I have a 3rd-party component, which is a 32-bit WinForms UserControl, which I am hosting inside a WindowsFormsHost element.

     

    The problem is: The customer wants to migrate to x64 with his DLL, and the 3d-party component (a media player) is available only in x86. So I need to find a way to have the x64 DLL, the x86 component and my managed application module (which can be either x86 or x64 - it doesn't matter) calling the first and hosting the later.

     

    My question is, what is the *best* way to do it (if it's possible at all).

    I understand that it might be possible by running the unmanaged DLL functions from a separate process, but I'm afraid the cost of the extra mechanism of moving data (images etc.) between the two processes would be to high. Any suggestions will be most welcome.

     

    Thanks,

      Ury

    Thursday, May 19, 2011 11:14 AM

Answers

  • Ury,

    32Bit and 64Bit means that the different architectures, different CPU instruction set. I don't think that it is possible to start one process which can use 32Bit and 64Bit components at the same time.

    Your best bet is that you use IPC(interprocess communication), but it depends on what functionality the special components in your scenario.

    You can host that unmanaged DLL in a 64Bit .NET application, then use .NET IPC mechanisms for Interprocess communication. If you need to share the big amount of data between two processes, you can have a look at shared memory to see whether it can satisfy your requirement.

     

    Rgs,

    Riquel


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 3:40 PM
  • For the record:  Yes, you need two executables:  A 64-bit one that will load the unmanaged DLL that will become 64-bit as well, and your .Net executable in 32-bit mode to load the media player available only as 32-bit.

    Is the unmanaged DLL a COM DLL?  If yes, you could have the DLL loaded by a COM out-of-process server.  I think it is called dllhost.exe.  Google the name for info on it.  I would imagine that you will have to include a LocalServer32 key that points to dllhost.exe + any command line necessary to load the object?  Or maybe no command line is necessary.  Check it out.  Remember, though:  Your customer will also need to compile a proxy/stub dll in 32-bit mode.

    As for your 32-bit .Net application, I'm not sure how you request the 64-bit version to be activated.  In C++ I would have used CoCreateInstance() and I would have specified the CLSCTX_ACTIVATE_64_BIT_SERVER flag.  See http://msdn.microsoft.com/en-us/library/ms693716(VS.85).aspx and http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx.

    If the unmanaged DLL is not a COM DLL, then you'll have to develop the 64-bit host yourself and then set up some form of IPC.  I personally like pipes.


    MCP
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 5:56 PM
  • You can't have both architectures in one process. If yoy're using COM, the standard mechanism is to have the COM Dll hosted by DllHost, because the RPC between 32-bit and 64-bit doesn't care about bitness.

    I can't speak for the debugging issue. That may be a "does Visual Studio debug across architecture boundaries" question. Visual Studio 2010 is a 32-bit app and I don't know if it an debug in 64-bit mode.  I know dev organisations where people just do all this in 32-bit anyway - the functionality doesn't change just because the code is running 32-bit or 64-bit. 


    Phil Wilson
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 6:01 PM
  • Hi Phil

    Although VS can debug 64bit application, I would like to guess that VS uses IPC to start the 64Bit components as the background process to inject DLL to debug 64bit application. Then use IPC to control that background process and get the debug information in VS. I don't do VS dev, so I guess this. 

    Rgs,

    Riquel


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Marked as answer by ury Friday, May 20, 2011 6:52 AM
    Friday, May 20, 2011 2:35 AM

All replies

  • Ury,

    32Bit and 64Bit means that the different architectures, different CPU instruction set. I don't think that it is possible to start one process which can use 32Bit and 64Bit components at the same time.

    Your best bet is that you use IPC(interprocess communication), but it depends on what functionality the special components in your scenario.

    You can host that unmanaged DLL in a 64Bit .NET application, then use .NET IPC mechanisms for Interprocess communication. If you need to share the big amount of data between two processes, you can have a look at shared memory to see whether it can satisfy your requirement.

     

    Rgs,

    Riquel


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 3:40 PM
  • Thanks Riquel.

    The unmanaged DLL is going to be 64-bit DLL - that's the requirment.  As the "media player" component which resides in the managed code which calls the DLL is a 32-bit only assembly, I think it means the "main" application must be of 32-bit architecture too.  That's essential what you're saying.

    Is there a specific IPC (or other) mechanism I should use?  The thing is, and I can't stress it enough, is that the customer must be able to have all the debugging capabilities available for the 64-bit DLL code when it's executed from the 32-bit application.

    Regards,

      Ury

     

    Thursday, May 19, 2011 3:46 PM
  • For the record:  Yes, you need two executables:  A 64-bit one that will load the unmanaged DLL that will become 64-bit as well, and your .Net executable in 32-bit mode to load the media player available only as 32-bit.

    Is the unmanaged DLL a COM DLL?  If yes, you could have the DLL loaded by a COM out-of-process server.  I think it is called dllhost.exe.  Google the name for info on it.  I would imagine that you will have to include a LocalServer32 key that points to dllhost.exe + any command line necessary to load the object?  Or maybe no command line is necessary.  Check it out.  Remember, though:  Your customer will also need to compile a proxy/stub dll in 32-bit mode.

    As for your 32-bit .Net application, I'm not sure how you request the 64-bit version to be activated.  In C++ I would have used CoCreateInstance() and I would have specified the CLSCTX_ACTIVATE_64_BIT_SERVER flag.  See http://msdn.microsoft.com/en-us/library/ms693716(VS.85).aspx and http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx.

    If the unmanaged DLL is not a COM DLL, then you'll have to develop the 64-bit host yourself and then set up some form of IPC.  I personally like pipes.


    MCP
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 5:56 PM
  • You can't have both architectures in one process. If yoy're using COM, the standard mechanism is to have the COM Dll hosted by DllHost, because the RPC between 32-bit and 64-bit doesn't care about bitness.

    I can't speak for the debugging issue. That may be a "does Visual Studio debug across architecture boundaries" question. Visual Studio 2010 is a 32-bit app and I don't know if it an debug in 64-bit mode.  I know dev organisations where people just do all this in 32-bit anyway - the functionality doesn't change just because the code is running 32-bit or 64-bit. 


    Phil Wilson
    • Marked as answer by ury Friday, May 20, 2011 6:39 AM
    Thursday, May 19, 2011 6:01 PM
  • Are there any compelling reasons to move to 64 bit? If the customer is just moving to 64 bit because its what all the hip kids do, just convince him he's about to spend a ton of money without any gains, sometimes the best thing to do is tell a customer 'no'. Depending on what the dll does you might be able to host it in a WCF Service?
    Thursday, May 19, 2011 7:46 PM
  • Hi Phil

    Although VS can debug 64bit application, I would like to guess that VS uses IPC to start the 64Bit components as the background process to inject DLL to debug 64bit application. Then use IPC to control that background process and get the debug information in VS. I don't do VS dev, so I guess this. 

    Rgs,

    Riquel


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Marked as answer by ury Friday, May 20, 2011 6:52 AM
    Friday, May 20, 2011 2:35 AM
  • Thank you all for your responses.

    I think it's agreed that combining the 32-bit only user control and the 64-bit unmanaged code functionality in a single application is possible only by using IPC, probably COM.

    As I said, the major issue I have with that is the "debuggability" I provide my customer with this solution.  The customer's "developers" are MATLAB and image processing experts, and they don't really care about Windows 32/64 bit architecture issues - they just want to be able to debug their algorithms easily, which I'm afraid isn't possible (at least the way they would see it) with IPC.

    So, the 32-bit user control will have to go...

    Thanks again,

      Ury

    Friday, May 20, 2011 6:58 AM