[Mono-dev] mono-service bugs

[Robert Jordan]

Hi,

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
> corlib/System/Environment.cs).
> 
> 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
mean anything.

> 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.

Robert