Name, life-cycle, directory structure, autoconf, temporary kludges for wine rpcss subtitute?
Sorry, in advance, for this barrage of questions... but I'm getting anxious to proceed with this thing.
Naming:
This guy needs a name if I'm ever going to start coding it. How about: Wine Remote Procedure Call System Server aka wrpcss.exe.so? A little misleading with the "ss" thing, but this name will look familiar to windows users, and is more accurate than my previous idea of wine-epmap, since it will eventually need to do more than just endpoint mapping.
I pretend this is the right name below, but if there's a better one, just substitute that in everywhere you see "wrpcss" in the following discussion.
Life Cycle:
Some scenarios will require wrpcss to run all the time as a daemon-type-thingy; most wont -- the majority of scenarios require dynamic on-demand invocation and auto-termination upon unmapping of all registered endpoints, as Ove suggested.
Are command line arguments an appropriate way to differentiate between these modes? This ends up going back to the open question of how to implement services in wine; but, of course, I don't want to wait for this to be resolved before proceeding. Whatever solution wine implements for services, adapting wrpcss to it won't be insurmountable (assuming it's a good solution).
Also: if run as a service, how do I get "detached" without using "fork()"? Is there some existing example of this I ought to emulate?
Directory Structure:
dlls/rpcrt4/wrpcss/ ? programs/wrpcss/ ?
Autoconf:
I can try to implment the necessary infrastructure myself, but if history is any guide, I will screw it up. If anyone is feeling generous with their time, they could give me a skeleton to fill in.
Temporary Kludges:
DCE does, indeed, provide the necessary idl to implement the endpoint mapper. Unfortunately, although the IDL is reasonably simple, there are just too many types in there to "do it right" from the beginning.
Meanwhile, I am getting sick of dragging along the unmerged server parts (it isn't that hard, but I'm lazy).
So, as discussed earlier, I propose the named-pipes hack until a full implementation is possible. I would, of course, take some care to keep the kludge-based parts separate from meaningful, potentially permanent parts of the code... howsabout I just listen at \.\pipe\wrpcss for the time being?
thanks for your input,
Greg Turner gmturner007@ameritech.net writes:
This guy needs a name if I'm ever going to start coding it. How about: Wine Remote Procedure Call System Server aka wrpcss.exe.so? A little misleading with the "ss" thing, but this name will look familiar to windows users, and is more accurate than my previous idea of wine-epmap, since it will eventually need to do more than just endpoint mapping.
If it's ever going to be compatible with Windows rpcss.exe then we should use the same name. Otherwise winerpcss.exe would probably be better to avoid potential name collisions.
On Friday 01 November 2002 10:21 am, Alexandre Julliard wrote:
Greg Turner gmturner007@ameritech.net writes:
This guy needs a name if I'm ever going to start coding it. How about: Wine Remote Procedure Call System Server aka wrpcss.exe.so? A little misleading with the "ss" thing, but this name will look familiar to windows users, and is more accurate than my previous idea of wine-epmap, since it will eventually need to do more than just endpoint mapping.
If it's ever going to be compatible with Windows rpcss.exe then we should use the same name. Otherwise winerpcss.exe would probably be better to avoid potential name collisions.
That's a good question... would/should/could our thing ever be compatible with the windows one? My pseudo-educated guess is no/no/no, mostly because its a windows subsystem, and hence operates at a lower level than wine... but I'd like to hear Ove's opinion (or anyone else's, of course).
On Fri, 1 Nov 2002, Greg Turner wrote:
On Friday 01 November 2002 10:21 am, Alexandre Julliard wrote:
Greg Turner gmturner007@ameritech.net writes:
This guy needs a name if I'm ever going to start coding it. How about: Wine Remote Procedure Call System Server aka wrpcss.exe.so? A little misleading with the "ss" thing, but this name will look familiar to windows users, and is more accurate than my previous idea of wine-epmap, since it will eventually need to do more than just endpoint mapping.
If it's ever going to be compatible with Windows rpcss.exe then we should use the same name. Otherwise winerpcss.exe would probably be better to avoid potential name collisions.
That's a good question... would/should/could our thing ever be compatible with the windows one?
I think I'd say dunno/maybe/yes. There's no terribly good reason to make it compatible, but I know of no terribly good reason not to either (except for the fact that we don't know exactly how much stuff it does - I think it does RPC/DCOM registrations, DCOM object activation, and probably hosts the Running Object Table). It's probably wisest to make it as compatible as we know how anyway, just in case.
Ove Kaaven ovehk@ping.uio.no writes:
I think I'd say dunno/maybe/yes. There's no terribly good reason to make it compatible, but I know of no terribly good reason not to either (except for the fact that we don't know exactly how much stuff it does - I think it does RPC/DCOM registrations, DCOM object activation, and probably hosts the Running Object Table). It's probably wisest to make it as compatible as we know how anyway, just in case.
Well, a good reason for being compatible is that we can then plug in the native rpcss.exe, that would be a great help for testing. So if it's possible I think it's worth it.
On Friday 01 November 2002 02:55 pm, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
I think I'd say dunno/maybe/yes. There's no terribly good reason to make it compatible, but I know of no terribly good reason not to either (except for the fact that we don't know exactly how much stuff it does - I think it does RPC/DCOM registrations, DCOM object activation, and probably hosts the Running Object Table). It's probably wisest to make it as compatible as we know how anyway, just in case.
Well, a good reason for being compatible is that we can then plug in the native rpcss.exe, that would be a great help for testing. So if it's possible I think it's worth it.
I'm afraid it probably isn't, rpcss probably uses NT "Ports" and many other very scary internal/undocumented wingarbages... I presume all those "*ss.exe" executables that hang around are this way... then again, it would be fun to try, wouldn't it? I'll have to snag one from W2K, run it under wine, and see what happens some time...
It's a service exe, I think, so, presumably, if we want to be like it, we just follow those conventions (or are there different ones for wine "services"?)
-
Alexandre Julliard -
Greg Turner -
Ove Kaaven