This one implements "pseudo-fork" behavior, a main workhorse loop, pseudo-debug log emitter, and command-line interpretation. In particular I'm looking for comments/criticism/flames/etc for:
o my handling of NO_NAMELESS_STRUCT... works for me, but how correct will this be, say, under MSVC with Microsoft headers?
o I differentiate between "server mode" and "lazy mode"... In lazy mode I assume that I'll have at least one incoming connection (if not I time out after 20 minutes); after that, once all endpoints are unmapped (all RPC-specific code is unimplmented, but this is what RPCSS_empty() is supposed to detect) I time out after a short delay (20 sec.) In server mode, I just wait around forever until I'm told to terminate (unimplemented, will be a command-line arg in the tradition of "wineserver -k", processed via the pipe)... reasonable?
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.
o Make/autoconf BS
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?
thanks for your help.
diff -ur -x CVS -x 'bigdif*' ../wine.test/configure.ac ./configure.ac --- ../wine.test/configure.ac 2002-11-03 11:50:15.000000000 -0600 +++ ./configure.ac 2002-11-01 18:53:32.000000000 -0600 @@ -1501,6 +1501,7 @@ programs/regedit/Makefile programs/regsvr32/Makefile programs/regtest/Makefile +programs/rpcss/Makefile programs/uninstaller/Makefile programs/view/Makefile programs/wcmd/Makefile diff -ur -x CVS -x 'bigdif*' ../wine.test/programs/Makefile.in ./programs/Makefile.in --- ../wine.test/programs/Makefile.in 2002-11-03 11:50:15.000000000 -0600 +++ ./programs/Makefile.in 2002-11-01 18:53:18.000000000 -0600 @@ -17,6 +17,7 @@ regedit \ regsvr32 \ regtest \ + rpcss \ uninstaller \ view \ wcmd \ @@ -39,6 +40,7 @@ progman \ regedit \ regsvr32 \ + rpcss \ uninstaller \ wcmd \ wineconsole \ @@ -56,6 +58,7 @@ progman \ regedit \ regsvr32 \ + rpcss \ uninstaller \ wcmd \ wineconsole \ @@ -67,6 +70,7 @@
# Symlinks to apps that we want to run from inside the source tree SYMLINKS = \ + rpcss.exe \ wineconsole.exe \ winedbg.exe
@@ -115,12 +119,16 @@
# Rules for symlinks
+rpcss.exe$(DLLEXT): rpcss/rpcss.exe$(DLLEXT) + $(RM) $@ && $(LN_S) rpcss/rpcss.exe$(DLLEXT) $@ + wineconsole.exe$(DLLEXT): wineconsole/wineconsole.exe$(DLLEXT) $(RM) $@ && $(LN_S) wineconsole/wineconsole.exe$(DLLEXT) $@
winedbg.exe$(DLLEXT): winedbg/winedbg.exe$(DLLEXT) $(RM) $@ && $(LN_S) winedbg/winedbg.exe$(DLLEXT) $@
+rpcss/rpcss.exe$(DLLEXT): rpcss wineconsole/wineconsole.exe$(DLLEXT): wineconsole winedbg/winedbg.exe$(DLLEXT): winedbg
--- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/rpcss/Makefile.in 2002-11-03 18:51:44.000000000 -0600 @@ -0,0 +1,15 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = rpcss.exe +APPMODE = cui +IMPORTS = user32 kernel32 + +C_SRCS = \ + rpcss_main.c + +@MAKE_PROG_RULES@ + +### Dependencies: + --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/rpcss/README 2002-11-03 18:52:12.000000000 -0600 @@ -0,0 +1,23 @@ +rpcss README + +rpcss, copyright 2002, Greg Turner +rpcss is to be distributed under the LGPL/X11-MIT licenses +See the Wine License for further information. + +Wine needs a server whose role is somewhat like that +of rpcss.exe in windows. + +Enjoy. + +KNOWN BUGS / TODO: + + o Service hooks are unimplemented (if you bother to implement + these, also implement net.exe, at least for "net start" and + "net stop" (should be pretty easy I guess, assuming the rest + of the services API infrastructure works (which net.exe should + assume, even if the API is lean or bugged))). + + o Is supposed to use RPC, not random kludges, to map endpoints. + + o Who knows? Whatever (sane) things rpcss does, we ought to at + least think about doing... but what /does/ it do? --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/rpcss/rpcss.h 2002-11-03 18:50:26.000000000 -0600 @@ -0,0 +1,43 @@ +/* + * Copyright 2002 Greg Turner gmturner007@ameritech.net + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __WINE_RPCSS_H +#define __WINE_RPCSS_H + +#include <stdio.h> + +#include "windows.h" + +/* yet another crude debug logger substitute (just what wine needed!) */ +#define RPCSS_DEBUG(args...) \ + do { \ + if (in_debug_mode) {\ + printf("rpcss.exe.so:%s: ", __FUNCTION__); \ + printf(args); \ + } \ + } while (FALSE) + +extern BOOL in_debug_mode; + +extern BOOL RPCSS_is_server(); +extern void RPCSS_be_server(); +extern void RPCSS_server_terminate(); + +#endif /* __WINE_RPCSS_H */ + +/* end of header */ --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/rpcss/rpcss_main.c 2002-11-04 01:16:29.000000000 -0600 @@ -0,0 +1,308 @@ +/* + * rpcss (main.c) + * + * Copyright 2002 Greg Turner gmturner007@ameritech.net + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <assert.h> + +#include "rpcss.h" +#include "winnt.h" + +/* in seconds */ +#define RPCSS_LONG_LAZY_TIMEOUT 1200 +#define RPCSS_SHORT_LAZY_TIMEOUT 20 + +/* are we the "fork child"? */ +static BOOL secret_fork_child; + +/* do we dump debug info to the console? */ +static BOOL in_debug_mode; + +/* are we in server mode, with no timeout? */ +static BOOL in_server_mode; + +/* was server mode terminated? */ +static BOOL server_mode_was_terminated; + +/* when do we just give up and bail? (UTC) */ +static SYSTEMTIME lazy_timeout_time; + +#if defined(NONAMELESSSTRUCT) + #define FILETIME_TO_ULARGEINT(filetime, ularge) \ + ( ularge.s.LowPart = filetime.dwLowDateTime, \ + ularge.s.HighPart = filetime.dwHighDateTime, \ + ularge ) /* r-value */ + #define ULARGEINT_TO_FILETIME(ularge, filetime) \ + ( filetime.dwLowDateTime = ularge.s.LowPart, \ + filetime.dwHighDateTime = ularge.s.HighPart, \ + filetime ) /* r-value */ +#else + #define FILETIME_TO_ULARGEINT(filetime, ularge) \ + ( ularge.LowPart = filetime.dwLowDateTime, \ + ularge.HighPart = filetime.dwHighDateTime, \ + ularge ) /* r-value */ + #define ULARGEINT_TO_FILETIME(ularge, filetime) \ + ( filetime.dwLowDateTime = ularge.LowPart, \ + filetime.dwHighDateTime = ularge.HighPart, \ + filetime ) /* r-value */ +#endif /* NONAMELESSSTRUCT */ + +#define TEN_MIL 10000000LL + +/* returns time remaining in seconds */ +long RPCSS_GetLazyTimeRemaining() +{ + SYSTEMTIME st_just_now; + FILETIME ft_jn, ft_ltt; + ULARGE_INTEGER ul_jn, ul_ltt; + + assert(! in_server_mode); /* then why are you calling? */ + + GetSystemTime(&st_just_now); + SystemTimeToFileTime(&st_just_now, &ft_jn); + FILETIME_TO_ULARGEINT(ft_jn, ul_jn); + + SystemTimeToFileTime(&lazy_timeout_time, &ft_ltt); + FILETIME_TO_ULARGEINT(ft_ltt, ul_ltt); + + return (ul_ltt.QuadPart - ul_jn.QuadPart) / TEN_MIL; +} + +void RPCSS_SetLazyTimeRemaining(long seconds) +{ + SYSTEMTIME st_just_now; + FILETIME ft_jn, ft_ltt; + ULARGE_INTEGER ul_jn, ul_ltt; + + RPCSS_DEBUG("(seconds == %ld)\n", seconds); + + assert(! in_server_mode); /* then why are you calling? */ + assert(seconds >= 0); /* negatives are not allowed */ + + GetSystemTime(&st_just_now); + SystemTimeToFileTime(&st_just_now, &ft_jn); + FILETIME_TO_ULARGEINT(ft_jn, ul_jn); + + /* we want to find the time ltt, s.t. ltt = just_now + seconds */ + ul_ltt.QuadPart = ul_jn.QuadPart + seconds * TEN_MIL; + + /* great. just remember it */ + ULARGEINT_TO_FILETIME(ul_ltt, ft_ltt); + if (! FileTimeToSystemTime(&ft_ltt, &lazy_timeout_time)) + assert(FALSE); +} + +#undef FILETIME_TO_ULARGEINT +#undef ULARGEINT_TO_FILETIME +#undef TEN_MIL + +BOOL RPCSS_is_server() +{ + return in_server_mode; +} + +void RPCSS_be_server() +{ + RPCSS_DEBUG("\n"); + in_server_mode = TRUE; +} + +void RPCSS_server_terminate() +{ + assert(in_server_mode); + server_mode_was_terminated = TRUE; +} + +BOOL RPCSS_work() +{ + RPCSS_DEBUG("\n"); + Sleep(1000); + return FALSE; /* we didn't do anything */ +} + +BOOL RPCSS_empty() +{ + BOOL rslt = TRUE; + + /* FIXME */ + + RPCSS_DEBUG("%s\n", rslt ? "TRUE" : "FALSE" ); + return rslt; +} + +BOOL RPCSS_is_ready_to_die() +{ + return + ( + RPCSS_empty() && + ( + (in_server_mode && server_mode_was_terminated) || + ( + (! in_server_mode) && + (RPCSS_GetLazyTimeRemaining() <= 0) + ) + ) + ); +} + +void RPCSS_main_loop() { + BOOL did_something_new; + + RPCSS_DEBUG("\n"); + + for (;;) { + did_something_new = FALSE; + + while ( (! did_something_new) && (! RPCSS_is_ready_to_die()) ) + did_something_new = (RPCSS_work() || did_something_new); + + if ((! did_something_new) && RPCSS_is_ready_to_die()) + break; /* that's it for us */ + + if (did_something_new) { + /* if we were in server mode, but terminated, then, + because we did something new, fall back to lazy mode */ + if (in_server_mode && server_mode_was_terminated) + in_server_mode = server_mode_was_terminated = FALSE; + + /* if we aren't in server mode, set the lazy timeout */ + if (! in_server_mode) + RPCSS_SetLazyTimeRemaining(RPCSS_SHORT_LAZY_TIMEOUT); + } + } +} + +BOOL RPCSS_ProcessArgs( int argc, char **argv ) +{ + int i; + char *c; + + for (i = 1; i < argc; i++) { + c = argv[i]; + while (*c == ' ') c++; + if ((*c != '-') && (*c != '/')) + return FALSE; + c++; + switch (*c++) { + case 's': + case 'S': + in_server_mode = TRUE; + break; + case 'd': + case 'D': + in_debug_mode = TRUE; + break; + case '^': + /* "secret" hidden command-line arg means we are the "fork child" */ + secret_fork_child = TRUE; + break; + default: + return FALSE; + break; + } + while (*c == ' ') c++; + if (*c != '\0') return FALSE; + } + + return TRUE; +} + +void RPCSS_Usage() +{ + printf("\nWine RPCSS\n"); + printf("\nsyntax: rpcss [/d] [/s]\n\n"); + printf(" /d: debug mode (print debug messages to std. output)\n"); + printf(" /s: server mode (don't time out)\n\n"); +} + +void RPCSS_Spork() +{ + /* Because we are a wine app, we can't fork. This is + a trick to invoke ourselves, so we can provide a + similar effect of creating a "background" process */ + + PROCESS_INFORMATION pi; + STARTUPINFO si; + char *oldcmdline, *newcmdline; + + /* create a string to invoke ourselves */ + oldcmdline = GetCommandLineA(); + newcmdline = LocalAlloc(LPTR, strlen(oldcmdline) + 10); /* more than enough */ + assert(newcmdline); /* must succeed */ + + sprintf(newcmdline, "%s /^", oldcmdline); + + ZeroMemory(&pi, sizeof(PROCESS_INFORMATION)); + ZeroMemory(&si, sizeof(STARTUPINFO)); + si.cb = sizeof(STARTUPINFO); + + if (!CreateProcess( + NULL, // executable + newcmdline, // command line + NULL, // process security attributes + NULL, // primary thread security attributes + FALSE, // no inherit handles + 0, // creation flags + NULL, // use parent's environment + NULL, // use parent's current directory + &si, // STARTUPINFO pointer + &pi // PROCESS_INFORMATION + )) + assert(FALSE); + + LocalFree(newcmdline); +} + +int main( int argc, char **argv ) +{ + /* + * We are invoked as a standard executable; typically, we act in a + * "lazy" manner. We open up our pipe, and hang around until we have + * nothing left to do, and then silently terminate. When we're needed + * again, rpcrt4.dll.so will invoke us automatically. + */ + + if (!RPCSS_ProcessArgs(argc, argv)) { + RPCSS_Usage(); + return 1; + } + + if (! in_debug_mode) { + if (secret_fork_child) + FreeConsole(); + else { + /* pseudo-fork */ + RPCSS_Spork(); + return 0; + } + } else if (secret_fork_child) { + /* this should never happen... perhaps they typed /d /^ on cmd line */ + RPCSS_Usage(); + return 2; + } + + if (! in_server_mode) + /* we want to wait for something to happen, and then + timeout when no activity occurs... but we will be + extra patient on the first wait */ + RPCSS_SetLazyTimeRemaining(RPCSS_LONG_LAZY_TIMEOUT); + + RPCSS_main_loop(); + + return 0; +}
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?
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.
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,
Greg Turner gmturner007@ameritech.net writes:
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?
Yes; the only difference is that in Winelib apps you need to prefix them with WINE_, so use WINE_TRACE instead of TRACE etc.
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.
Ultimately we may need something like this yes, but I would suggest not worrying about it for now. Debugging will be a lot easier if the app doesn't go into the background, even in daemon mode. And then we may want to add support somewhere so that you can do a real Unix daemon (with fork, setsid, etc.), so it's not clear that your CreateProcess hack will be needed even for the final implementation.
On 4 Nov 2002, Alexandre Julliard wrote:
Greg Turner gmturner007@ameritech.net writes:
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?
Yes; the only difference is that in Winelib apps you need to prefix them with WINE_, so use WINE_TRACE instead of TRACE etc.
Also, winemaker users will have trouble because winemaker does not pass the relevant option to winebuild and does not compile and link with the needed xxx.dbg.c file.
Any volunteer for making the necessary (simple) changes to winemaker?
Am Mon, 2002-11-04 um 23.45 schrieb Francois Gouget:
Any volunteer for making the necessary (simple) changes to winemaker?
Are these "simple changes" documented anywhere ? Winebuild is a miracle to me, and I guess to many others too, even people who have contributed substantial amounts of code.
Martin
On 5 Nov 2002, Martin Wilck wrote:
Am Mon, 2002-11-04 um 23.45 schrieb Francois Gouget:
Any volunteer for making the necessary (simple) changes to winemaker?
Are these "simple changes" documented anywhere ?
Nope.
Winebuild is a miracle to me, and I guess to many others too, even people who have contributed substantial amounts of code.
Winebuild is a bit of a mystery for everyone. The trick is to look at how Wine's Makefiles do things and do the same :-)
Am Die, 2002-11-05 um 21.51 schrieb Francois Gouget:
Are these "simple changes" documented anywhere ?
Nope.
Winebuild is a bit of a mystery for everyone. The trick is to look at how Wine's Makefiles do things and do the same :-)
I was guessing so :-/ Perhaps I'll give it a try.
Martin
On Mon, 4 Nov 2002, Greg Turner wrote:
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.
Note that to be a "real, fully functional RPC server", it would have to bind to a privileged port and such, providing all the DCE RPC daemon services that should live on that port. I'm not sure I would trust a complex Winelib app to run as root, listening on an open network port. It'd probably be much better to let the user run a real DCE RPC daemon (like freedce's) as root, and just have Wine's rpcss communicate with it as necessary to update this real daemon's registrations. Then several (Unix) users could run RPC services on the same host, too.
(Doesn't solve the problem with remote activation, though)
On Monday 04 November 2002 05:04 pm, Ove Kaaven wrote:
Note that to be a "real, fully functional RPC server", it would have to bind to a privileged port and such, providing all the DCE RPC daemon services that should live on that port. I'm not sure I would trust a complex Winelib app to run as root, listening on an open network port. It'd probably be much better to let the user run a real DCE RPC daemon (like freedce's) as root, and just have Wine's rpcss communicate with it as necessary to update this real daemon's registrations. Then several (Unix) users could run RPC services on the same host, too.
(Doesn't solve the problem with remote activation, though)
good point, I hadn't given that much thought. It's an interesting problem. I guess we'll have to deal with it sooner or later, but, lucky for us, probably later than sooner :)
Also, aren't some of these ports often locked up by samba? Perhaps a "real solution" will eventually have to entail a native unix RPC routing mechanism which runs as root, and decides whether an incoming RPC goes to samba, wine-as-user, dce-rpc, or some other target, based on lord-knows-what criteria...
On Mon, 4 Nov 2002, Greg Turner wrote:
On Monday 04 November 2002 05:04 pm, Ove Kaaven wrote:
Note that to be a "real, fully functional RPC server", it would have to bind to a privileged port and such, providing all the DCE RPC daemon services that should live on that port. I'm not sure I would trust a complex Winelib app to run as root, listening on an open network port. It'd probably be much better to let the user run a real DCE RPC daemon (like freedce's) as root, and just have Wine's rpcss communicate with it as necessary to update this real daemon's registrations. Then several (Unix) users could run RPC services on the same host, too.
(Doesn't solve the problem with remote activation, though)
good point, I hadn't given that much thought. It's an interesting problem. I guess we'll have to deal with it sooner or later, but, lucky for us, probably later than sooner :)
Also, aren't some of these ports often locked up by samba? Perhaps a "real solution" will eventually have to entail a native unix RPC routing mechanism which runs as root, and decides whether an incoming RPC goes to samba, wine-as-user, dce-rpc, or some other target, based on lord-knows-what criteria...
Hmm, that may not be necessary. If Samba provides a RPC registration service then we wouldn't need another DCE RPC daemon like freedce's, we could just use Samba as our registration service (and if uses the port but doesn't have that feature yet, someone might be able to convince them to add it). It would also appear easier to plug remote activation into Samba (i.e. make Samba start "wine myservice.exe" when that service is requested by remote host) than into any other daemon, if it is ever needed. It'd probably be worth looking into when the time comes.
Am Die, 2002-11-05 um 13.43 schrieb Ove Kaaven:
Hmm, that may not be necessary. If Samba provides a RPC registration service then we wouldn't need another DCE RPC daemon like freedce's, we could just use Samba as our registration service (and if uses the port but doesn't have that feature yet, someone might be able to convince them to add it).
Good luck! From what I learned in my latest Samba inquiry, they have other things to worry about. In any case you must make sure this is all properly separated, for GPL license issues.
It'd probably be worth looking into when the time comes.
I recommend approaching the Samba guys early so that they know this functionality is desired. Whoever wants to implement this must be prepared to dig into Samba hacking.
Martin
On Tuesday 05 November 2002 07:34 am, Martin Wilck wrote:
Am Die, 2002-11-05 um 13.43 schrieb Ove Kaaven:
Hmm, that may not be necessary. If Samba provides a RPC registration service then we wouldn't need another DCE RPC daemon like freedce's, we could just use Samba as our registration service (and if uses the port but doesn't have that feature yet, someone might be able to convince them to add it).
the only thing that's a little wierd about this is the prospect of creating a (conditional) dependency on Samba for wine... perhaps we want both (A) support from Samba and (B) our own service capable of listening on these ports and firing up rpcss as needed, under some user context(s).
Anyways, it's a bit of a project in-and-of-itself... it's important to think ahead, but there's no point in planning out the finer details until we have the basics implemented.
Good luck! From what I learned in my latest Samba inquiry, they have other things to worry about.
yes, I hear they are busy.
In any case you must make sure this is all properly separated, for GPL license issues.
yup. X11 (and LGPL?) code can be sublicensed by Samba under GPL, but it's a one-way-street, I guess. It's not worth driving ourselves nuts over these issues until the big picture is clearer.
It'd probably be worth looking into when the time comes.
I recommend approaching the Samba guys early so that they know this functionality is desired. Whoever wants to implement this must be prepared to dig into Samba hacking.
Martin
I think, ATM, it's premature to do much more than let them know what's going on on our end. It'd be somewhat unreasonable to expect the busy Samba hackers to code against our vaporware. Maybe I'll fire off some e-mails to them after work today... looks like more mailing list subscriptions for me... :(
Greg Turner wrote:
Anyways, it's a bit of a project in-and-of-itself... it's important to think ahead, but there's no point in planning out the finer details until we have the basics implemented.
I have a question. Why is it that we think that all possible DLLs must come under the base WINE source tree? Even MS don't work this way. In a way, Wine is just the PE loader and linker, and the wineserver. Due to natural constrains, it may be wise to put anyone that needs to talk to wineserver under the WINE tree as well. Why is it, however, that everyone else are also under the same tree?
Shachar
+void RPCSS_Spork() +{
- /* Because we are a wine app, we can't fork. This is
a trick to invoke ourselves, so we can provide asimilar effect of creating a "background" process */
I was wondering about this but have been busy with other things. In shelllink.c we call fork and waitpid for shell32. Shouldnt this code be removed and reimplemented like in rpcss? When I am trying to build shell32 under windows I still get this
shelllink.o(.text+0x4161):shelllink.c: undefined reference to `fork' shelllink.o(.text+0x43fa):shelllink.c: undefined reference to `waitpid'
Can someone give a example of how to work around waitpid and maybe I can adapt Gregs Spork code. Thanks Steven
On Saturday 09 November 2002 08:33 pm, Steven Edwards wrote:
+void RPCSS_Spork() +{
- /* Because we are a wine app, we can't fork. This is
a trick to invoke ourselves, so we can provide asimilar effect of creating a "background" process */I was wondering about this but have been busy with other things. In shelllink.c we call fork and waitpid for shell32. Shouldnt this code be removed and reimplemented like in rpcss? When I am trying to build shell32 under windows I still get this
shelllink.o(.text+0x4161):shelllink.c: undefined reference to `fork' shelllink.o(.text+0x43fa):shelllink.c: undefined reference to `waitpid'
Can someone give a example of how to work around waitpid and maybe I can adapt Gregs Spork code. Thanks Steven
I think what you are looking for is here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas...
beware, however, that the "Spork" function and fork() are more-or-less completely different. That spork code is just a cheap-and-dirty way to invoke yourself. This means that:
o spork only returns once o the child process doesn't inherit state from the parent process o it will only work for processes for which you control the source; dll's can't do it this way.
I think, long ago, I saw seen some clever folks attempt to implement fork() like behavior for windows; if you need the "real deal," you might be able to find this with some googling, or maybe cygwin has ideas you could borrow.
-
Alexandre Julliard -
Francois Gouget -
Greg Turner -
Martin Wilck -
Ove Kaaven -
Shachar Shemesh -
Steven Edwards