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
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
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
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