- wine-gitlab - winehq.org

Re: [PATCH v4 0/1] MR3598: ntdll: Add error and warning logs in more cases of memory exhaustion.
by Tim Clem (＠tclem) 11 Jul '24

11 Jul '24

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

1 0

[PATCH v5 0/2] MR6021: nsiproxy.sys: Use pcblist64 sysctl to enumerate TCP & UDP connections on macOS.
by Tim Clem (＠tclem) 11 Jul '24

11 Jul '24

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

2 3

[PATCH v3 0/2] MR5990: mfreadwrite/reader: Fix seeking and playback loop when using decoders.
by Rémi Bernon (＠rbernon) 11 Jul '24

11 Jul '24

-- v3: mfreadwrite/reader: Send MFT_MESSAGE_NOTIFY_START_OF_STREAM on start or seek. winegstreamer/video_decoder: Generate timestamps relative to the first input sample. https://gitlab.winehq.org/wine/wine/-/merge_requests/5990

3 7

[PATCH 0/3] MR6057: Cmd engine rewrite (part XX)
by eric pouech (＠epo) 11 Jul '24

11 Jul '24

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

3 4

[PATCH v2 0/1] MR6007: ntdll: Don't use CLOCK_REALTIME_COARSE
by Tatsuyuki Ishi (＠ishitatsuyuki) 11 Jul '24

11 Jul '24

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

4 11

[PATCH 0/1] MR6056: include: Fix typo with X3DAUDIO_EMITTER structure in x3daudio.h
by Biswapriyo Nath (＠Biswa96) 11 Jul '24

11 Jul '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6056

3 2

[PATCH 0/1] MR6054: Draft: mf/tests: Reduce the mute threshold for the transform tests.
by Rémi Bernon (＠rbernon) 11 Jul '24

11 Jul '24

It constantly fails on Gitlab because of output overflow. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6054

2 1

[PATCH v11 0/1] MR5968: cmd: Do not set enviroment variable when no input is provided by set /p command.
by Vijay Kiran Kamuju (＠infyquest) 11 Jul '24

11 Jul '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55662 Tests are not provided as its interactive. -- v11: cmd: Do not set enviroment variable when no input is provided by set /p command. https://gitlab.winehq.org/wine/wine/-/merge_requests/5968

3 2

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Dmitry Timoshkov (＠dmitry) 11 Jul '24

11 Jul '24

On Thu Jul 11 10:43:10 2024 +0000, Egor Poleshko wrote: > I will. Also, take a look at this: > ![GetUserNameExW](/uploads/786f1b0d12cc9dffb024bb0a65e328ee/GetUserNameExW.mp4) Videos usually provide no technical information and lead to pure speculations. Actual code sounds more convincing: https://testbot.winehq.org/JobDetails.pl?Key=147012 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75897

1 0

[PATCH 0/9] MR6052: mshtml: Improve script global object handling and use new bindings for more objects.
by Jacek Caban (＠jacek) 11 Jul '24

11 Jul '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6052

3 10

Re: [PATCH v5 0/4] MR5237: Use futexes on macOS for thread-ID alerts.
by Marc-Aurel Zent (＠mzent) 11 Jul '24

11 Jul '24

On Thu Jul 11 10:51:43 2024 +0000, Elizabeth Figura wrote: > Sorry for the late approval; I missed that I had been assigned. > As far as I can tell from the documentation this is correct and matches > the semantics we need. > There are a couple trailing whitespace errors in the last patch though. No worries, and thanks the review! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5237#note_75894

1 0

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Egor Poleshko (＠somedevfox) 11 Jul '24

11 Jul '24

On Thu Jul 11 10:08:54 2024 +0000, Dmitry Timoshkov wrote: > I'd suggest to add a test. That test most likely will show that > GetUserNameEx(NameDisplay) returns an error ERROR_NONE_MAPPED on every > VM in the Testbot. That means that your assumptions about > GetUserNameEx() behaviour are incorrect, and the code in your plugin > software won't work on at least some (I'd guess on most) of the Windows > computers. Therefore your implementation is incorrect as well. I will. Also, take a look at this: ![GetUserNameExW](/uploads/786f1b0d12cc9dffb024bb0a65e328ee/GetUserNameExW.mp4) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75893

1 0

[PATCH 0/1] MR6044: crypt32: Make CertFindCertificateInStore(CERT_FIND_ISSUER_NAME) work.
by Dmitry Timoshkov (＠dmitry) 11 Jul '24

11 Jul '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6044

4 3

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Dmitry Timoshkov (＠dmitry) 11 Jul '24

11 Jul '24

On Thu Jul 11 09:52:04 2024 +0000, Egor Poleshko wrote: > Nevermind, I apologise. I misunderstood how do the username values work > on local accounts. > From your and my observations, GetUserNameExW(3) performs several checks > before returning a result: > - If the user is connected to an Active Directory domain, return the > `displayName` value from the domain LDAP database. > - If the local user is linked to a Microsoft account, return the name > specified in it. > - Else, return `ERROR_NONE_MAPPED`. > The Microsoft Account part is tricky, because, as far as I know, Wine > doesn't provide a way to link the local user to a Microsoft account... > Maybe, my implementation will suffice? I'd suggest to add a test. That test most likely will show that GetUserNameEx(NameDisplay) returns an error ERROR_NONE_MAPPED on every VM in the Testbot. That means that your assumptions about GetUserNameEx() behaviour are incorrect, and the code in your plugin software won't work on at least some (I'd guess on most) of the Windows computers. Therefore your implementation is incorrect as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75890

1 0

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Egor Poleshko (＠somedevfox) 11 Jul '24

11 Jul '24

On Thu Jul 11 09:01:15 2024 +0000, Dmitry Timoshkov wrote: > What do you mean? Nevermind, I apologise. I misunderstood how do the username values work on local accounts. From your and my observations, GetUserNameExW(3) performs several checks before returning a result: - If the user is connected to an Active Directory domain, return the `displayName` value from the domain LDAP database. - If the local user is linked to a Microsoft account, return the name specified in it. - Else, return `ERROR_NONE_MAPPED`. The Microsoft Account part is tricky, because, as far as I know, Wine doesn't provide a way to link the local user to a Microsoft account... Maybe, my implementation will suffice? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75889

1 0

[PATCH v10 0/1] MR5968: cmd: Do not set enviroment variable when no input is provided by set /p command.
by Vijay Kiran Kamuju (＠infyquest) 11 Jul '24

11 Jul '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55662 Tests are not provided as its interactive. -- v10: cmd: Do not set enviroment variable when no input is provided by set /p command. https://gitlab.winehq.org/wine/wine/-/merge_requests/5968

3 3

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Dmitry Timoshkov (＠dmitry) 11 Jul '24

11 Jul '24

On Thu Jul 11 08:58:24 2024 +0000, Egor Poleshko wrote: > Does the user on that computer have an offline display name? > ![image](/uploads/c9944139127ec71cac7d2b2d1e19c834/image.png){width=318 height=100} What do you mean? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75886

1 0

Re: [PATCH v2 0/1] MR6002: secur32: Implement the NameDisplay name format of the GetUserNameExW method
by Egor Poleshko (＠somedevfox) 11 Jul '24

11 Jul '24

On Tue Jul 9 18:18:29 2024 +0000, Egor Poleshko wrote: > Hm, interesting. I'll experiment with this and make changes to my branch > accordingly. Thank you. Does the user on that computer have an offline display name? ![image](/uploads/c9944139127ec71cac7d2b2d1e19c834/image.png){width=318 height=100} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75885

1 0

[PATCH v4 0/2] MR6021: nsiproxy.sys: Use net.inet.tcp.pcblist64 to enumerate connections on macOS.
by Tim Clem (＠tclem) 11 Jul '24

11 Jul '24

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 pcblist64, so I had to fetch it with sysctlbyname. -- v4: nsiproxy.sys: Use the pcblist64 sysctl to enumerate UDP connections on macOS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6021

5 7

[PATCH 0/6] MR6051: win32u: Move layered window attributes update out of the drivers.
by Rémi Bernon (＠rbernon) 11 Jul '24

11 Jul '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6051

2 6

[PATCH 0/2] MR6049: ntdll: Double-null-terminate registry multi-strings in RtlQueryRegistryValues.
by Alex Henrie (＠alexhenrie) 11 Jul '24

11 Jul '24

This reverts most of commit 2821a850d401dfabc5d76a4f40b0d6a42045fc5e which was a partial and ultimately improper solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6049

2 2

[PATCH v2 0/4] MR6045: server: Reimplement mailslots using server-side I/O.
by Elizabeth Figura (＠zfigura) 11 Jul '24

11 Jul '24

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. -- v2: 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

3 5

Re: [PATCH v4 0/1] MR3598: ntdll: Add error and warning logs in more cases of memory exhaustion.
by theofficialgman (＠theofficialgman) 11 Jul '24

11 Jul '24

@tclem would you might providing a brief explanation on the thought process behind this? In the usecase where the host has below 48bits of address space (commonly the case on arm64 linux kernels which might use 39bit or even 36bit address space) this results in the following similar lines of text being basically spammed in the log during process creation ``` 002c:err:virtual:map_fixed_area out of memory for 0x6fffffcd0000-0x6ffffffef000 002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffcd0000-0x7ffffffef000, unix_prot 0x7. ``` Are 48bits of address space really a requirement for most applications and cause fatal errors without it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_75871

1 0

[PATCH v2 0/4] MR6047: server: Deny opening handles to objects with zero access.
by Paul Gofman (＠gofman) 11 Jul '24

11 Jul '24

-- v2: server: Skip inaccessible threads in (get_next_thread). server: Do not allow zero access mask when opening some objects. ntoskrnl.exe/tests: Open directory object with nonzero access in test_permanent(). ntdll/tests: Add tests for opening some objects with zero access. https://gitlab.winehq.org/wine/wine/-/merge_requests/6047

3 5

[PATCH 0/4] MR6047: server: Deny opening handles to objects with zero access.
by Paul Gofman (＠gofman) 11 Jul '24

11 Jul '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6047

3 6

2025

2024

2023

2022

wine-gitlab