Zhiyi Zhang (@zhiyi) commented about dlls/uxtheme/tests/system.c:
>
> +static void test_ShouldSystemUseDarkMode(void)
> +{
> + DWORD light_theme, light_theme_size = sizeof(light_theme), last_error;
> + BOOL result;
> + LSTATUS ls;
> +
> + pShouldSystemUseDarkMode = (void *)GetProcAddress(GetModuleHandleA("uxtheme.dll"),
> + MAKEINTRESOURCEA(138));
> + if (!pShouldSystemUseDarkMode)
> + {
> + win_skip("ShouldSystemUseDarkMode() is unavailable.\n");
> + return;
> + }
> +
> + ls = RegGetValueW(HKEY_CURRENT_USER,
I think ShouldSystemUseDarkMode() should use SystemUsesLightTheme registry key instead of AppsUseLightTheme. However, Wine currently doesn't set SystemUsesLightTheme. Let's set SystemUsesLightTheme in winecfg/theme.c on_theme_changed() as well. And change the "WinRT app theme" to "WinRT theme". The winecfg changes should be in a separate commit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3959#note_47848
This series:
- fixes a couple of issues in mach-o modules support
(getting information from system modules in wow setups,
machine information...)
- stops hiding information in some fields between dbghelp
and winedbg (using an extensible solution, where more
information can be shared in the future)
- display elf/mach-o in winedbg (previously mach-o was
reported as elf)
- display PE native vs builtin module information in winedbg
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3975
Rainbow 6 Siege and some other games require this. Type is printed in the FIXME to determine which type the application requires.
--
v8: gdi32: Add stub for D3DKMTQueryAdapterInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777
> Since MCI_UnmapMsgAtoW handles all the cases where MCI_MapMsgAtoW allocates memory. Why not just call MCI_UnmapMsgAtoW to do its thing in all cases?
Fine, but it would need to be a separate commit to that of changing the return values of `MCI_MapMsgAtoW()`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3854#note_47829
On Fri Oct 6 06:52:42 2023 +0000, Maarten De Braekeleer wrote:
> Hey!
> First, thanks for addressing this. The fact that CTRL+C closes cmd was
> the reason I created https://bugs.winehq.org/show_bug.cgi?id=55197.
> I have some questions about the current cmd behavior:
> - `CTRL+C` creates a new line, but does not write a new prompt to stdout.
> Typing text will make text appear again on the original line.
> Microsoft cmd will create a new prompt, and make new text input appear
> after that.
> - This is probably a feature request, but I think it would be useful to
> close cmd by pressing CTRL+D (EOF). Other repl's, such as python have
> this behavior.
> If you prefer me to create bugzilla issues for these, let me know.
please file a bug report for the missing prompt after ctrl-c in cmd (note: it should be also pointed out that ctrl-c in builtin cmd doesn't stop current command: e.g. try to stop 'dir /s c:\\')
I'm afraid that ctrl-d will not be supported as you'd like. this is a unix shell behavior, not windows console one.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_47820