rpcrt / epmapper / scm

Hi!

Some time ago I did send the rpcrt patches from ove ported to the cvs.
It didn't got included. Are there any special reasons?

The epmapper was implemented in the wineserver. Should it be a standalone server?

1) If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call. 
2) What IPC should we use locally? We could implement LPC like reactos.
3) We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this?
To many questions for one mail? ;-)

juergen

[Ove Kaaven]

On Fri, 2 Aug 2002 [e-mail] wrote:
> Hi!
>
> Some time ago I did send the rpcrt patches from ove ported to the cvs.
> It didn't got included. Are there any special reasons?
>
> The epmapper was implemented in the wineserver. Should it be a standalone server?

Alexandre has expressed that he prefers that, yeah. I guess it makes some
sense, since I'm not sure how you'd put related stuff like the Running
Object Table into the wineserver anyway.
> - If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call.

In real windows, endpoint lookups are cached in the client, and they
aren't done that often anyway, so this won't be a large problem.
> - What IPC should we use locally? We could implement LPC like reactos.

Either that or stick with named pipes like now...
> - We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this?

I've considered it for a while, and the best idea I have so far is to let
the client (rpc_epmap.c) try to connect to the epmapper (LPC or named
pipe), and if it isn't there, launch it with CreateProcess and try to
connect again. Keep the connection to it open until the app exits (or
unloads rpcrt4). Then the epmapper process (rpcss.exe, wasn't it?) can
simply exit cleanly when the last connection to it closes, similar to the
way wineserver itself unloads itself.

But I'm not likely to work on the server part for a while. Whenever I do
get around to resuming working on DCOM stuff, I'm more likely to work on
the IDL compiler and the bytecode marshalling.