Process lasso as a service?

chris635 · November 30, 2014, 10:56:07 AM

Hey guys,

I am the only user on this machine. I use it for everything including gaming (overclocked and water cooled). Would running process lasso as a service cause more problems than it's worth? I'm curious since I have the pro version.

Chris

BenYeeHua · November 30, 2014, 11:29:44 AM

Nope, it should not causing any difference, just running as service can allow it to manage the other users/processes while your main user is log out, which will end all processes except services.

Jeremy Collake · November 30, 2014, 11:58:00 AM

UPDATE: Governor as a service no longer has these limitations.

When the governor is run as a service, it does change (not, see update) the behavior of ProBalance slightly. It can no longer identify which process is in the foreground, a restriction of Windows, thus it may restrain the foreground process when it otherwise wouldn't have. Probably this has no real-world implications, as 'restraint' is just a marginal reduction in the priority class, but it's something to be aware of.

Otherwise, it will function mostly the same as when running as a normal process.

chris635 · November 30, 2014, 12:02:57 PM

Okay, thanks. I'll check it on some games later.

Chris

Jeremy Collake · November 30, 2014, 12:29:50 PM

It should be fine with games, for they will be excluded if they are marked as a game.

A worst case scenario is that you may have to manually exclude a process that you wouldn't have otherwise excluded.

The simple answer is everything will be just fine

. I just wanted to mention that caveat.

chris635 · November 30, 2014, 12:44:02 PM

Okay

BenYeeHua · November 30, 2014, 03:32:18 PM

Quote from: Jeremy Collake on November 30, 2014, 11:58:00 AM
When the governor is run as a service, it does change the behavior of ProBalance slightly. It can no longer identify which process is in the foreground, a restriction of Windows, thus it may restrain the foreground process when it otherwise wouldn't have. Probably this has no real-world implications, as 'restraint' is just a marginal reduction in the priority class, but it's something to be aware of.

Otherwise, it will function mostly the same as when running as a normal process.

Hmm, so I guess it is a limit for service that disallow to using something like EVENT_SYSTEM_FOREGROUND?
Or it is because of difference "User"?

---
Wait... Or did you means active process/window?
http://stackoverflow.com/questions/3940346/foreground-vs-active-window

And I think it can guess based on the priority too.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684828%28v=vs.85%29.aspx

Jeremy Collake · November 30, 2014, 03:43:44 PM

It is because it is running as a different user. Session isolation would require I run a client in the user space to identify the current foreground process. It's something I've considered, but haven't had a need to do.

In fact, in many cases, it may be preferable to allow ProBalance to act on the foreground process.

And by 'foreground' I mean the process that owns the window that currently has keyboard and mouse focus. That whole StackOverflow discussion is based on some semantic confusion in the MSDN docs. It's not really pertinent, and I don't want to break my brain trying to figure out what people think certain terms are supposed to mean.

Reading closer, I see the people in that StackOverflow question are trying to say that a non-active foreground window can overlap the active window. I suppose that's true, but it's irrelevant and misleading. The API used is GetForegroundWindow, which 'Retrieves a handle to the foreground window (the window with which the user is currently working)'. In any event, it's irrelevant to the OP, and also to me. Foreground is the one I want.

chris635 · November 30, 2014, 04:42:55 PM

Are the anti sleep process's supposed still work with service?

Chris

BenYeeHua · December 02, 2014, 08:44:18 AM

Thank for the explanation, so ya, just keep it as foreground, as I just call the foreground windows that don't has focus as on the top.

Quote from: chris635 on November 30, 2014, 04:42:55 PM
Are the anti sleep process's supposed still work with service?

Chris

Yes, as it can manage/see the processes, it will anti sleep.

For the foreground, the API will report difference answer for difference user, so it will stop working when the governor is running under difference user, for security and privacy.
Just thinking like a server with many difference user that are using it at the same time, why it should report the foreground window that is under the other user to you?

chris635 · December 02, 2014, 10:18:27 AM

I am having a problem with the anti sleep process's in service mode then. My monitor is set to go to sleep after 15 minutes. With my browser ,itune's..etc I have them set as anti sleep process's. Under service mode these process's do not keep my monitor from going to sleep after 15 minutes. I wonder if I should delete these process's from anti sleep, then re apply them once in service mode?

Chris

Jeremy Collake · December 02, 2014, 10:23:48 AM

I don't think it would help to reapply those rules.

This is one feature I have not tested well in service mode. Typically, service mode is used on servers, and they don't often make use of the 'consumer' functions.

Let me do some investigation and see what is going on. There may be some inherent restriction or other problem. I'll let you know what I discover, and thanks for bringing it to my attention.

chris635 · December 02, 2014, 11:15:12 AM

Yeah re-applying the rules once in service mode doesn't work.

Chris

Jeremy Collake · December 12, 2014, 11:09:23 PM

I believe the cause is that I can't keep the PC awake when the governor is running as a non-interactive service. Well, not without a refactor.

That code relies on being in an interactive user session.

You could try opening the properties tab of the Governor service and selecting 'Allow service to interact with desktop'. OR you could run the service as a specific user.