EventGhost

Posted: **Tue Oct 13, 2015 4:25 pm**

Here's the new version.
I am again asking for thorough testing.
I do not know how to set the process priority, if I choose "Run as Administrator"

.

Pako

Posted: **Tue Oct 13, 2015 7:54 pm**

Testing now.

I'll see if I can find a solution for the priority issue. Worst case scenario, we just disable the priority selector when "Run as Administrator" is checked. Technically, the previous version of EG couldn't set priority on elevated processes either, so it's not like this is a regression.

Posted: **Wed Oct 14, 2015 12:20 am**

First off, this:

Code: Select all

if waitForCompletion or triggerEvent:
    processInformation.fMask = SEE_MASK_NOCLOSEPROCESS

...needs to be changed to this:

Code: Select all

processInformation.fMask = SEE_MASK_NOCLOSEPROCESS

Without SEE_MASK_NOCLOSEPROCESS, hProcess doesn't get populated, so SetPriorityClass doesn't have a handle to work with if waitForCompletion and triggerEvent aren't enabled.

As for setting the priority of elevated processes, many people suggest creating a debug token and doing OpenProcess with PROCESS_SET_INFORMATION first, but that doesn't work in Windows 8 and above, so our last remaining option appears to be:

Code: Select all

if priority != 2:
    try:
        SetPriorityClass(processInformation.hProcess, PRIORITY_FLAGS[priority])
    except:
        pid = windll.kernel32.GetProcessId(processInformation.hProcess)
        # Run this command hidden as Administrator: C:\Windows\System32\wbem\wmic.exe process where processid={pid} CALL setpriority {PRIORITY_FLAGS[priority]}

I've added "if priority != 2" because there's no need to take any action at all if "Normal" is selected, and I'm using try/except logic instead of "if not runAsAdmin"/else because SetPriorityClass will choke on auto-elevated processes like mmc.exe even if runAsAdmin isn't enabled.

Posted: **Wed Oct 14, 2015 4:04 pm**

It looks promising.
You can provide the edited file Execute.py?
BTW - I added one choice (High) in the selection of priorities.
So, Normal priority now has index=3, instead of 2.
However, I am thinking about the the deletion of "Realtime" options, so that the new version would not result in a change in priorities for the current configuration.

Pako

Posted: **Wed Oct 14, 2015 8:52 pm**

According to a "Copy as Python", Normal is still 2. It appears to count upwards from Idle (0), so users who previously had Realtime selected will now get High, and "if priority != 2" still does what I want it to do.

I noticed that SetPriorityClass is unable to set Realtime priority in Windows 10 (and 8?), so I've added a GetPriorityClass check afterwards. If the current priority doesn't match the selected priority, I raise an error to skip to the except block, where wmic.exe will correctly set Realtime.

This solution is working well on my end, but definitely let me know how it goes on yours. And don't forget to add "Run as Administrator" to Windows Command. After that, I think we're good to go for release.

Posted: **Fri Oct 16, 2015 12:30 pm**

blackwind wrote:And don't forget to add "Run as Administrator" to Windows Command.

I fear that when using ShellExecuteEx it will not be possible for this action returned results (such as Dir).
I think the best option is to add a new action "Run command as Administrator"
This action will not return any results (excluding return code).

Pako

Posted: **Fri Oct 16, 2015 8:28 pm**

Personally, I'm not a fan of duplicate functionality, both from a user experience standpoint and a code maintainability standpoint. What I would do is simply use ShellExecuteEx for everything, redirect output to a file (for example, cmd.exe /c dir C:\ > %TEMP%\EventGhost-output.txt), read the file to get the result, and delete the file after doing so. The output filename will need to include a timestamp so multiple commands can run at the same time without overwriting each others' output files:

Code: Select all

import os, time
filename = os.path.join(os.getenv("TEMP"), "EventGhost-output-%s.txt" % time.time())

Three benefits to doing things that way:

We don't have several actions for doing basically the same thing.
Users can very quickly change an existing Windows Command to run as Administrator.
Commands run as Administrator will be able to return a result as well.

I'd also like to recommend that Realtime be reinstated in Execute.py. The rationale for removing it was that it would screw up existing priorities, but I proved in my last post that isn't the case. If removing it served a purpose, no problem, but there's no sense in removing existing functionality unless it serves a purpose.

Posted: **Sat Oct 17, 2015 9:24 am**

blackwind wrote:What I would do is simply use ShellExecuteEx for everything, redirect output to a file

This is a very good idea. That solves my problem.I absolutely agree that the existence of two actions (with almost the same functions) is unnecessary.
Before, I thought that if I use ShellExecuteEx, then capturing of standard output is impossible.
That's why I thought it was very confusing to use single action, which in some cases might return results and in some cases not.

Pako

Posted: **Sat Oct 17, 2015 8:00 pm**

Perfect. One last tiny suggestion, and then you have my go-ahead for release:

Code: Select all

payload = "The result to use as payload"

In English, this is a very awkward wording that may make it unclear to some users what exactly the option does. Change it to:

Code: Select all

payload = "Use result as payload"

No need to provide test files for such a small change. I'll get the update in the next release.

Thanks for taking the time to work with me on this. As always, great job!

Posted: **Fri Oct 30, 2015 9:11 pm**

So, back to the topic of the thread: Snarl.

I've been testing uiAccess="true" with my self-signed cert, and it seems that, as far as COM is concerned, this flag still puts the process into a separate privilege space even though we're not running as Administrator. In other words, Snarl.* events don't come through with uiAccess="true" either. In preparation for the signing we'll be doing when Let's Encrypt launches, we need to figure out a way to address this issue.

The AutoHotkey thread in which they discuss uiAccess confirms the COM issue:

ComObjActive/ComObjGet may fail. UIA programs are probably only able to access the active objects of other UIA programs, not regular programs. For example, ComObjActive("Word.Application") will fail because Word is not marked for UI access. The reverse is also true: objects registered by UIA scripts can only be accessed by other UIA programs/scripts.

Therefore, I believe the only possible solution is to create a separate unprivileged process strictly for COM communication, in much the same way that a number of other plugins (like AudioEndpoint) silently load an executable in the background to facilitate their functionality. This executable will communicate with Snarl via COM, and then needs to communicate back to EventGhost somehow (NOT via COM) to trigger the events. We should probably offer an API for the unprivileged process so other plugins that do COM can utilize it as well. Any thoughts on the best way to approach this?

Posted: **Tue Nov 17, 2015 5:19 am**

blackwind wrote:Therefore, I believe the only possible solution is to create a separate unprivileged process strictly for COM communication, in much the same way that a number of other plugins (like AudioEndpoint) silently load an executable in the background to facilitate their functionality. This executable will communicate with Snarl via COM, and then needs to communicate back to EventGhost somehow (NOT via COM) to trigger the events. We should probably offer an API for the unprivileged process so other plugins that do COM can utilize it as well.

It seems feasible, but it is not the only option.
If the problem lies in the fact that communication is via COM, then we can completely eliminate the COM and communicate through the socket. I think it would be easier. However, unfortunately, I have to postpone it yet, plus I can not promise that I'll come back to it.

Pako

Posted: **Tue Nov 17, 2015 7:37 am**

I didn't realize events could be received from Snarl via socket. If that is, indeed, possible, then it's definitely the ideal path forward.

As always, I'm happy to test and provide feedback when you have something to show.

Posted: **Fri Dec 04, 2015 1:42 am**

Let's Encrypt has entered public beta. Any progress yet on stripping out COM?

Posted: **Sun Mar 06, 2016 9:00 am**

The work I'm currently doing on the Git repo requires me to exit EventGhost a lot, and I've found that the EventGhost.exe process always hangs around for about six seconds after exiting if the Snarl plugin is loaded. Could you look into that for me, Pako?

Posted: **Sun Mar 06, 2016 2:46 pm**

I'm sorry, but I do not know how to fix it.
I tried it (a few hours) now, but without success.
Maybe it would be better if we will not use COM.
Perhaps someday I'll come back to it and try to do it.
For me personally, it has no meaning, I do not use Snarl.

Pako

EventGhost

Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl

Re: Snarl