0

My WinForms application will load the unmanaged DLL "stub", and retrieve information. The stub DLLs themselves load unmanaged DLLs "source" to retrieve the information. The 32-bit stub will load 32-bit sources and 64-bit stub will load 64-bit sources. I need a way for my WinForms application to display this information without making a 32 and 64 bit version for it. How can I do it?

I need to access both the 32 and 64 bit stub DLLs as the sources are random (dependant on what the end user has installed), and are 32/64-bit as well. I am making a VST plugin scanner, if this info helps. The source DLLs are VST plugins, obviously I have no control over how many of them are installed and in what bit-width.

demberto
  • 489
  • 5
  • 15
  • 1
    Well, you can compile your WinForms application as AnyCPU, and then at runtime detect whether it's running as x86 or x64 and load the unmanaged DLL with the corresponding bitness... But why would you? – canton7 Sep 23 '21 at 09:06
  • or just keep everything 32bit, since they work on both 32bit and 64bit systems. (unless you really need the additional memory from 64bit) – Turtlefight Sep 23 '21 at 09:14
  • @canton7 I forgot to mention that, I need to use both the 32 and 64 bit stub DLLs as the sources are a bunch of random different DLLs, they can be 32-bit or 64-bit. Its not about the memory space. I know that I can implement an out-of-proc COM server, but I have no idea/skills how to do that. I have edited my question – demberto Sep 23 '21 at 10:23
  • @Turtlefight please check the question or above comment, I cannot mention 2 people in a comment – demberto Sep 23 '21 at 10:29
  • There is no way to load 32bit dlls into a 64bit process or 64bit dlls into a 32bit process. you'll have to spawn a second process with the correct bitness to load the dll. from there on you can use basically any ipc technique you want to communicate between the two processes, e.g. out-of-process COM, pipes, sockets, mailslots, shared memory, etc... – Turtlefight Sep 23 '21 at 10:34
  • [Here's a list from msdn](https://learn.microsoft.com/en-us/windows/win32/ipc/interprocess-communications) of the possible ipc methods with some examples. There you can pick one that meets your requirements and use it to implement a wrapper process that loads the dll and communicates with the main process. – Turtlefight Sep 23 '21 at 10:36
  • Even an "AnyCPU" .NET application will end up being JIT-compiled to either x86 or x64 at runtime. As others have said, you simply cannot load a native x86 DLL into a .NET application which is being JIT'd as x64, and vice versa – canton7 Sep 23 '21 at 10:42
  • The program flow will be WinForms App -> Wrapper process -> stub DLL -> source DLL? @Turtlefight? – demberto Sep 23 '21 at 10:42
  • @demberto there would basically be two processes: one 64bit and one 32bit. one runs your winforms app and loads the matching bitness dlls, the other one is just there to load the other dlls. It all depends on what requirements you have and how you want to communicate between the two processes. But that's way too much to pack into a single comment / answer. – Turtlefight Sep 23 '21 at 11:02
  • @canton7: For .NET Core 'AnyCPU' is useless - unlike .NET Framework, you can't even build it without specifying x86 or x64. – Dave Doknjas Sep 23 '21 at 13:51
  • @Turtlefight performance/speed doesn't matter, its just a few strings, so just looking for the easiest way. Named pipes seem to be the solution ig, what about data copy? – demberto Sep 23 '21 at 15:02

0 Answers0