On Fri, 2 Aug 2002 juergen.schmied@debitel.net 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.