[Mono-dev] mono-service bugs
robertj at gmx.net
Mon Feb 4 13:36:27 EST 2008
Avery Pennarun wrote:
> 4. Environment.UserInteractive should be false when run as a service
> but true when run as a normal user; in Mono, it's always false (see
> All of these are probably very easy fixes except #4, which is why I'm
> asking here instead of just filing the bug or submitting a patch.
> What does "interactive" mean in mono? In Windows, it's a well-defined
> concept (if you're not interactive, there's just no such thing as
> stdout or stderr or popup dialogs etc; if you are interactive, then
This is not quite correct. On Windows, even services have a
desktop, but this desktop belongs to a non interactive
window station. I guess the code behind UserInteractive
is just checking whether the process' station name == "Winsta0",
which is per definition the one and only interactive station,
even in the context of a terminal server.
Stdin/out/err do not count, because on both Windows and Unix
their existence or (nonexistence for that matter) doesn't
> there is). In Unix, it's unclear: even daemons might have a stderr
> (albeit not one they should usually be using) and even user-level
> applications might not be able to pop up dialogs.
> I would be happy to submit a fix for Environment.UserInteractive, but
> it's not obvious how we should do it. Would checking for a valid
> stdin work? Or maybe it should always be true except when
> mono-service explicitly makes it false somehow? Does mono-service
> have access to internal methods that would let it poke at environment
> settings like that?
Mono-service might call an internal method, e.g
Environment.SetUserInteractive(false), via reflection.
Another way might be to check whether the process has
a controlling terminal.
More information about the Mono-devel-list