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>

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

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

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

The RtlU*ByteSwap() family:
- has FASTCALL calling convention
- is only exported from ntdll and ntoskrnl.exe in 32bit mode
  (didn't check ARM though)

Wine's support for RtlUlonglongByteSwap() doesn't follow these constraints.
Note: in __fastcall, 64bit paramaters are passed on the stack, to
RtlUlonglongByteSwap() calling convention acts as __stdcall.

So:
- fix ntdll.spec (resp. ntoskrnl.exe.spec) to only export
  (resp. forward) RtlUlonglongByteSwap for i386
- always provide an inline implementation in winternl.h
- reimplement ntdll.RtlUlonglongByteSwap() for i386 with
  __fastcall calling convention.
- fix ntdll/tests/rtl.c to use correct calling convention.
- add test in ntdll/tests/rtl.c for inlined version.

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

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

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

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

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

Testing: kernel32:debugger, there's sometimes the following error:
debugger.c:1760: Test failed: unexpected instruction pointer 778B2A0C

Current test code has a workaround when this happens on last thread, but
this is clearly not sufficient.

Fix the test so that it grabs the thread context only in a place we're
sure it's in stopped state at breakpoint instruction.
(Current code likely catches cases where the thread is in bp signal
handling).

Rewrote the test to be in more logical order.

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

Signed-off-by: Fabian Maurer <dark.shadow4@web.de>