Except for nodes with custom properties, those still need more work on the infrastructure. jscript change is just minimum needed to allow objects with only builtin properties to preserve their current behavior, I have more tweaks for that area queued for "async" custom properties.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6092
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v7: odbc32: SQLError/W handle NULL handles
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v6: odbc32: SQLError/W handle NULL handles
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
Fixes Bug 23029 (Devil May Cry® 3 Special Edition) (6550) Intro Video is covered by green, transparent square for a majority of it.
Before these patches, surface data for planar formats is not copied
correctly when the application uses a custom allocator-presenter and
allocates a surface of different size than the VMR9 source.
Patch 2/2 adds support for performing this copy correctly when the
source dimensions are less or equal than the rendering surface
dimensions.
---
I have some questions:
- Should I also make it work for when the dst is smaller than the src?
- If not, should the FIXME() in 1/2 be promoted to an error? Otherwise we might have segfaults, writing out of scope.
- Should I use copy_plane(), introduced in 2/2 also in the implementation of the other formats? Changing what needs to be changed to preserve behavior of course.
--
v3: quartz: Properly copy data to render surfaces of planar formats in VMR9.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6069
This fixes various corner cases.
This is not motivated by any particular application. However, the server-side
code seems at least as simple as the existing client-side code, is more
accurate, and removes a potential source of complication from any future work
involving asyncs.
--
v3: server: Reimplement mailslots using server-side I/O.
server: Treat completion with error before async_handoff() as error.
kernel32/tests: Add more mailslot tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6045
Fixes Bug 23029 (Devil May Cry® 3 Special Edition) (6550) Intro Video is covered by green, transparent square for a majority of it.
Before these patches, surface data for planar formats is not copied
correctly when the application uses a custom allocator-presenter and
allocates a surface of different size than the VMR9 source.
Patch 2/2 adds support for performing this copy correctly when the
source dimensions are less or equal than the rendering surface
dimensions.
---
I have some questions:
- Should I also make it work for when the dst is smaller than the src?
- If not, should the FIXME() in 1/2 be promoted to an error? Otherwise we might have segfaults, writing out of scope.
- Should I use copy_plane(), introduced in 2/2 also in the implementation of the other formats? Changing what needs to be changed to preserve behavior of course.
--
v2: quartz: Properly copy data to render surfaces of planar formats in VMR9.
quartz: Emit FIXME when the rendering surface is smaller than the source in VMR9.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6069
The first two patches here address an issue I encountered when using Wine's d3dx9 with DXVK in the game Command and Conquer 3. The game calls `D3DXLoadSurfaceFromMemory` on a multisampled render target. This ends up going through the `lock_surface()` helper in d3dx9, which eventually calls `UpdateSurface()` in `unlock_surface()` to copy the staging surface back to the multisampled render target. This succeeds on wined3d even though it shouldn't, and fails on DXVK like it should.
The second two patches address an issue reported in Empires: Dawn of the Modern World, where the game expects a device reset to reset the scene state.
--
v2: wined3d: Clear scene state on device state reset.
d3d8/tests: Add a test for device reset after beginning a scene.
d3d9/tests: Add a test for device reset after beginning a scene.
ddraw/tests: Add tests for preserving d3d scene state during primary surface creation.
d3d9: Return failure if a multisampled surface is passed to IDirect3DDevice9::UpdateSurface().
d3d9/tests: Add tests for IDirect3DDevice9::UpdateSurface() with a multisampled surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6042
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v5: odbc32: SQLError/W handle NULL handles
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v4: odbc32: SQLError/W handle NULL handles
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
--
v7: user32/edit: Add some WM_ASKCBFORMATNAME tests.
user32/tests: Add tests for NULL strings with edit control GETTEXT message.
comctl32/tests: Add tests for NULL strings with edit control GETTEXT message.
user32: Fail on NULL string for edit control WM_GETTEXT message.
comctl32: Fail on NULL string for edit control WM_GETTEXT message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6004
--
v6: user32/edit: Add some WM_ASKCBFORMATNAME tests.
user32/tests: Add tests for NULL strings with edit control GETTEXT message.
comctl32/tests: Add tests for NULL strings with edit control GETTEXT message.
user32: Fail on NULL string for edit control WM_GETTEXT message.
comctl32: Fail on NULL string for edit control WM_GETTEXT message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6004
--
v5: user32/edit: Add some WM_ASKCBFORMATNAME tests.
comctl32/user32: Add tests for NULL strings with edit control GETTEXT message.
user32: Correctly handle NULL string in GETTEXT/CBFORMAT AtoW wrapper.
comctl32/user32: Fail on NULL string for edit control WM_GETTEXT message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6004
Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/listview.c:
> CoUninitialize();
> }
>
> +static void test_LVM_GETNEXTITEM(void)
Please add the tests first and put them in a separate commit. You can mark the tests that are failing on Wine with a todo_wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5909#note_76062
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v3: odbc32: SQLError handle NULL handles
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
Wine renamed the "Application Data" directory to "AppData" in commit
4111801ab31 ("shell32: Use winvista+ AppData paths.", 2021-05-27), so we
can use it for the temp directory now without having to worry about
spaces in the path.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6071
Fixes Bug 23029 (Devil May Cry® 3 Special Edition) (6550) Intro Video is covered by green, transparent square for a majority of it.
Before these patches, surface data for planar formats is not copied
correctly when the application uses a custom allocator-presenter and
allocates a surface of different size than the VMR9 source.
Patch 2/2 adds support for performing this copy correctly when the
source dimensions are less or equal than the rendering surface
dimensions.
---
I have some questions:
- Should I also make it work for when the dst is smaller than the src?
- If not, should the FIXME() in 1/2 be promoted to an error? Otherwise we might have segfaults, writing out of scope.
- Should I use copy_plane(), introduced in 2/2 also in the implementation of the other formats? Changing what needs to be changed to preserve behavior of course.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6069
The first two patches here address an issue I encountered when using Wine's d3dx9 with DXVK in the game Command and Conquer 3. The game calls `D3DXLoadSurfaceFromMemory` on a multisampled render target. This ends up going through the `lock_surface()` helper in d3dx9, which eventually calls `UpdateSurface()` in `unlock_surface()` to copy the staging surface back to the multisampled render target. This succeeds on wined3d even though it shouldn't, and fails on DXVK like it should.
The second two patches address an issue reported in Empires: Dawn of the Modern World, where the game expects a device reset to reset the scene state.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6042
The `-Wstringop-overread` fix feels a bit questionable (so I'll add Eric as a
reviewer to clarify the MSC structs details)
--
v4: winedump: Initialize size variable in dump_dir_exceptions().
winedump: Use offsetof() for string position calculations.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5625
GCC 14.1 emits a bunch of warning when compiling (winedump & dbghelp).
This stems from some of the structures attempting to reflect file
layout (after serialisation), whereas the variable length of
some contiguous fields make it impossible (in C).
So use flexible array members for variable length arrays,
and use an FAM as well for packing the more complicated bits.
This keeps these data blocks as C structures for the fields
that can be directly mapped, and leave to the caller the
responsability of deserializing the rest.
This seem to be enough to get rid of these GCC warnings.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6064
Fixed rotation of angles < 90deg in bus_sdl.
Align logical max of angles to physical max defined in dinput (35900). Before, a polar angle of eg 90deg would end up in bus_sdl/bus_udev as 90.25deg.
--
v4: winebus.sys: Align logical max of angles to physical max defined in dinput
winebus.sys: Fix rotation for angles < 90deg
https://gitlab.winehq.org/wine/wine/-/merge_requests/6043
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
v2:
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
--
v2: odbc32: Use SQLSetConnectAttrW() instead of SQLSetConnectAttr() if possible.
odbc32: Use SQLFreeHandle() instead of SQLFreeEnv/Connect().
odbc32: Set parent functions before creating the environment handle.
odbc32: Accept SQL_FETCH_NEXT in SQLDataSources/Drivers() if the key has not been opened.
odbc32: Factor out helpers to create driver environment and connection handles.
odbc32: Implement SQLGetInfo(SQL_ODBC_VER).
odbc32: Default to ODBC version 2.
odbc32: Handle options in SQLFreeStmt().
odbc32: Stub SQLGetEnvAttr(SQL_ATTR_CONNECTION_POOLING).
odbc32: Implement SQLGet/SetConnectAttr(SQL_ATTR_CONNECTION_TIMEOUT).
odbc32: Implement SQLGet/SetConnectAttr(SQL_ATTR_LOGIN_TIMEOUT).
https://gitlab.winehq.org/wine/wine/-/merge_requests/6050
Send INVALIDATEMEDIATYPE to allow the transform type to be set before
retrying PROCESSINPUTNOTIFY.
--
v2: mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned.
mf/tests: Add tests for custom evr presenter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6059
I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. First impressions are that games have become smoother, but need to think about tests that can actually be measured.
Before build need define `WINE_USE_ATOMIC_LOCKS`.
```bash
export CFLAGS="${CFLAGS} -DWINE_USE_ATOMIC_LOCKS"
```
--
v6: ws2_32: Add atomic lock support.
wine32u: Add atomic lock support.
winevulkan: Add atomic lock support.
ntdll: Add atomic lock support.
winewayland: Add atomic lock support.
include: Define custom mutex macroses.
msxml3: Fix compilation errors with Clang 18.
configure: Change C standard to C17.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6031
I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. First impressions are that games have become smoother, but need to think about tests that can actually be measured.
Before build need define `WINE_USE_ATOMIC_LOCKS`.
```bash
export CFLAGS="${CFLAGS} -DWINE_USE_ATOMIC_LOCKS"
```
--
v5: ws2_32: Add atomic lock support.
wine32u: Add atomic lock support.
winevulkan: Add atomic lock support.
ntdll: Add atomic lock support.
winewayland: Add atomic lock support.
include: Define custom mutex macroses.
msxml3: Fix compilation errors with Clang 18.
configure: Change C standard to C17.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6031
This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for
NtQuerySystemTime() if it has sufficient resolution.")
CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000.
OTOH, there are several ways to get up to 0.5ms resolution on modern
Windows (high resolution waitable timers, NtSetTimerResolution with
0.5ms). This code path therefore has a possibility of behaving worse
than native.
Since COARSE resolution is HZ dependent, this code path only runs if the
kernel is configured with CONFIG_HZ=1000. Most distro ships does not
ship with this. Therefore, this code path is rarely tested, and is more
of a recipe for surprise. If any application rely on fast
NtQuerySystemTime they are likely already broken for majority of Wine
users.
Given the above reason, don't use CLOCK_REALTIME_COARSE. Use
gettimeofday which is internally hooked to CLOCK_REALTIME.
--
v3: ntdll: Don't use CLOCK_REALTIME_COARSE
https://gitlab.winehq.org/wine/wine/-/merge_requests/6007
Apologies for it spamming the log. My intention was, as my comment describes, to be louder about cases where we're running out of memory. Often such allocation failures are indeed fatal, since many applications (and internal Wine code) does not expect them. I didn't intend for there to be, nor did I write, any requirements around the bits of address space. It raises the question for me of why we're trying to allocate memory that high if we know it's above the address limit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_75958
The handles returned by libproc (namely struct socket_info's soi_pcb)
use all 64 bits, but the ones from the pcblist sysctl are truncated
to 32. That makes find_owning_pid fail. The pcblist64 sysctl was
added in macOS 10.6 and returns handles that match those from
libproc.
--
There does not seem to be a MIB constant for the pcblist64 sysctls, so I'm caching the result of sysctlnametomib.
--
v5: nsiproxy.sys: Use the pcblist64 sysctl to enumerate UDP connections on macOS.
nsiproxy.sys: Use the pcblist64 sysctl to enumerate TCP connections on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6021
This is part XX of cmd engine rewrite.
It provides:
- a couple of more internal cleanups,
- avoids leaks on some error paths,
- fixes a couple of redirection related issues
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6057
This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for
NtQuerySystemTime() if it has sufficient resolution.")
CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000.
OTOH, there are several ways to get up to 0.5ms resolution on modern
Windows (high resolution waitable timers, NtSetTimerResolution with
0.5ms). This code path therefore has a possibility of behaving worse
than native.
Since COARSE resolution is HZ dependent, this code path only runs if the
kernel is configured with CONFIG_HZ=1000. Most distro ships does not
ship with this. Therefore, this code path is rarely tested, and is more
of a recipe for surprise. If any application rely on fast
NtQuerySystemTime they are likely already broken for majority of Wine
users.
Given the above reason, don't use CLOCK_REALTIME_COARSE. Use
gettimeofday which is internally hooked to CLOCK_REALTIME.
--
v2: ntdll: Don't use CLOCK_REALTIME_COARSE
https://gitlab.winehq.org/wine/wine/-/merge_requests/6007