* Fix build with mingw
4a71cab2e7 broke wf_events.c.
The drive channel was not building because of missing definitions.
* winpr: make functions return False when not implemented
This patch improves waiting on process handles:
* under linux we take advantage of pidfd if available, when it can be used it
allows to have one or more process in the objects that are WaitForMultipleObject-ed.
* the patch also make the code honor the timeout parameter during a WaitForSingleObject and
possibly run completion when WaitForSingleObjectEx is executed with alertable set to true
* Fixed GetFileInformationByHandle initializers
* Fix#7793: Do not expose internal input API
Slow-Path input uses UINT16 for scancodes on wire, but only the
lower byte is actually used. (the extended fields are sent in
keyboardFlags field)
Hide this implementation detail and adjust the API to use UINT8
for the code instead just like the corresponding Fast-Path PDU
* Added a warning for problematic slow path keyCodes
* expose EnvironmentBlockToEnvpA
* cleanup includes in process.c
* removed unused "flag" variable in _CreateProcessExA
* make ProcessHandleCloseHandle static
When launching a new process stdin/stdout/stderr can be redirected by
passing the corresponding HANDLEs in the passed lpStartupInfo structure.
This is required for example if a pipe should be used as stdin/stdout.
If set in lpStartupInfo the file descriptor of the passed handle is
now used. The test was updated accordingly.
If SA_SIGINFO isn't set in the flags sa_handler is used
instead of sa_sigaction.
This fixes also the compiler warning:
FreeRDP/winpr/libwinpr/thread/process.c: In function ‘_CreateProcessExA’:
FreeRDP/winpr/libwinpr/thread/process.c:282:20: warning: assignment from
incompatible pointer type [enabled by default]
The calling thread of CreateProcess can be in any library and
can have arbitrary signal masks and handlers.
We now save the caller's mask and block all signals before forking.
After fork:
- child resets the handlers and unblocks all signals.
- parent restores the caller's original signal mask.
TerminateProcess shouldn't call kill if the PID is <=0 because this has
unwanted effects (and is not what TerminateProcess should do):
* with PID == 0 any process in the same process group gets the signal
sent
* with PID == -1 *every* processes that the running users has
permissions to gets the signal sent
* with PID < -1 the process within the same process group and -PID gets
the signal send
For more details see kill(2).
