Bug 103756

The coding convention for the dbus library is to report errors through a DBusError (analogous to a GError or a C++ exception) so that they can be caught and handled by application code in whatever way is most appropriate for the application. In particular, this avoids corrupting stdout/stderr if the application is using them for something machine-readable.

However, the Windows implementation of _dbus_get_autolaunch_address() doesn't do that consistently:

          if (!SearchPathA(dbus_module_path, daemon_name, NULL, sizeof(dbus_exe_path), dbus_exe_path, &lpFile))
            {
              dbus_set_error_const (error, DBUS_ERROR_FAILED, "could not find dbus-daemon executable");
              retval = FALSE;
              fprintf (stderr, "please add the path to %s to your PATH environment variable\n", daemon_name);
              fprintf (stderr, "or start the daemon manually\n\n");
            }

(This is after Bug #103601 - before that, it used printf to stdout, which was worse, because stdout is more likely to be used for machine-readable output.)

The warnings that are currently printed to stderr should probably move into the message part of the DBusError. It's OK for a DBusError to be reasonably long.

In library code, we should only emit warnings to stderr as a last resort when nothing else is possible (and if we do that, we should use _dbus_warn() instead of fprintf).

I'm not intending to fix this myself, since I don't develop on Windows and so can't meaningfully test this.