-1

I am not so familiar with the Microsoft COM Technology. In a nutshell I have an Microsoft Out-of-process COM Server that is implemented in the executable file foo.exe. The environment is C++ and the Microsoft Foundation Classes Framework (MFC).

There is a client bar.exe which uses functionality within foo.exe over the Microsoft COM Technology. Within foo.exe there are some Dynamic Link Libraries involved which uses also functionality provided by the COM Server foo.exe (for example fooBar.dll).

So far so good. I am on the road of searching a way to determine if the client of the COM Server foo.exe is in an other process or even within the same process as foo.exe such as fooBar.dll in the example above. Does anyone knows such a way?

Edit: With other words: Obvious the COM Server foo.exe can act as an in-process or an out-of-process COM Server. To add up to the comment of Hans Passant and the answer of Joe Willcoxson who is proposing to address the calling DLL via GetModuleHandle to determine if the COM Server acts currently as in-process Server, in case when I got the handle and in case when I not got the handle as out-of-process Server. So it seams that when the COM Server is aware of well-known DLLs which uses functionality from that server within the same process, we could say that the COM Server acts in this moment as in-process Server and in other case as out-of-process Server. Do I misunderstand something or are these considerations correct?

My investigations for the moment are not mentionable so I hoping there is a Microsoft COM Expert in the community who knows how the barrow runs.

Thank you very much for help!

kbisang
  • 558
  • 4
  • 13
  • 1
    Having a valid interface pointer you are not supposed to bother who exactly implements it, especially that in case of out-of-proc server you don't talk to server directly, you talk to proxy instead. That is, there is no standard way but you can query some interface which is known to be not masrhalable across process boundary, and in case you got the pointer you know the server is here in the process. – Roman R. Oct 20 '15 at 15:58
  • The question makes no sense, the terms in/out-of-process only applies to the server. Client code always lives in its own process. – Hans Passant Oct 20 '15 at 15:59
  • 2
    Are you saying that the server (as opposed to the client) loads a DLL, which then turns around and calls methods on that same server? In any case, why do you care who's calling the method? What actual problem are you trying to solve? – Igor Tandetnik Oct 20 '15 at 16:45
  • @Hans Passant: I have concretised the question: I am still on the road of searching a way to determine if the client of the COM Server foo.exe is in an other process or even within the same process as foo.exe such as fooBar.dll in the example above. – kbisang Oct 20 '15 at 18:48
  • @Igor Tandetnik: Yes the server loads a DLL which then turns around and calls methods on that same server. The problem that I try to solve is, to ignore a message box pop up in case when the client runs in an other process. In case when the client runs in the same process as foo.exe I like to allow the message box pop up. – kbisang Oct 20 '15 at 18:53
  • @Roman R. Thanks for your suggestion. How do I query an interface which is known to be not marshalable acros process boundary? Do you have a short code example? – kbisang Oct 20 '15 at 19:02
  • Why would you ever want to have a COM server show message boxes? This is an unusual thing to want to do. For all you know, your server is running on a headless machine, with no monitor, no keyboard and no human present to press OK button. It is generally the client's responsibility to show UI and interact with the user. – Igor Tandetnik Oct 20 '15 at 20:29
  • @Igor Tandetnik: You are absolutely right. But the point is that we develop a legacy financial system with a more or less given architecture which is based on the Microsoft COM Technology as described in the question. – kbisang Oct 21 '15 at 07:12

2 Answers2

1

I am not sure of how you would do it once you already have a COM pointer. However, there is a way when you are creating the object.

The CoCreateInstance() function takes flags CLSCTX_INPROC_SERVER, CLSCTX_INPROC_HANDLER, CLSCTX_LOCAL_SERVER, CLSCTX_REMOTE_SERVER.

Usually the default arguments when you use something like ATL is to combine the flags and it just returns whatever is available. Instead of doing that, you can try the flags individually and see if the object gets created with a particular flag.

I should add that there is sort of a way if the object is actually an OLE object/server. If that is the case, then you can query for IViewObject. If it's in-process, it won't have that interface. If it's out of process, then it will have the interface.

One other thing, if the object implements IRunnableObject and you did not do anything to specifically put it in the running state, then an in process object will most likely be in the running state, and the out of process object will not be in the running state.

A very simple hack may be to call GetModuleHandle() with the name of the DLL. If it returns a handle, then it is in-process. It's not a generic solution, it requires you know the name of the DLL beforehand.

Joseph Willcoxson
  • 5,853
  • 1
  • 15
  • 29
  • Thanks for your answer. You bring me to further considerations which I append to the questions. Please see the edit section. – kbisang Oct 21 '15 at 09:33
0

Within the COM Server foo.exe you can do following.

CTheApp::InitInstance()
{
    [...]
    bool runAsOutOfProcessServer = false;
    CCommandLineInfo commandInfo;
    ParseCommandLine(commandInfo);
    if(commandInfo.m_bRunEmbedded || commandInfo.m_bRunAutomated)
    { 
           runAsOutOfProcessServer = true;
    }
    [...]

    if(runAsOUtOfProcessServer)
       AfxMessageBox("Out of Process Invocation");
}

Obvious there are two members in CCommandLineInfo which indicates that the process is started up as OLE Automation Server or started up to edit an embedded OLE item. With ParseCommandLine you got the information over call by reference to the local variable commandInfo. Then you can check if the members m_bRunEmbedded or m_bRunAutomated are set to determine if the COM Server within foo.exe is started up. Then at the end you can pop up your message box only if the local variable runAsOutOfProcessServer is true.

kbisang
  • 558
  • 4
  • 13