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
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
On Thu Jul 11 08:58:24 2024 +0000, Egor Poleshko wrote:
> Does the user on that computer have an offline display name?
> {width=318 height=100}
What do you mean?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75886
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?
{width=318 height=100}
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6002#note_75885
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
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