On Monday 04 November 2002 11:56 am, Alexandre Julliard wrote:
Greg Turner gmturner007@ameritech.net writes:
o Pseudo-debug log emitter: should I be using stderr? is this basically an OK approach? What is the hex number that most real wine debug logs begin with? I'd like to look the same.
Why don't you simply use the Wine debug macros?
Cool. I assumed I wasn't allowed to -- I'd love to use them, I'll give it a shot after work. I presume, then, that I acheive this by just pretending I'm a DLL, and following the same patterns that abound elsewhere?
o the pseudo-fork crud (RPCSS_spork() and the /^ cmd-line arg.) should I be worried about accidentally invoking the real rpcss.exe? is this an unacceptably stupid approach in general?
I'm not sure the fork stuff is really useful. It seems to me this app is going to be launched from inside Wine anyway, not from the command line, so there is no need to make it go into the background.
ATM that's largely correct, except it should also support a "daemon" mode ("/s" command-line argument). For local RPC's, the "lazy" (from rpcrt4.dll) invocation method will be enough. But -- to be a "real," fully functional RPC server, we will need it running in "server" mode. Otherwise, networked RPC's, from without, will always fail, finding no endpoint mapper or name service to converse with at the local host.
This is why you will always find rpcss.exe running on W2K, even when nobody's logged in. Turn off the Remote Procedure Call service (rpcss), and your W2K host is basically dead, or, at best, incapable of networked communications, like domain browsing, mmc administration (even local), filesharing, etc.
So, to sum up my point... supporting some kind of daemon-like mode will become increasingly important as the implementation progresses, and at least marginally useful in the relatively near future (i.e., to test basic networked RPC's, I'll need this).
Thanks for your helpful comments,