February 2024 - Wine-gitlab

Re: [PATCH v11 0/7] MR4082: gdiplus: Implement font linking in GdipDrawString.
by Esme Povirk (＠madewokherd) 06 Feb '24

06 Feb '24

On Tue Feb 6 18:52:00 2024 +0000, Esme Povirk wrote: > I think this should be || No, that doesn't seem right either, I need to think about this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4082#note_60324

1 0

Re: [PATCH v11 0/7] MR4082: gdiplus: Implement font linking in GdipDrawString.
by Esme Povirk (＠madewokherd) 06 Feb '24

06 Feb '24

Esme Povirk (@madewokherd) commented about dlls/gdiplus/graphics.c: > + to_measure_length = min(length - (i - index), section->end - i); > + > + get_font_hfont(graphics, section->font, NULL, &hfont, NULL, NULL); > + oldhfont = SelectObject(graphics->hdc, hfont); > + GetTextExtentExPointW(graphics->hdc, &string[i], to_measure_length, max_ext, &fitaux, NULL, &sizeaux); > + SelectObject(graphics->hdc, oldhfont); > + DeleteObject(hfont); > + > + max_ext -= sizeaux.cx; > + if (fit) > + *fit += fitaux; > + size->cx += sizeaux.cx; > + size->cy = max(size->cy, sizeaux.cy); > + > + i += to_measure_length; > + if ((i - index) >= length && fitaux < to_measure_length) break; I think this should be || -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4082#note_60323

1 0

Re: [PATCH v11 0/7] MR4082: gdiplus: Implement font linking in GdipDrawString.
by Esme Povirk (＠madewokherd) 06 Feb '24

06 Feb '24

On Tue Feb 6 15:01:50 2024 +0000, Santino Mazza wrote: > I tested GdipMeasureString with different strings that require font > linking and it behaves correctly. It's strange because I also tested > with the exact same string the game uses and with the generic > typographic format, but I still can't get the bug to reproduce. > Apparently when the game tries to draw that specific string, > GdipMeasureString returns a bounding box with width 0, which causes > draw_string_callback to not increase the X position, so it overwrites > the other word. Again this doesn't happen if I use font_link_get_text_extent_point. The difference might have to do with scaling? It looks like GdipMeasureString scales the size, and I don't think font_link_get_text_extent_point would. Come to think of it, it's probably necessary to account for text rotation when in draw_string_callback (an arbitrary affine transform can be applied to the text, although I think at the moment our handling of anything beyond rotation is a bit broken). I think it might be a good idea to add output parameters for dx and dy to draw_driver_string. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4082#note_60317

1 0

[PATCH v2 0/1] MR5024: msvcrt: Adjust _gmtime64_s() accepted time limits.
by Paul Gofman (＠gofman) 06 Feb '24

06 Feb '24

Fixes a crash in Microsoft Flight Simulator (which passes some currently invalid values to ucrtbase._gmtime64() and doesn't expect NULL result). It looks like any msvcrt version on modern Windows accepts wider range of values. Meanwhile, the exact range is different for ucrtbase vs older CRT versions (the exact values for ucrtbase also vary before Win10 1909). Also, older msvcrt.dll matches what we have in Wine now. So the patch keeps old msvcrt behavior, adds universally correct limits for msvcrt 70-120 and the latest (Win10 1909+) for ucrtbase. -- v2: msvcrt: Adjust _gmtime64_s() accepted time limits. https://gitlab.winehq.org/wine/wine/-/merge_requests/5024

3 6

[PATCH v11 0/8] MR4982: Load and play MIDI
by Yuxuan Shui (＠yshui) 06 Feb '24

06 Feb '24

There are still some issues I need to fix, mainly around timing conversion between MIDI and dmusic. Right now MIDI files seem to be cut off before the end is reached. Please have a look at the general approach in the meantime, I need to know if this is the right way to do this or not. -- v11: dmime: Create a band track for MIDI segments. https://gitlab.winehq.org/wine/wine/-/merge_requests/4982

4 15

[PATCH 0/1] MR5039: winebus.sys: Do not attempt to open keyboard and mouse HID devices on macOS.
by Tim Clem (＠tclem) 06 Feb '24

06 Feb '24

Doing so triggers a permissions prompt for input monitoring. Patch originally by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5039

3 2

[PATCH 0/1] MR5037: kernelbase: Reduce FIXME to TRACE if params is null.
by Nikola Kuburović 06 Feb '24

06 Feb '24

The game I was trying to run (Ravendawn) was polluting the stdout with hundreds of CreateFile2 FIXMEs. The game worked fine, probably because the params pointer was NULL, so any non-implemented extra parameters weren't even used and we just forwarded to CreateFileW. So, a simple if was added to check whether the pointer is null, and if it is, we just call TRACE instead of FIXME since in this case it isn't really necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5037

3 2

[PATCH v3 0/4] MR627: vkd3d: Implement ID3D12Resource2.
by Conor McCarthy (＠cmccarthy) 06 Feb '24

06 Feb '24

-- v3: vkd3d: Implement ID3D12Resource2. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/627

3 6

[PATCH v2 0/3] MR5035: Change SetLastError to RestoreLastError if appropriate
by Alfred Agrell (＠Alcaro) 06 Feb '24

06 Feb '24

Theoretically, this allows debuggers to tell them apart. https://devblogs.microsoft.com/oldnewthing/20110429-00/?p=10803 But in practice, this is more about cleanliness than anything else; I'm not aware of anyone running SetLastError-aware debuggers in Wine. Feel free to reject if this is a waste of time. The changeable SetLastError calls were found by this script: ```python #!/usr/bin/env python3 import os import re for (dirpath, dirnames, filenames) in os.walk("."): for fn in filenames: if not fn.endswith(".c"): continue text = open(dirpath+"/"+fn,"rt").read() text = text.replace("RtlSetLastWin32Error","SetLastError") text = text.replace("RtlGetLastWin32Error","GetLastError") if "SetLastError" not in text: continue varname = None for line in text.split("\n"): if "GetLastError" in line: if m := re.search(r"([A-Za-z0-9_]+) *= *GetLastError", line): prevline = line varname = m[1] if line == "}": varname = None if varname is not None and "SetLastError" in line: if m := re.search(r"SetLastError\( *([A-Za-z0-9_]+) *\)", line): if m[1] == varname: print(dirpath+"/"+fn, prevline, line) ``` The script also flags https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/mpr/wnet.c#L2811, which is half set and half restore; I chose to left it unchanged. Idea from https://gitlab.winehq.org/wine/wine/-/merge_requests/5020/diffs#6c845445f68… -- v2: win32u: Use RtlRestoreLastWin32Error instead of RtlSetLastWin32Error if appropriate everywhere: Change SetLastError to RestoreLastError if appropriate ntdll: Duplicate RtlSetLastWin32Error to RtlRestoreLastWin32Error https://gitlab.winehq.org/wine/wine/-/merge_requests/5035

4 5

[PATCH 0/1] MR5036: win32u: Use consistent locking order for display related mutexes.
by Alexandros Frantzis (＠afrantzis) 06 Feb '24

06 Feb '24

Most paths that hold both the display_lock and the display_devices_init mutex acquire them in the order just mentioned. However, there are two cases where these are acquired in the opposite order, which with unfortunate thread interactions and timings can lead to a deadlock. Fix these cases to use the same order as the rest of the code. --- The instance of this deadlock I am seeing happens when enabling the virtual desktop mode with the Wayland driver (with pristine master) with any program. It's a deadlock between two threads calling: 1. `get_display_depth` =\> first acquires `display_lock` (in `lock_display_devices`) then `display_devices_init` (in `adapter_get_current_settings)` 2. `desktop_update_display_devices` =\> `add_gpu` =\> first acquires `display_devices_init` then `display_lock` The deadlock is not very easy to hit normally, but a sleep like in the attached patch below makes it 100% reproducible for me: [add_gpu_sleep.patch](/uploads/c08632d7a9dec751840199bdb16fb9a8/add_gpu_sleep.patch) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5036

2 1