Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53980

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

They will be reinterpreted by Unix tty, leading to wrong display.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

WriteConsole (not in processed mode) and WriteConsoleOutput* functions
allow to write control characters, which can then be read back as is.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Based on user32 WINPROC_CallProcWtoA.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53744

Fixes a regression introduced by
cbfe940a.

They fail on the Gitlab CI.

It fails on the Gitlab CI.

It fails on the Gitlab CI.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53595

Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=53525

They are now pretty much superseded by the more extensive tests in
joystick8.c, using virtual devices.

This was previously automatically done when user32 was loaded, but since
the move of __wine_send_input to win32u, we do not need to load it any
more. Make sure we have a desktop or WM_INPUT messages won't be sent by
wineserver.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53941

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53941

Revision 24b26f8b changed FreeBSD
(and DragonFly) not to use /proc any longer. Hence we also do not
need the exe_link variable on those two platforms, either. Avoid
declaring it there.

(This avoids a compiler warning with GCC 12.)

find_device_from_devnode was unnecessarily guarded by HAVE_SYS_INOTIFY_H,
alas its use in process_monitor_event was not, so linking failed. Simply
make find_device_from_devnode generally available.

Win10 and Win11 can have some variations in debug events order
(linked to when thread start debug event are generated).

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54159Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Even if there's a synchronisation mechanism between kernel32:debugger
and its children which ensures that child has finished writing to and
closed the blackbox logging file before reading it, there's no
guarantee that the file is not re-opened by another process: antivirus,
file indexing...
And according to [1], even the OS itself can still have opened references
to it.

So, always open/read the blackbox file in read share mode to work around
this issue.

Also, harden the code for potential errors, and be nicer in where
failures come from.

[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-cleanup

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53456Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Investigating the test failures in MR!1823, it turns out
that sometimes in Win7, at process exit, not all the dll unload
debug events are sent (in traces, only the last loaded dll gets the
event).
I don't know what it only shows now :-(, but that seems very
replicable (it happens every time with new job to TestBot).

So mark the case of missing unload dll debug event as broken
(still checking that the load dll debug event has been received).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>