nsnb
20th September 2010 17:48 UTC
Processes::FindProcess vs. nsProcess::FindProcess vs. FindProcDLL
I noticed that there are multiple plug-ins with similar functionality:
http://nsis.sourceforge.net/FindProcDLL_plug-in
http://nsis.sourceforge.net/Processes_plug-in
http://forums.winamp.com/showthread.php?t=230998
My question now is when and why choose one over the other? What are the differences between them? Is one a newer version of another?
I found this excellent thread which provides a clue ("FindProcDLL only finds processes of the currently logged in user"), but I haven't found more information.
Could you please shed some light on this?
Thanks.
Afrow UK
20th September 2010 18:01 UTC
Without looking at the source code, I can guess some use API's that only work prior to Vista or after Windows 98. None of the plug-ins will allow you to find a 64-bit process (because this cannot be done from a 32-bit process unless you use WMI).
Stu
nsnb
20th September 2010 19:26 UTC
Originally posted by Afrow UK
Without looking at the source code, I can guess some use API's that only work prior to Vista or after Windows 98. None of the plug-ins will allow you to find a 64-bit process (because this cannot be done from a 32-bit process unless you use WMI).
Further investigation suggests that nsProcess by
Instructor is the newest of all and supports finding a 64-bit process
if NSIS itself was built on an x64 system. It doesn't support Unicode, however, which a
recent revision of FindProceDLL does.
The
Processes plug-in has an x64 Vista fix, but there is no information about what that fix means.
My conclusion is that
nsProcess is the most mature & complete package (except that some reported it triggers their anti-virus software). I can, of course, be mistaken - so if you think otherwise please let me know.
820815
20th September 2010 21:26 UTC
ProcFunc
Afrow UK
20th September 2010 22:19 UTC
Originally posted by nsnb
...and supports finding a 64-bit process if NSIS itself was built on an x64 system.
The limitation is because NSIS is 32-bit; it is nothing to do with the platform that NSIS is built on. If NSIS was rebuilt as an x64 binary then we wouldn't have the problem. I think I posted a link on this issue in the LockedList plug-in forum topic while I was trying to find a solution. x64 NSIS is not going to be here any time soon - it'd be a lot of work.
So really there are 2 solutions that I can think of at this time. Use WMI (someone posted a header file in a recent post) or write a 64-bit executable which does what the plug-ins do (you could make it a console application and read its output using nsExec::ExecToStack).
Post 7000 FTW.
Edit: In regards to ProcFunc, it uses CreateToolhelp32Snapshot among others (including the FindProcDLL plug-in). From MSDN CreateToolhelp32Snapshot:
If the specified process is a 64-bit process and the caller is a 32-bit process, this function fails and the last error code is ERROR_PARTIAL_COPY (299).
Stu
razvar
11th April 2011 11:16 UTC
You can use IssProc (google it). It was made for Inno but works with nsis, even if the setup is 32bit you will get the 64bit processes, dll's or any file type in use (no WMI required)
hnedka
3rd June 2011 10:23 UTC
Hi, I have created a modification of FindProcDLL plugin, because I found out it doesn't work on 64 bit Windows. It's alpha so far, briefly tested (ANSI version not at all). For the time being I don't recommend it for any serious project.
Changes you won't like:
- removed support for Win9x (too much trouble with it, sorry)
Positive changes:
- can find 64 bit processes (no WMI)
- can find processes called like a short path (for example you are looking for Program.exe, but it's called with a short path, so the real process name is e.g. PROGR~1.EXE and you wouldn't find it before)
- excludes current process from all searches
- you can search for an entire path (or any part of it - from the left), for example:
FindProcDLL::FindProc "C:\Program Files\MyProg\Prog.exe"
>FindProcDLL::FindProc "C:\Program Files"
- you can search for a subpath from the right (backslash is expected in the process path right before the searched string):
FindProcDLL::FindProc "MyProg\Prog.exe"
>FindProcDLL::FindProc "Program Files\MyProg\Prog.exe"
- integrated KillProc function (all of the above updates apply to it):
FindProcDLL::KillProc "myprog.exe"
- added function WaitProcEnd, which waits for a process to exit (doesn't consume any processor time, uses WaitForSingleObject):
FindProcDLL::WaitProcEnd "myprog.exe" -1
>
the second parameter is timeout, if it is reached, the function returns 100 and doesn't wait for the process (recommended value is -1);
if there was no process to wait for, 0 is returned, if successfully waited, returns 1
- added function WaitProcStart, which waits until a certain process start (very processor-intensive, timeout is this time used for the polling interval, set at least 250 ms, 500 is better)
FindProcDLL::WaitProcStart "myprog.exe" 300
>
returns 0 on success
- plugin size is 3.5 kB ;)
All returned values go to $R0, just like in the standard version. I will likely upgrade it soon, if and when I encounter any bugs. Let me know if you find something.
hnedka
3rd June 2011 10:58 UTC
Updated the file from the previous post. Can't edit it now, waits for authorization.
PoRtAbLe_StEaLtH
9th September 2012 21:13 UTC
Thank You Sooo Much !!!!!!
Originally posted by hnedka
Updated the file from the previous post. Can't edit it now, waits for authorization.
i have been struggling with this for a few weeks now.. originally.. i thought it was due to CreateMuteX. .. your MOD fixed it!!!!
what a relief :)
thank you sooo much for sharing .. i couldn't have done it ..
P.S.
hnedka's MOD deserves it's own Wiki page ! :up: