Debug and explanatory messages describing the course of events and the current state of the process

[abzalov]

This is probably more of a discussion.

I made a separate branch OutputDebugMessage - master...abzalov:LockedList:OutputDebugMessage
These changes were needed in our company and turned out to be very useful to us.

I don’t know if they should be transferred to the main repository, but perhaps they will be useful to someone else.
What do you think about it?

Here's a brief description of the new feature.
Added debug messages and explanatory messages describing the course of events and the current state of the process:

• about found locking applications
• about applications that should be skipped (response from callback)
• about applications that will be closed (and which way)
• about the number of handles and modules to be processed, and about the quantities processed so far (message about every 5000 processed handles)
• about whether the LockedList64.dll plugin was found or not and details of the process of working with it
• about frozen threads that had to be terminated
• about aborted search process in the user interface or canceling SilentSearch using a callback
• about unknown handle types
• about various errors that interfere with further work (memory allocation, exceeding the permissible buffer size, etc.)

By default, messages are translated to OutputDebugString.
The user can set his own callback (via LockedList::SetOutputDebugCallback) to receive all messages into his installer for subsequent logging or other processing.

[Nadahar]

I'm all for everything that improves debugging - NSIS is generally hard to debug. Things like this surely makes life easier in many circumstances.

What I'm thinking is that if we can find a way to enable the extra code only "on demand" (#ifdefs or some global state variable?) it could be a only positive with no "downside" when you don't need it, it would be great to just do a PR and get it into the "standard version". Do you have any ideas of how to best make it "on demand" only? (I'm not saying it's "expensive" as it is, but it's always nice to not do unnecessary operations)

[abzalov]

OK I understood. I'll do it through a global variable.
If the callback is not installed by NSIS script, then nothing will be done as before.
If the callback is installed, then messages will be output both to OutputDebugString and passed to the user function.

[Nadahar]

Yeah - that sounds like a good idea.