Esme Povirk (@madewokherd) commented about dlls/comdlg32/navbar.c:
> hwnd, 0, COMDLG32_hInstance, NULL);
> SetWindowSubclass(info->background_hwnd, NAVBAR_BACKGROUND_SubclassProc, 0, (DWORD_PTR)info);
>
> + info->overflow_hwnd = CreateWindowExW(0, WC_BUTTONW, NULL,
For accessibility it'd be good to give this button a title.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857#note_20177
Esme Povirk (@madewokherd) commented about dlls/comdlg32/navbar.c:
> while (ILRemoveLastID(pidl));
> ILFree(pidl);
>
> + NAVBAR_OVERFLOW_Clear(info);
> +
> + /* move the first crumb to overflow menu, if there are at least 2 crumbs */
> + crumb1 = LIST_ENTRY(list_head(&new_crumbs), struct crumb, entry);
> + if (crumb1 && crumb1->entry.next != &new_crumbs)
> + {
> + NAVBAR_OVERFLOW_Insert(info, crumb1->pidl, crumb1->display_name);
> + DestroyWindow(crumb1->hwnd);
> +
> + list_remove(&crumb1->entry);
I think removing items from the list like this is confusing. It also results in the need for a special case "preserving" the first crumb in the layout code.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857#note_20178
Esme Povirk (@madewokherd) commented about dlls/comdlg32/navbar.c:
> + menu_item.hbmpItem = HBMMENU_CALLBACK; /* see NAVBAR_OVERFLOW_DrawIcon */
> +
> + InsertMenuItemW(info->overflow_menu, -1, TRUE, &menu_item);
> +}
> +
> +static void NAVBAR_OVERFLOW_Clear(NAVBAR_INFO *info)
> +{
> + INT i, menu_item_count = GetMenuItemCount(info->overflow_menu);
> + MENUITEMINFOW menu_item = {0};
> +
> + menu_item.cbSize = sizeof(MENUITEMINFOW);
> + menu_item.fMask = MIIM_DATA;
> +
> + for (i = 0; i < menu_item_count; i++)
> + {
> + /* deleting an item shifts further indices, so don't use `i` */
It would probably be simpler to delete the items from the end, and slightly more efficient because it removes the need to shift indices.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857#note_20175
Implements navigation bar featuring:
- back/forward buttons
- go up button
- address crumbs
- hides crumbs when there's not enough space to display all of them
- always shows at least 2 crumbs
- truncating them if needed
- first crumb is at least 56px
- aligns label to the left if truncated
- right clicking on the crumb, or free space, opens a menu with `Copy address as text` and `Edit address` options
- reuses existing crumbs to avoid some flickering
- overflow menu
- first crumb is always moved here
- removes the split, if there are no items in the menu
- hidden crumbs are moved here
- left or right click on the button starts address editing
- address edit
- accepts an existing path
- expands environment variables, e.g. `%APPDATA%\Microsoft` -> `C:\users\%USERNAME%\AppData\Roaming\Microsoft`
- errors with a `MessageBox` on nonexistent paths
- refresh button
- changes into go to button when editing address
- DPI scaling
Screenshots:






Remaining issues:
- crumbs not lighting up when hovered sometimes
- can be observed in current file dialog, hovering over dropdown arrow of a file type fixes it for a moment
- crumbs flickering on address change sometimes
- mostly when there's not enough space to display all of them
- `DeferWindowPos` doesn't seem to be atomic in Wine, presumably is in native Windows?
- unexpected address conversion for some PIDLs
- e.g. `Desktop` -> `C:\users\%USERNAME%\Desktop`, which is an entirely different location
- or `My Computer` into an empty string
- known folders are not handled by address edit, e.g. `Desktop`, `My Computer`
- icons are not DPI scaled
- while writing this:
```
0024:fixme:bitmap:NtGdiCreateBitmap planes = 0
0024:err:system:user_check_not_lock BUG: holding USER lock
wine/dlls/win32u/sysparams.c:396: user_check_not_lock: Assertion `0' failed.
wine: Assertion failed at address F7FF8549 (thread 0024), starting debugger...
```
- can't reproduce, happened when clicking on an item in overflow menu
- race condition? cosmic ray?
Addresses following bugs:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=50338
- https://bugs.winehq.org/show_bug.cgi?id=51855 (partially? no search box)
--
v3: comdlg32: Add refresh/go to button to IFileDialog navigation bar.
comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add breadcrumb overflow menu to IFileDialog navigation bar.
comdlg32: Add address breadcrumbs to IFileDialog navigation bar.
comdlg32: Add go up button to IFileDialog navigation bar.
comdlg32: Add IFileDialog navigation bar.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857
Implements navigation bar featuring:
- back/forward buttons
- go up button
- address crumbs
- hides crumbs when there's not enough space to display all of them
- always shows at least 2 crumbs
- truncating them if needed
- first crumb is at least 56px
- aligns label to the left if truncated
- right clicking on the crumb, or free space, opens a menu with `Copy address as text` and `Edit address` options
- reuses existing crumbs to avoid some flickering
- overflow menu
- first crumb is always moved here
- removes the split, if there are no items in the menu
- hidden crumbs are moved here
- left or right click on the button starts address editing
- address edit
- accepts an existing path
- expands environment variables, e.g. `%APPDATA%\Microsoft` -> `C:\users\%USERNAME%\AppData\Roaming\Microsoft`
- errors with a `MessageBox` on nonexistent paths
- refresh button
- changes into go to button when editing address
- DPI scaling
Screenshots:






Remaining issues:
- crumbs not lighting up when hovered sometimes
- can be observed in current file dialog, hovering over dropdown arrow of a file type fixes it for a moment
- crumbs flickering on address change sometimes
- mostly when there's not enough space to display all of them
- `DeferWindowPos` doesn't seem to be atomic in Wine, presumably is in native Windows?
- unexpected address conversion for some PIDLs
- e.g. `Desktop` -> `C:\users\%USERNAME%\Desktop`, which is an entirely different location
- or `My Computer` into an empty string
- known folders are not handled by address edit, e.g. `Desktop`, `My Computer`
- icons are not DPI scaled
- while writing this:
```
0024:fixme:bitmap:NtGdiCreateBitmap planes = 0
0024:err:system:user_check_not_lock BUG: holding USER lock
wine/dlls/win32u/sysparams.c:396: user_check_not_lock: Assertion `0' failed.
wine: Assertion failed at address F7FF8549 (thread 0024), starting debugger...
```
- can't reproduce, happened when clicking on an item in overflow menu
- race condition? cosmic ray?
Addresses following bugs:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=50338
- https://bugs.winehq.org/show_bug.cgi?id=51855 (partially? no search box)
--
v2: comdlg32: Add refresh/go to button to IFileDialog navigation bar.
comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add breadcrumb overflow menu to IFileDialog navigation bar.
comdlg32: Add address breadcrumbs to IFileDialog navigation bar.
comdlg32: Add go up button to IFileDialog navigation bar.
comdlg32: Add IFileDialog navigation bar.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857
Implements navigation bar featuring:
- back/forward buttons
- go up button
- address crumbs
- hides crumbs when there's not enough space to display all of them
- always shows at least 2 crumbs
- truncating them if needed
- first crumb is at least 56px
- aligns label to the left if truncated
- right clicking on the crumb, or free space, opens a menu with `Copy address as text` and `Edit address` options
- reuses existing crumbs to avoid some flickering
- overflow menu
- first crumb is always moved here
- removes the split, if there are no items in the menu
- hidden crumbs are moved here
- left or right click on the button starts address editing
- address edit
- accepts an existing path
- expands environment variables, e.g. `%APPDATA%\Microsoft` -> `C:\users\%USERNAME%\AppData\Roaming\Microsoft`
- errors with a `MessageBox` on nonexistent paths
- refresh button
- changes into go to button when editing address
- DPI scaling
Screenshots:






Remaining issues:
- crumbs not lighting up when hovered sometimes
- can be observed in current file dialog, hovering over dropdown arrow of a file type fixes it for a moment
- crumbs flickering on address change sometimes
- mostly when there's not enough space to display all of them
- `DeferWindowPos` doesn't seem to be atomic in Wine, presumably is in native Windows?
- unexpected address conversion for some PIDLs
- e.g. `Desktop` -> `C:\users\%USERNAME%\Desktop`, which is an entirely different location
- or `My Computer` into an empty string
- known folders are not handled by address edit, e.g. `Desktop`, `My Computer`
- icons are not DPI scaled
- while writing this:
```
0024:fixme:bitmap:NtGdiCreateBitmap planes = 0
0024:err:system:user_check_not_lock BUG: holding USER lock
wine/dlls/win32u/sysparams.c:396: user_check_not_lock: Assertion `0' failed.
wine: Assertion failed at address F7FF8549 (thread 0024), starting debugger...
```
- can't reproduce, happened when clicking on an item in overflow menu
- race condition? cosmic ray?
Addresses following bugs:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=50338
- https://bugs.winehq.org/show_bug.cgi?id=51855 (partially? no search box)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857
This series tries to fix WM_PASTE tests error on edit control (both user32 & comctl32).
The test failures where systematic on a local Win10 for comctl32 (yet very rare on
user32, perhaps one in 20 runs).
Since the failures are not systematic, it ought to be a synchronisation / timing
issue.
Flushing the msg queue before starting the paste test cycle seems to fix the issue.
- 0 occurence on comctl32 and user32 in 50 run (local VM)
- 0 occurence on Testbot (comctl32) in 1 run.
It's hard to be fully conclusive about bug resolution, but it's at least a step into
the right direction.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1886
Starting with Win10, height of multiline edit controls no longer seems
to be hardwired to a multiple of the font height (when larger than
font height).
- Adapt the tests accordingly (detecting how to compute the expected
height of a control).
- Extend the ranges of the tested heights.
Note:
- there may be another way to detect the model for height computation.
- the range of heights tested stem from internal testing and is larger
than existing testing. It could be reduced as a range, or picking
values from a fixed set of values (if needed).
Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=52152
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
v2: comctl32/test: Adapt the edit tests for height to Win10+.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1881
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v17: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
On Windows, application-specific settings are stored in the registry
under HKCU\\Console\\<path_to_app>.
Our implementation of conhost.exe does not know which process is
connected to it, so we need to get the full process image name before
loading any application-specific console settings.
To do this, we extend the server protocol to pass the process Id of
the connected console process to conhost.exe.
Please run tools/make_requests before merging.
--
v4: conhost: Load/Save console settings using the process path or window title
https://gitlab.winehq.org/wine/wine/-/merge_requests/1492
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53863
This fixes a regression introduced by ebbcc10b0593948657b8e684c3a9be8ace1a5d25.
Prior to that commit, buffers which were not CPU-accessible would not have the
WINED3D_BUFFER_USE_BO flag set, and accordingly
buffer_resource_sub_resource_map() would simply return the SYSMEM location,
ignoring the DISCARD and NOOVERWRITE flags.
However, the "accelerated" path in wined3d_cs_map_upload_bo() only checks for
the DISCARD flag, assuming that it is only set for dynamic GPU-accessible
buffers, and would subsequently try to allocate non-mappable memory and then map
it.
This commit avoids the accelerated path for such buffers, once again matching
our old behaviour. According to [1], this also matches Windows: DISCARD on
SYSTEMMEM buffers is ignored on both AMD and NVidia, and NOOVERWRITE is ignored
on NVidia (but not AMD).
[1] https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messa…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1864
--
v3: wined3d: Load and invalidate every mipmap level when mapping the top mipmap level.
d3d8/tests: Test uploading the whole mipmap chain in one map.
d3d9/tests: Test uploading the whole mipmap chain in one map.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1865
DISCARD maps on deferred contexts do not seem to offer the same synchronization
guarantees as do DISCARD maps on the immediate context, at least not with
respect to subsequent NOOVERWRITE maps on the immediate context. This is not
particularly surprising, seeing as it is probably far more usual to only map a
resource on one kind of context or the other.
The test currently fails on Windows 11 on NVidia drivers, but it also fails on
Mesa, for what I think are the same reasons.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52563
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54023
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1863
Starting with Win10, height of multiline edit controls no longer seems
to be hardwired to a multiple of the font height (when larger than
font height).
- Adapt the tests accordingly (detecting how to compute the expected
height of a control).
- Extend the ranges of the tested heights.
Note:
- there may be another way to detect the model for height computation.
- the range of heights tested stem from internal testing and is larger
than existing testing. It could be reduced as a range, or picking
values from a fixed set of values (if needed).
Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=52152
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1881
Depending on the theme, if there was a header,
the border ends up painted lower than it should be,
and clipped by the header.
7-Zip file manager, the reason why the offset was added in 5f0dcf79185941c4faff35d1cc9c758160f3a27d in the first place, still renders correctly.
Before:

After:

EDIT1:
Actually compared screenshots of 7-Zip file manager and looks like the headers are now painted consistently after highlighting them.


--
v2: comctl32/listview: Exclude header area in WM_NCPAINT.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1878
When `import_dll` function gets `STATUS_DLL_NOT_FOUND` from `load_dll()`, it has no way of distinguishing whether it's a dependency for the dll wasn't found, or the dll itself is missing.
That results in confusing ERR messages, where a dll is found, but wine
claims it isn't. Fix this by moving the print to the actual place that
is aware of whether it's the parent or the child dll haven't been found.
Log before:
0024:err:module:import_dll Library lib2.dll (which is needed by L"Z:\\tmp\\lib1.dll") not found
0024:err:module:import_dll Library lib1.dll (which is needed by L"Z:\\tmp\\a.exe") not found
Log after:
0024:err:module:load_dll Library L"lib2.dll" (which is needed by L"Z:\\tmp\\foo\\lib1.dll") not found
0024:err:module:import_dll Loading library lib2.dll (which is needed by L"Z:\\tmp\\foo\\lib1.dll") failed (error c0000135).
0024:err:module:import_dll Loading library lib1.dll (which is needed by L"Z:\\tmp\\foo\\a.exe") failed (error c0000135).
--------
While it's just about prints, but it costed me hours of wandering *(because if I know where to find the dependency dll, but I see that the main dll is also "not found" despite being "right there", I have to research the latter problem that looks more complicated. But given enough resources applied, it then turns out to be a faux)*.
As a fun fact, I am apparently not the only one to have stumbled upon. Here's a screenshot of a `#english` chat where I asked about a commit title correctness. It's the last place where you'd expect to find someone familiar with WINE, and yet here's a person that had to deal with that exact error as well:

So, I think it's kinda serious problem.
--
v3: ntdll: don't claim to have not found a library that is in place
https://gitlab.winehq.org/wine/wine/-/merge_requests/1166
Although the test has never been observed to fail on Windows, I think the
failure is genuinely a race in the test.
File handles (like events) are signaled in order to mark that an I/O operation
has completed. In this case the I/O operation includes manipulating data on both
ends of the pipe, and as part of that may signal the other end. Internally,
however, the file handle must logically happen *after* all of this processing
has taken place, not least because (given the Windows I/O architecture) it is
the job of the I/O manager, not the IRP handler.
Since the purpose of the test is probably just to check that the file handle
will be signaled after a synchronous I/O operation has completed, we may as well
check it from the client thread, after we know for sure that it has.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=54078
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1879
When an upstream node has not given enough samples to the transform,
we need to request more samples from it to avoid stalling the
pipeline.
This fixes an issue where the intro audio of the game Airborne Kingdom stops playing after a few seconds.
--
v2: mf: Request more samples for transforms when needed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1853
Depending on the theme, if there was a header,
the border ends up painted lower than it should be,
and clipped by the header.
7-Zip file manager, the reason why the offset was added in 5f0dcf79185941c4faff35d1cc9c758160f3a27d in the first place, still renders correctly.
Before:

After:

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1878
The check was dropped in e392e0ac2846edc25610723c19d6a796372017e1, leaving the dwFlags variable unused.
I have no idea if it was indeed unnecessary or if it was dropped by mistake but either we need to keep the check, or we should remove the variable.
--
v2: winex11: Check pixel format flags in X11DRV_wglChoosePixelFormatARB.
opengl32/tests: Test wglChoosePixelFormatARB flags filters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1828
We get conhost.exe:tty failures on testbot:
- not for version prior to w1064v1909 (these tests require
pseudo-consoles, which are not implemented in these Windows
version).
- for w1064v1909
- not for W10 versions after w1064v1909.
So, we assume that pseudo-console support is immature in this
Windows version: skip all the remaining test at the first
discrepancy point.
I could have maintained a couple of unit tests for this Windows
version, but decided not to:
- it would make the code more complicated (*),
- it doesn't bring value to Wine
- it would be a pain to maintain.
This patch fixes the (remaining) W10 part of bug below.
Support for W11 will be handled in separate patch (and likely with
properly integrating the results from W11, contrary to this patch).
Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=53465
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1873
The first intend of this serie is that CUI app in non processed input
mode should not die when using the ctrl-\ key stroke.
This series:
- implements ctrl-pause/break in conhost.exe (in processed mode) by
generating the proper console event
- maps for unix-console ctrl-\ into a ctrl-pause/break key stroke.
Code change is relatively small, and fixes an annoying behavior in
unix consoles (see bug report).
The series could have been a bit smaller by not adding ctrl-break
support in user32 console, but:
- it's cleaner that way
- it still requires the server changes (which may be perhaps the
most questionnable here, esp. the termios change).
So a valid (IMO) candidate for 8.0.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1867
--
v2: wined3d: Load and invalidate every mipmap level when mapping the top mipmap level.
d3d8/tests: Test uploading the whole mipmap chain in one map.
d3d9/tests: Test uploading the whole mipmap chain in one map.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1865
Fixes a regression introduced by
aa8f97e8294b0618de0e8a45ff2adef0c4e516da.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54184
For the requests which involve additional data to be sent the application might use WinHttpWriteData() before WinHttpReceiveResponse() to pass the additional request data instead of providing the optional data to WinHttpSendRequest(). In that case server reply can't be read in send_request().
I believe the first patch straightens up state handling in receive_response() by introducing a single switch processing every incoming state and avoiding additional local variable (along with making WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE notification handling less obscure).
--
v3: winhttp: Only read server reply in send_request() if the whole request is sent.
winhttp: Handle state in a single switch in receive_response().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1851
--
v3: mf/tests: Test SetOutputType for WMV decoder.
mf/tests: Use one input type for GetOutputType tests.
mf/tests: Introduce check_dmo_set_input_type.
mf/tests: Shorten test messages.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1839
While testing some Windows CUI app (hiew.exe from bug #54141), it appears
that some console API allow to write all the possible control characters
onto the console.
This serie:
- add tests for read/write test of these
- fix 'unix' console to not send some of the control characters to the
underlying tty, which would reinterpret them. This leads to unwanted
display (ie hexdump of a file would insert real cr/lf when displaying
dump of \r\n")
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1846
Fixes a regression introduced by
aa8f97e8294b0618de0e8a45ff2adef0c4e516da.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54184
For the requests which involve additional data to be sent the application might use WinHttpWriteData() before WinHttpReceiveResponse() to pass the additional request data instead of providing the optional data to WinHttpSendRequest(). In that case server reply can't be read in send_request().
I believe the first patch straightens up state handling in receive_response() by introducing a single switch processing every incoming state and avoiding additional local variable (along with making WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE notification handling less obscure).
--
v2: winhttp: Only read server reply in send_request() if the whole request is available.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1851