The windows code needs a specific environment for the child in some cases when calling _dbus_spawn_async_with_babysitter(). To avoid platform dependend #ifdefs as in the initial patch done (see comment below) _dbus_spawn_async_with_babysitter() signature is extended with an argument on any platform. >> _dbus_verbose ("Spawning %s ...\n", argv[0]); >> if (!_dbus_spawn_async_with_babysitter (&pending_activation->babysitter, argv, >> +#ifdef DBUS_WIN >> + envp, >> +#endif >The #ifdef here should be somewhere else; I think there was a previous >discussion about how dbus spawn/babysitter doesn't work at all or make sense on >Windows, which I expect is true; if so then there should be a cross-platform >abstraction at a higher level. >But if it does make sense, there should at least be an abstraction that >addresses environment variables vs. however things work on Windows.
Created attachment 6627 [details] [review] added environment argument to _dbus_spawn_async_with_babysitter()
Created attachment 6630 [details] [review] updated patch Added missing dbus/dbus-spawn.h
what about the higher-level question - does it make sense to use the "babysitter" on Windows? I see in the quoted mail I referred to some previous discussion of that, but I don't remember it. I guess there are two uses: - service activation by the daemon - dbus-launch how do these work on windows and how should they work / what would the "windows native" approach be?
- service activation is working on windows too I don't know what dbus-launch has to do with this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.