- wine-gitlab - winehq.org

[PATCH v4 0/1] MR3494: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h.
by Vitaly Lipatov (＠lav) 04 Aug '23

04 Aug '23

-- v4: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/3494

3 2

[PATCH v3 0/1] MR3494: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h.
by Vitaly Lipatov (＠lav) 03 Aug '23

03 Aug '23

-- v3: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/3494

2 1

[PATCH 0/1] MR3507: win32u: Copy an incoming CB_GETCOMBOBOXINFO when packing it for the client.
by Tim Clem (＠tclem) 03 Aug '23

03 Aug '23

The only important field at this point is cbSize, but if it's zero, the message will not be processed. --- The other option would be to zero the buffer and then do the equivalent of `((COMBOBOXINFO *)buffer)->cbSize = sizeof(COMBOBOXINFO)`, rather than copying the incoming lparam. That doesn't seem better to me, but I'm no expert. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3507

2 1

[PATCH v2 0/1] MR3494: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h.
by Vitaly Lipatov (＠lav) 03 Aug '23

03 Aug '23

-- v2: include: Update SECURITY_LOGON_TYPE and SECURITY_LOGON_SESSION_DATA in ntsecapi.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/3494

3 3

[PATCH 0/9] MR3506: Improve headers compatibility
by Vitaly Lipatov (＠lav) 03 Aug '23

03 Aug '23

I tried build a real Windows application (mimikatz) and had troubles with some wine headers incompatibility. The patch set improves headers to allow build the foreign application with Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3506

2 9

Re: [PATCH v5 0/2] MR3473: whoami: Refactor and add more commands.
by Hans Leidekker (＠hans) 03 Aug '23

03 Aug '23

On Thu Aug 3 10:09:59 2023 +0000, Maxim Karasev wrote: > Printing a non-english username. > `wprintf()` by default doesn't print non-english letters at all (I > remember testing various system LC_ALL variants, like `C.UTF-8`, > `en_US.UTF-8`, `ru_RU.UTF-8`, and none of that took an effect). > With `setlocale(LC_ALL, something)` it does print the letters, but > 1. Only of a language that is set, so I presume it chooses something > like a `cp1251` equivalent (an 8-bit language-specific encoding?). > 2. It isn't used in any of other wine programs, while that > `ConsoleWriteW()` hack is used at least in present whoami and xcopy > implementations (probably more). > This implementation, in turn, behaves exactly like the Windows whoami. > Also when testing the `klist` I noticed that on Windows it was printing > `?` signs instead of `Server` string (somehow hooked up a translation?), > so `ConsoleWriteW()` seems to be necessary for any translatable console > programs if one wants to avoid `setlocale()`. I tried a username with non-ascii characters on Windows 10 and Wine and whoami behaves the same. Non-ascii characters are rendered on the console. When redirecting output non-ascii characters are replaced with '?'. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3473#note_41261

1 0

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Yuxuan Shui (＠yshui) 03 Aug '23

03 Aug '23

On Thu Aug 3 16:39:16 2023 +0000, Yuxuan Shui wrote: > Yes, what you said makes sense. > > something that's pretty much always been within Wine's scope to fix. > I want to assure you I 100% understand that. After all, this MR is > exactly trying to fix such a case. And I think it's better if I clarify what I mean when I say "invalid". In this example, this use of `ReleaseSRWLockExclusive` is clearly invalid w.r.t. the official description of the API, and that's why I called it so. Real world applications do make use of APIs in invalid ways, and Wine has to support those usages. However this doesn't make such uses less invalid. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41257

1 0

Re: [PATCH v5 0/4] MR3319: evr: Leave critical section before waiting for streaming thread.
by Santino Mazza (＠tati1454) 03 Aug '23

03 Aug '23

- Fixed the queue memory leak - Created a critical section for the queue - I removed the allocator lock when it calls NotifyRelease, I didn't add a case for being able to call NotifyRelease inside the lock because NotifyRelease never receives a pointer to the allocator so I don't think there is a need to still lock while running NotifyRelease. - Moved process_input to NotifyRelease. - Also removed the test because it doesn't reproduce the bug reliably specially in the testbot, but I can add it again if it's needed or try to look for a way to make it reliable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3319#note_41256

1 0

[PATCH v4 0/4] MR3319: evr: Leave critical section before waiting for streaming thread.
by Santino Mazza (＠tati1454) 03 Aug '23

03 Aug '23

I'm not sure how could I test this behavior, right now the test I wrote works but there are times where it doesn't enter into the deadlock. -- v4: evr: Remove process input handling from streaming thread. evr: Don't lock allocator in NotifyRelease call. evr: Create critical section for sample queue. evr: Release sample queue when streaming ends. https://gitlab.winehq.org/wine/wine/-/merge_requests/3319

2 4

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Yuxuan Shui (＠yshui) 03 Aug '23

03 Aug '23

On Thu Aug 3 16:09:52 2023 +0000, Zebediah Figura wrote: > > I feel that is a bit overkill for a single application, which is using > the lock in an invalid way anyway. > Maybe, but I don't like the way this patch basically feels like it's > hacking around the current behaviour. > I'd also assert that "invalid" is often not a very meaningful word when > it comes to Wine. There's documented API, sure, but programs making > assumptions about internals is commonplace, and something that's pretty > much always been within Wine's scope to fix. Yes, what you said makes sense. > something that's pretty much always been within Wine's scope to fix. I want to assure you I 100% understand that. After all, this MR is exactly trying to fix such a case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41253

1 0

2025

2024

2023

2022

wine-gitlab