The listview bug is caused by passing the incorrect index to the LISTVIEW_SortItems callers custom compare function. If we pass the copied array indices, which are different because of the sorting, the caller is going to use those indices for their unsorted array which don't match.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56140
--
v4: comctl32: Fix sorting for listview.
comctl32/tests: Add test for listview sorting order.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6160
Send INVALIDATEMEDIATYPE to allow the transform type to be set before
retrying PROCESSINPUTNOTIFY.
--
v3: 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
The listview bug is caused by passing the incorrect index to the LISTVIEW_SortItems callers custom compare function. If we pass the copied array indices, which are different because of the sorting, the caller is going to use those indices for their unsorted array which don't match.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56140
--
v3: comctl32: Fix sorting for listview.
comctl32/tests: Add test for listview sorting order.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6160
The listview bug is caused by passing the incorrect index to the LISTVIEW_SortItems callers custom compare function. If we pass the copied array indices, which are different because of the sorting, the caller is going to use those indices for their unsorted array which don't match.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56140
--
v2: comctl32: Fix sorting for listview.
comctl32/tests: Add test for listview sorting order.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6160
Fixes bug 54861. The UK Kalender program was crashing when a new event was created as stated in the bug report. The fix is to create all the property sheet pages from the beginning instead of when they are selected.
--
v2: comctl32: Create all prop sheet pages on initialization.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6146
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v5: remove is_dynamic_env_var(...) because it is not needed anymore
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v3: Release 9.14.
opengl32: Fix match criteria for WGL_DRAW_TO_PBUFFER_ARB.
winex11: Query proper GLX attribute for pbuffer bit.
gdiplus: Fixed order of adding offset and result ternary operator.
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/6166
This lists all fields of the `struct fd_ops` when object of that type --
`handler_fd_ops` in server/signal.c -- is being initialized.
It looks like field list in initialization of the `handler_fd_ops` in
server/signal.c was out-of-sync for a long time. Take a look, for
example, on patches ad1e0609a0f (server: Get rid of no loner used
cancel_async from fd_ops., 2016-12-01) (which removed "reference" to the
`cancel_async` field correctly, but did not add "references" to the `read`
and `write` fields, for example), or 837b39b2028 (server: Add read and
write fd member functions., 2015-05-05) (which updated `struct fd_ops`
but did not change initialization of the `handler_fd_ops` at all).
Because the main purpose of initialization of the `handler_fd_ops` made in
server/signal.c is to assign address of the `handler_poll_event()`
function to the `poll_event` field, while making all other fields `NULL`ed,
lacking some fields in that initialization is not an error according to
C standard:
> 6.7.11 Initialization
>
> 11 ... If an object that has static or thread storage duration is not
> initialized explicitly, or any object is initialized with an empty
> initializer, then it is subject to default initialization, which
> initializes an object as follows:
>
> - if it has pointer type, it is initialized to a null pointer;
>
> ...
>
> 22 If there are fewer initializers in a brace-enclosed list than there
> are elements or members of an aggregate, or fewer characters in a
> string literal used to initialize an array of known size than there
> are elements in the array, the remainder of the aggregate is subject
> to default initialization.
But to maintain code consistency I believe initialization of the
`handler_fd_ops` object should enumerate all fields of the
`struct fd_ops` type.
No functional changes intended.
```shell
$ ./configure
...
$ make
...
$ ./wine --version
wine-9.6-74-g6a1dab2af04
```
--
v27: Fix initialization of the msg_queue_fd_ops
Fix initialization of the process_fd_ops
Fix initialization of the thread_fd_ops
Fix initialization of the inotify_fd_ops
Fix initialization of the master_socket_fd_ops
Fix initialization of the handler_fd_ops
https://gitlab.winehq.org/wine/wine/-/merge_requests/5503
Based on patch by Gabriel Ivăncescu.
The part allowing properties to disappear as part of enumeration (as well as similar changes from previous MR) is not quite optimal. I think we will want to avoid it once host prototypes are supported.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6167
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v2: remove unused vars
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
without freetype, some calling return failed, so some value may not be initialized (it initialize by some failed calling and pass argument by point of it), it would cause random crash!
Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn>
--
v6: win32u: fix random crash without libfreetype
https://gitlab.winehq.org/wine/wine/-/merge_requests/5957
We can't return the unicode string size, this returns sizes to small
for multi-byte characters.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54295
--
v9: userenv: Fix GetProfilesDirectoryA return value
kernel32: Rework ExpandEnvironmentStringsA to return ansi size and fix corner cases.
kernel32: Rework ExpandEnvironmentStringsW error handling.
ntdll: Rework RtlExpandEnvironmentStrings/_U to account for corner cases.
kernel32: Add ExpandEnvironmentStringsA tests for japanese.
kernel32: Add more tests for ExpandEnvironmentStringsA.
kernel32: Add tests for ExpandEnvironmentStringsW.
ntdll: Add more tests for RtlExpandEnvironmentStrings/_U.
userenv: Add another test for GetProfilesDirectoryA
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en…
Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes.
With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded.
This is useful when a user has very long environment variables in their system for reasons unrelated to Wine.
Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941
Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6140
We can't return the unicode string size, this returns sizes to small
for multi-byte characters.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54295
--
v7: kernel32: Rework ExpandEnvironmentStringsA to return ansi size and fix corner cases.
kernel32: Rework ExpandEnvironmentStringsW error handling.
ntdll: Rework RtlExpandEnvironmentStrings/_U to account for corner cases.
kernel32: Add ExpandEnvironmentStringsA tests for japanese.
kernel32: Add more tests for ExpandEnvironmentStringsA.
kernel32: Add tests for ExpandEnvironmentStringsW.
ntdll: Add more tests for RtlExpandEnvironmentStrings/_U.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045
Fabian Maurer (@DarkShadow44) commented about dlls/win32u/sysparams.c:
> 'r','s','t','u','v','w','x','y','z','A','B','C','D','E','F','G','H',
> 'I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z'};
>
> - if (metric && !NtGdiGetTextMetricsW( hdc, metric, 0 )) return 0;
> + if (metric && !NtGdiGetTextMetricsW( hdc, metric, 0 )) goto fail;
>
> if (!NtGdiGetTextExtentExW( hdc, abcdW, ARRAYSIZE(abcdW), 0, NULL, NULL, &sz, 0 ))
> - return 0;
> + goto fail;
>
> if (height) *height = sz.cy;
> return (sz.cx / 26 + 1) / 2;
> +fail:
> + if (height) *height = 1;
> + return 0;
Just curious, but why `1`?
Also, wouldn't it be easier to have `if (height) *height = 1;` at the beginning of the function? Then you could keep the rest the same. And maybe that function could zero the `metrics` as well? Not sure where it would be required, I find a setup without freetype strange to begin with.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5957#note_77190
clang will default to the host if no target is specified, which causes
compile test failures if arch-specific CFLAGS are used for a non-host
arch.
--
v4: configure: Test PE compilers after setting their target argument.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5586
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.
--
v6: nsiproxy.sys: Use the pcblist64 sysctl to enumerate UDP connections on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6021
On Fri Jul 26 15:36:35 2024 +0000, Fan WenJie wrote:
> test-linux-32 always failed, can you see the reason for the failure?
Just open [it](https://gitlab.winehq.org/fanwenjie/wine/-/jobs/89772) and scroll around until you find a colored block, then look for red lines in that block.
If it has nothing to do with your changes (for example because it's about sockets or batch files), then it's broken on master too, and is someone else's problem. Just ignore it, it won't block merging. Don't rerun it, it'll just fail again.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77150
On Fri Jul 26 10:09:51 2024 +0000, Rémi Bernon wrote:
> Fwiw, on Windows, all desktops are of the same size, which only depends
> on the set of monitors which are plugged in.
> IMO we should implement support for multiple virtual monitors, rather
> than going back to the old virtual desktop logic.
desktop is not equals to monitor, currently wine supports multiply desktops (mutiply host window) on a virtual monitor. only need one virtual monitor because it is only a virtual device.
In virtual desktop mode
desktop = host platform window
virtual monitor=dummy host monitor device
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77129
Fwiw, on Windows, all desktops are of the same size, which only depends on the set of monitors which are plugged in.
IMO we should implement support for multiple virtual monitors, rather than going back to the old virtual desktop logic.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77123
You can add Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56993 at the end of your commit message body.
Also, the wrong commit is b86cc9e6, not fecfb442
```
(b86cc9e6589...)|BISECTING:wine/win32-build$ git bisect bad
b86cc9e658959cee47e6e587fec4f7c26350ed76 is the first bad commit
commit b86cc9e658959cee47e6e587fec4f7c26350ed76
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Tue Feb 13 15:05:37 2024 +0100
winex11: Let win32u decide when to force update the display cache.
dlls/winex11.drv/window.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77120
Zhiyi Zhang (@zhiyi) commented about dlls/win32u/sysparams.c:
> struct monitor *monitor;
> struct gpu *gpu;
>
> - if (list_head( &monitors ) == &virtual_monitor.entry)
Please don't add irrelevant changes in the same commit. If you want to fix explorer.exe not starting up with a user-specified resolution, focus on that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77119
Adding PSN_QUERYINITIALFOCUS helped fix some focus issues with the property sheet in bug 54862. Previously the listview in the tab control did not get focus from the start when it should have.
--
v4: comctl32/tests: Add test for PSN_QUERYINITIALFOCUS for the propsheet.
comctl32: Add handling for PSN_QUERYINITIALFOCUS in prop.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6145
On Thu Jul 25 23:39:50 2024 +0000, Fabian Maurer wrote:
> Why do you remove all that virtual source logic? I mean, I'm not an
> export, but it looks off.
virtual_source should remove,2 reason
in function is_monitor_active
`
static BOOL is_monitor_active( struct monitor *monitor ) { struct source *source; /* services do not have any adapters, only a virtual monitor */ if (!(source = monitor->source)) return TRUE; if (!(source->state_flags & DISPLAY_DEVICE_ATTACHED_TO_DESKTOP)) return FALSE; return !IsRectEmpty( &monitor->rc_monitor ); }
`
virual_monitor do not need source.
virtual monitor is a temporary setting,should not write registry, It is a feature only for wine, so have no effect for global setting.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6150#note_77094
Example with gcc and -O3 maximum optimization flag.
Before:

After:

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6159
Example my assembly with gcc -02 flag
Before:

After:

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6158
Adding PSN_QUERYINITIALFOCUS helped fix some focus issues with the property sheet in bug 54862. Previously the listview in the tab control did not get focus from the start when it should have.
--
v3: comctl32/tests: Add test for PSN_QUERYINITIALFOCUS for the propsheet.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6145
Adding PSN_QUERYINITIALFOCUS helped fix some focus issues with the property sheet in bug 54862. Previously the listview in the tab control did not get focus from the start when it should have.
--
v2: comctl32/tests: Add test for PSN_QUERYINITIALFOCUS for the propsheet.
comctl32: Add handling for PSN_QUERYINITIALFOCUS in prop.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6145
On Wed Jul 24 16:08:05 2024 +0000, Elizabeth Figura wrote:
> Gitlab seems to claim that when it's actually not true, unfortunately. I
> don't know if there's anything we can do about it.
> I don't think merge requests need to be rebased unless there are
> actually merge conflicts.
I see, thanks for letting me know about that!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6133#note_76955
On Wed Jul 24 10:05:49 2024 +0000, Đorđe Mančić wrote:
> My bad, sorry. I'm new to contributing to Wine and the GitLab site said
> that the merge request can't be approved if I don't rebase, so that's
> why I did it.
Gitlab seems to claim that when it's actually not true, unfortunately. I don't know if there's anything we can do about it.
I don't think merge requests need to be rebased unless there are actually merge conflicts.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6133#note_76952
On Wed Jul 24 10:05:49 2024 +0000, Fabian Maurer wrote:
> FWIW, I don't think you need to rebase it, unless there is conflicts.
My bad, sorry. I'm new to contributing to Wine and the GitLab site said that the merge request can't be approved if I don't rebase, so that's why I did it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6133#note_76935
Also some patches to address comments made on the last MR. :)
--
v2: d3dx9: Add support for loading non-square cubemap DDS files into cube textures.
d3dx9: Add support for specifying which array layer to get pixel data from to d3dx_image_get_pixels().
d3dx9: Use d3dx_image structure inside of D3DXCreateCubeTextureFromFileInMemoryEx().
d3dx9: Cleanup texture value argument handling in D3DXCreateCubeTextureFromFileInMemoryEx().
d3dx9: Refactor texture creation and cleanup in D3DXCreateCubeTextureFromFileInMemoryEx().
d3dx9/tests: Add more D3DXCreateCubeTextureFromFileInMemory{Ex}() tests.
d3dx9/tests: Reorder test structure members.
d3dx9/tests: Make some test structures static const.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6040