- 24 Nov, 2021 35 commits
-
-
Rémi Bernon authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52062Signed-off-by:
Rémi Bernon <rbernon@codeweavers.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Rémi Bernon authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52062Signed-off-by:
-
Rémi Bernon authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52062Signed-off-by:
-
Gabriel Ivăncescu authored
Signed-off-by:
Gabriel Ivăncescu <gabrielopcode@gmail.com> Signed-off-by:
Jacek Caban <jacek@codeweavers.com> Signed-off-by:
-
Gabriel Ivăncescu authored
Signed-off-by:
-
Gabriel Ivăncescu authored
Signed-off-by:
-
Gabriel Ivăncescu authored
IDX props are not configurable, thus they cannot be deleted, so it makes no sense to special-case them anyway. Signed-off-by:
-
Gabriel Ivăncescu authored
Signed-off-by:
-
Gabriel Ivăncescu authored
Convert them to PROP_DELETE if the referenced prop in the prototype chain doesn't exist anymore. Signed-off-by:
-
Gabriel Ivăncescu authored
Delete only affects own properties. Signed-off-by:
-
Huw Davies authored
This makes winecoreaudio consistent with the other midi drivers. Signed-off-by:
Huw Davies <huw@codeweavers.com> Signed-off-by:
Andrew Eikum <aeikum@codeweavers.com> Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
The session setvol helper has been removed to reduce the number of helper functions as the loop over the session's clients isn't very complicated. Session mute is handled by setting the master volume to zero. Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
The capture_resample syscall can now be removed. Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
This fixes an error introduced in 8e90b256 which was incorrectly fixed in b5b77ed6. Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
This has been broken at least since 19549d11. Signed-off-by:
-
Paul Gofman authored
Signed-off-by:
Paul Gofman <pgofman@codeweavers.com> Signed-off-by:
-
Zebediah Figura authored
Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
Henri Verbeet <hverbeet@codeweavers.com> Signed-off-by:
-
Henri Verbeet authored
Fixes: c2f0ae50Signed-off-by:
-
Henri Verbeet authored
Signed-off-by:
-
Zebediah Figura authored
That is, load Wine system dependencies only when they are imported from Wine builtins or other system dependencies, and do not match a Wine system dependency by its base name when looking for already-loaded modules. The reasoning is that it is possible for an application to ship, and expect to use, a newer version of a MinGW-compiled library, or one with custom patches, or possibly an unrelated library with the same name. We don't want to offer Wine's system dependencies in place of the application's, or vice versa. Signed-off-by:
-
Zebediah Figura authored
Many distributions provide MinGW-compiled system DLLs which are currently bundled with Wine. Unfortunately, while MinGW pkg-config can be used to detect the linking path, there is no standardized runtime path, and many distributions in fact use different paths. Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Connor McAdams authored
Signed-off-by:
Connor McAdams <cmcadams@codeweavers.com> Signed-off-by:
-
Connor McAdams authored
Signed-off-by:
-
Thomas Faber authored
Signed-off-by:
Thomas Faber <thomas.faber@reactos.org> Signed-off-by:
-
- 23 Nov, 2021 5 commits
-
-
Esme Povirk authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51989Signed-off-by:
Esme Povirk <esme@codeweavers.com> Signed-off-by:
-
Georg Lehmann authored
Signed-off-by:
Georg Lehmann <dadschoorse@gmail.com> Signed-off-by:
-
Daniel Lehman authored
Fixes loading XML from a UNC path. Signed-off-by:
Daniel Lehman <dlehman@esri.com> Signed-off-by:
-
Jinoh Kang authored
Today, when gdbproxy is started with --no-start mode, GDB fails to recognise the symbol file unless the `file` command or the `sharedlibrary` command is explicitly issued. Also, RHEL's downstream GDB complains with the following message: Remote gdbserver does not support determining executable automatically. RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection. The following versions of gdbserver support it: - Upstream version of gdbserver (unsupported) 7.10 or later - Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64) - RHEL-7.3 versions of gdbserver (on any architecture) Fix this by implementing the qXfer object "exec-file". Signed-off-by:
Jinoh Kang <jinoh.kang.kr@gmail.com> Signed-off-by:
-
Jinoh Kang authored
GDB does not retrieve the result of a qXfer command at once; instead, it issues a series of requests to obtain the result one "chunk" at a time, and concatenates those chunks internally. Each request contains offset and length variables that specify which portion of the result shall be retrieved. Today, Winedbg handles this by generating the entire result data each time a request is received and slicing out the requested range for the response. This is not only inefficient due to repeated computation, but also prone to race condition since the result may change between successive chunk requests due to the dynamic nature of some commands such as "libraries" and "threads." Fix this by cacheing the result into a buffer at the first request, and use the buffer to serve successive chunk requests. The cache is invalidated when the remote requests a different object, or the debugger reaches the end of the result cache buffer. Signed-off-by:
-
