0
  • EXE 'A' is written in C#. 'A' calls DLL 'B', also written in C#.
  • DLL 'B' calls CreateProcess to launch a second EXE 'C'. 'C' is written in native C++, Win32.
  • 'C' needs to be able to call a function in DLL 'B' because 'B' knows of a handle with which it can obtain info from 'A'. The handle will be stored as a global variable within B.

I know how to call a managed C# DLL from a Native C++ EXE.

My question is: how can we make C call back into B? How does C find B?

Pierre
  • 4,114
  • 2
  • 34
  • 39
  • 3
    I'd use a named pipe, give it a GUID name and pass the name as a command line argument to C – Scott Chamberlain Jun 08 '16 at 23:26
  • 'C' needs to be an executable because it's an application that's already been written, many KLOCs of code. It's an interactive graphics app, tightly bound to the Windows message loop, would take many months to turn into a DLL. It's doable, but I'm looking to save time. – Pierre Jun 09 '16 at 02:39
  • Why on earth would this be downvoted? Would anyone downvoting please have the courtesy of explaining why they chose to do so? Scott Chamberlain's suggestion of using named pipes is excellent, and may provide me with the solution I'm looking for. – Pierre Jun 09 '16 at 03:07
  • 1
    At a guess, it's because they consider it obvious that calling a function in a different process is impossible. I personally disagree with downvoting on those grounds, and I suspect that in fact you *could* in principle achieve a reasonable facsimile of what you've asked for using COM, but such is life. (For the record, a named pipe is probably a more reasonable solution to your actual problem than COM anyway.) – Harry Johnston Jun 09 '16 at 04:00
  • Thank you Harry Johnston, I had thought about COM, because I was concerned about the performance of named pipes. This thing is going to involve a lot of XML data. I'll give NP a try. – Pierre Jun 09 '16 at 11:04
  • 2
    Named pipes are implemented using shared memory. With respect to performance there is little you can do to get any better. Without knowing what *"a lot of XML data"* is you cannot expect reasonable responses, though. As for the down-votes, I guess it is, because this question completely ignores a very basic concept: process isolation. This isn't anything new either; it has been commonplace literally for decades. – IInspectable Jun 09 '16 at 17:23
  • I've got a C# server & C++ client pipe going. The data transfer rate is a combined 30 MB/sec. for I/O, pretty decent (i7-6700 3.40 GHz). Pipes is the way to go. Thank you to all who contributed positively. – Pierre Jun 10 '16 at 11:58

2 Answers2

2

No, it can't.

The DLL and EXE are in different processes, and you cannot call a function in a different process.

user253751
  • 57,427
  • 7
  • 48
  • 90
  • What about with a pipe as suggested by Scott Chamberlain? Would that avoid the problem of being in a different process? – Pierre Jun 09 '16 at 02:41
  • 2
    It depends what you mean by "avoid". Named pipes work across processes, of course. But they don't allow you to call a function in the other process, they just let you pass bytes around. Presumably that's all you really need. – Harry Johnston Jun 09 '16 at 03:24
-1

straight forward answer: yes you can. But it is an really annoying process. You got to create a callback in B and C needs to receive this callback.

So here some links to help you with loading the unmanaged dll.

http://timtrott.co.uk/calling-win32-dlls/
Is it possible to use win32 DLLs in C#?
https://msdn.microsoft.com/en-us/library/aa719104%28v=vs.71%29.aspx

And here is how to create your callback:
Howto implement callback interface from unmanaged DLL to .net app?

My advice is, avoid doing this. unmanaged dlls should be used only in the "request and return" mode, what means that they only answer requests from the caller and the caller waits until the dll finish the process.

Community
  • 1
  • 1
Allan Leon Alencar Leitão
  • 94
  • 1
  • 8