1

Topic: out of process the COM-server without registration in the register

There was a task of operation with indirect Cs ++ libraries which support the assembly only under 32 bits, from 64-bit application. Decided to use 32-bit out of process COM the server, that not  interprocess calls. . Complexity that application-client should work without installation (from a flash card, dvd, etc.) . Isolated COM and Side-by-Side manifestos allow regstration free only for DLL in-process, therefore such variant disappears. Some circuit with two exe as a result appeared. The big request to criticize, since experience in development of COM-servers was not. COM only from client side all road used... So in a directory two lie exe-shnika: the 32-bit COM-server (ATL) and the 64-bit client software program. In the register is registered nothing. The client launches the COM-server through CreateProcess, remembers process id. We wait while the server registers classes, before an input in a cycle of messages the server signals named event (its client and waits). The server  guid a COM class somewhere in ole32.dll, but without record in the register to the client object not to create... We Cause CoGetClassObject which searches for a meta-class in the registration table ole, we receive IClassFactory and we create our COM object. It is enough to create one "root" object (with a name root, application, service manager...) And it already to use a surrounding for all operation and, in particular, as factory for other necessary objects (different classes). In the client we use generation of stubs through #import... no_dual_interface. Accordingly stubs work through IDispatch:: Invoke. It removes a problem with , arising that we typelib is not registered in the register. There is one problem. Registration of COM classes in ole32 - global, is not present a warranty that the class registered that process of the COM-server, which client launched through CreateProcess. If the user launched some copies of the program from one or different directories each copy should use the process of the COM-server. In general, any similarity Side-By-Side is necessary. It has been decided to register objects class factory in running object table (IRunningObjectTable) with a unique moniker for each process. A moniker to make from guid a class and id server process. The client also knows guid a class and id server process, can construct an appropriate moniker and through IRunningObjectTable:: GetObject to receive class factory. At usage ATL on server side there was some complexity with capture of a local copy class factory since after construction it is transferred in CoRegisterClassObject and more links to it in process does not remain. Function FinalContruct at ATL-evskoj bases for COM objects Here helped, in it registration class object in running object table transits successfully to call CoRegisterClassObject. I will be grateful for any councils and remarks.

2

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> I Will be grateful for any councils and remarks. Registration not mandatory to do in HKEY_CLASSES_ROOT (which actually HKEY_LOCAL_MACHINE\SOFTWARE\Classes), it is possible to write down all in HKEY_CURRENT_USER\SOFTWARE\Classes which is accessible to record to the simple user. https://msdn.microsoft.com/ru-ru/librar … p/ms724475 (v=vs.85).aspx I.e. yours COM the server can register all necessary classes in HKEY_CURRENT_USER\SOFTWARE\Classes and is normal work. There are two singularities. 1) if we are launched from the Manager that (for safety reasons) registration in HKEY_CURRENT_USER\SOFTWARE\Classes are ignored COM, it is necessary to catch it and all to write in HKEY_LOCAL_MACHINE\SOFTWARE\Classes. 2) Occasionally we come up against a situation when record in HKEY_CURRENT_USER\SOFTWARE\Classes is forbidden by local administrators (most likely that users could not register the associations of files).

3

Re: out of process the COM-server without registration in the register

Hello, aloch, you wrote: A> Registration not mandatory to do in HKEY_CLASSES_ROOT (which actually HKEY_LOCAL_MACHINE\SOFTWARE\Classes), it is possible to write down all in HKEY_CURRENT_USER\SOFTWARE\Classes which is accessible to record to the simple user. Dependence on the register was to be eliminated not so much because of a recording capability/impossibility in HKLM, and for independence of layout exe servers. At least by development exe servers lie in folders Debug and Release, and something can be registered in the register only one... It would be desirable with it exe-shnikom the COM-server to address as with normal dll, threw it in a directory  - and it is good.

4

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> There is one problem. Q> registration of COM classes in ole32 - global, is not present a warranty that the class registered that process of the COM-server which Q> the client launched through CreateProcess. Q> If the user launched some copies of the program from one or different directories each copy should use Q> the process of the COM-server. In general, any similarity Side-By-Side is necessary. Can look in such side: at a class is additional GUID on which too he can be created, it forms dynamic, and is transferred by parameter from one exe to another, and on it becomes CoCreateInstance in the client?

5

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> I Will be grateful for any councils and remarks. And can generally is simple create object in one process, and make CoMarshalInterface with MSHCTX_LOCAL? In other process  CoUnmarshalInterface. IStream in both processes it is possible to create in storage CreateStreamOnHGlobal or SHCreateMemStream. For memory block transmission it is possible to use Named Pipe. Or even Anonymous Pipe (one process can inherit  another or receive prodoubled). Well or Memory-Mapped File. Yes, fuss such only for "a root" class, should go further.

6

Re: out of process the COM-server without registration in the register

Hello, Alexander G, you wrote: AG> Can look in such side: at a class is additional GUID on which too he can be created, it forms dynamic, and is transferred by parameter from one exe to another, and on it becomes CoCreateInstance in the client? And CoCreateInstance on client side whence learns about this additional GUID'? To me it is thought that it gets into the register to search for such class...

7

Re: out of process the COM-server without registration in the register

Hello, Alexander G, you wrote: AG> And can generally is simple create object in one process, and make CoMarshalInterface with MSHCTX_LOCAL? AG> In other process  CoUnmarshalInterface. AG> IStream in both processes it is possible to create in storage CreateStreamOnHGlobal or SHCreateMemStream. I have enough IDispatch for operation with all my objects, and for it is standard . As I understand, dances with tambourines are necessary for   interfaces if typelib in the register it is not registered. Well and still, COM it has been decided to use to leave from explicit usage , divided storage, etc. And so it turns out almost self-made RPC. As to make it I know, but I do not want to fence for the given task.

8

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> As I understand, dances with tambourines are necessary for   interfaces if typelib in the register it is not registered. It is possible to use implementation IDispatch which does MFC - the type library generally is not necessary to it.

9

Re: out of process the COM-server without registration in the register

Hello, aloch, you wrote: A> it is possible to use implementation IDispatch which does MFC - the type library generally is not necessary to it. Implementation of operation with IDispatch on the client or implementation in object (on the server)? We on the server use ATL-preparation, template class IDispatchImpl. If to it in template parameters to specify the version major=FFFF, minor=FFFF it takes typelib from resources exe-shnika, instead of from the register. It quite suits us. On the client operation with IDispath is hidden in generated by the directive #import the code. It is, of course, more convenient, than hands Invoke to cause. Even if to use a wrapper with . For directive operation #import it is necessary typelib only in compile time.

10

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> Hello, aloch, you wrote: A>> it is possible to use implementation IDispatch which does MFC - the type library generally is not necessary to it. Q> Implementation of operation with IDispatch on the client or implementation in object (on the server)? On the server. MFC uses the implementation IDispatch to which the type library is not necessary. It is connected by that IDispatch in MFC (it seems, versions MFC 1.5, still in 16-bit Windows 3.x) appeared __ how there was language IDL (in MFC was used ODL), and accordingly, type libraries as those.

11

Re: out of process the COM-server without registration in the register

Hello, aloch, you wrote: A> On the server. MFC uses the implementation IDispatch to which the type library is not necessary. It is connected by that IDispatch in MFC (it seems, versions MFC 1.5, still in 16-bit Windows 3.x) appeared __ how there was language IDL (in MFC was used ODL), and accordingly, type libraries as those. I looked that there and as. All the same the description, but in the form of ODL is necessary... The Task to get rid of IDL/library of types is not necessary. The main thing in the register to have nothing.

12

Re: out of process the COM-server without registration in the register

Hello, qaz77, you wrote: Q> the description, but in the form of ODL All the same is necessary... This description is necessary only for the client, for this purpose, that helps  worked. MFC implements all through the MAP_... Q> the Task to get rid of IDL/library of types is not necessary. Q> the Main thing in the register to have nothing. It is possible to try the following idea. Using independent from TLB implementation IDispatch (as in MFC) to create the implementation using _ _, created in the register only for the period of the given session for the given location of the main process (on a flash card, in network a full-sphere, on CD) CLSID for a principal class - factories of all remaining necessary classes. Here to you and SxS for OutProc. Independence from TLB is necessary not to be  those GUID which are registered in it. For  it will not be necessary, since COM   IDispatch, and only it and is necessary to you. Certainly, it is necessary to work a little over the server code that its such focus to teach. Well and the client should attend to to create all necessary in the register before reversal to the server, and then all it to clean therefrom (for example, right after root-factory creations)

13

Re: out of process the COM-server without registration in the register

Hello, aloch, you wrote: A> It is possible to try the following idea. Using independent from TLB implementation IDispatch (as in MFC) to create the implementation using _ _, created in the register only for the period of the given session for the given location of the main process (on a flash card, in network a full-sphere, on CD) CLSID for a principal class - factories of all remaining necessary classes. Here to you and SxS for OutProc. Here there will be a struggle for a global resource and race if to launch some copies of my program. For given CLSID only one way to exe in parameter LoalServer32 simultaneously can be specified. A> Independence from TLB is necessary not to be  those GUID which are registered in it. Here did not understand that means. A> for  it will not be necessary, since COM   IDispatch, and only it and is necessary to you. Indeed. A> it is finite, it is necessary to work a little over the server code that its such focus to teach. Well and the client should attend to to create all necessary in the register before reversal to the server, and then all it to clean therefrom (for example, right after root-factory creations) Here it is not pleasant to me. If the client falls, the garbage in the register remains. Usage RunningObjectTable looks more attractive, in it after computer reboot precisely remains nothing. As I understand, registration in RunningObjectTable is provided with any service OLE.