udev_add_device declares a variable (product) even when it is not used
on all platforms. Use the same condition for the declaration that already
guards the code.
init_argv0_dir has conditional code for different operating systems. In
case of FreeBSD a variable remains uninitialized in the error case, yet
is then used. Fix that by handling the error case.
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>
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.
Revision 24b26f8bd6 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=54159
Signed-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=53456
Signed-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>
It looks like the behavior changes when only this test is run vs when it
is run as part of the winetest suite.
This is probably because ChangeDisplaySettingsExW only sends the message
the first time it is called (since boot?).
Having other tests run before it, one of them probably changed display
settings already and we're not getting the message anymore.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53894
