Processes::FindProcess vs. nsProcess::FindProcess vs. FindProcDLL

[nsnb]

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]

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]

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]

ProcFunc

[Afrow UK]

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

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]

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]

Updated the file from the previous post. Can't edit it now, waits for authorization.

[PoRtAbLe_StEaLtH]

Thank You Sooo Much !!!!!!

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 !