Prevents the common problem of injecting in to certain processes and
getting the hook DLL "stuck":
- windows explorer
- steam
- battle.net
- gog galaxy
- skype
- uplay
- origin
- microsoft visual studio
- task manager
- league of legends lobby window
- windows 10 system settings window
This reverts commit 8d520b970d.
This can actually cause a hard lock due to the windows API when
destroying window capture. When the graphics thread locks the source
list for doing tick or render, and then the UI thread tries to destroy a
source, the UI thread will wait for the graphics thread to complete
rendering/ticking of sources. The video_tick of window capture would
then check windows in the same process and try to query the window's
name via GetWindowText. However, GetWindowText is synchronous, and will
not return until the window event has been processed by the UI thread,
so it will perpetually lock because the two threads are waiting for each
other to finish.
If the PSAPI_VERSION macro is not set to 1 when using
GetProcessImageFileName, it will attempt to import it as
K32GetProcessImageFileName from kernel32.dll instead of psapi.dll, which
breaks compatibility with vista and xp.
This fixes a bug where if INCLUDE_MINIMIZED was set and the window size
was (0, 0), the window would still be excluded from the resulting list
that was created.
When getting the class/title/exe of a particular window handle in the
build_window_strings function, always set the class/title/exe pointers
to null to prevent any potential references to invalid values if any of
them do not happen to be set for whatever reason.
Because other capture methods may end up needing to share this code,
separate the window finding source code to window-helpers.c and
window-helpers.h.
This include a function to fill out a property list with windows, a
function to find a window based upon priority/title/class/exe, and a
function to decode the window title/class/exe strings from a window
setting string.
jp9000
Richard Stanway