Instead of manually specifying success or failure.
Based on test_return_status() in ntoskrnl. The changes in this patch don't
affect device IRPs, but the tests show the heuristic that Windows uses, and in
practice it turns out to be correct for all known asyncs.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Mostly just to simplify the interface, so that we don't need to use the return
value to communicate this.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Devices are only added from a single thread but they may be destroyed
concurrently so we need to guard the list against race conditions.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And name the callbacks a bit more consistently.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This internal xinput PDO is an HID compatible pass-through device, but
it needs to be kept private and is listed on the internal WINEXINPUT
device interface class, instead of the HID device interface class.
This is a Wine extension for convenience and native XInput driver uses a
different, undocumented, device interface.
We now filter the report read requests to make sure only one is sent
through to the lower bus device, and we complete both gamepad and xinput
read requests at once using the returned data.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Although these devices will be HID compatible we need to not have them
listed on the HID class, as they should only be used internally by Wine
XInput implementation.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So everything will be ready in the device fdo (or fail to start the
device entirely), when we need it later.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
use case, in a WoW setup:
wine programs/winedbg/winedbg.exe.so notepad.exe
where both winedbg and notepad are 64bit exec:s
in this case, dbghelp (loaded from winedbg) reads '<...>/wine' from WINELOADER
windows env block inside notepad
(but the unix env block is correctly set to wine64 by the tweak in
ntdll/unix/loader.c)
as a consequence dbghelp doesn't get the ELF information (it tries to read 32bit
ELF entities, and fails); hence misses all the loaded ELF libraries
winedbg's command 'info share' only reports the PE modules
note: the 'dual' case
wine64 programs/winedbg/winedbg.exe.so c:\\windows\\syswow64\\notepad.exe
where winedbg is a 64bit exec and notepad a 32bit
shows the same failures
workaround this in dbghelp by tweaking the value of WINELOADER whether
the debuggee is 32 or 64bit
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since with the unknown type entry, we can end up with types which don't
match the expected symt->tag, we need to check before the conversions.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The 32bit CIE_ID is an unsigned integer (will become important when
handling 32 vs 64 bit values).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
DW_FORM_ref_udata value is an offset from current unit (as the others
DW_FORM_ref[1,2,3,4] are)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Esme Povirk