On Thu Jul 6 23:20:17 2023 +0000, Mohamad Al-Jaf wrote:
> It's in the registry under
> `HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsRuntime\ActivatableClassId`.
> It lists the classes there and if you click one there's a `DllPath`
> string that contains the housing dll.
You could also add tests like in media.speech, where you try loading the DLL via LoadLibraryW
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38290
On Mon Jul 3 10:04:03 2023 +0000, Davide Beatrici wrote:
> changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/3218/diffs?diff_id=55132&start_sha=a029ad6955486d1f4255b8af264e37bdef92075e#93e6661c548f95d6c2ae8340ba18809196820745_630_621)
!3260
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3218#note_38286
On Mon Jul 3 10:04:02 2023 +0000, Davide Beatrici wrote:
> changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/3218/diffs?diff_id=55132&start_sha=a029ad6955486d1f4255b8af264e37bdef92075e#93e6661c548f95d6c2ae8340ba18809196820745_628_621)
!3260
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3218#note_38284
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v37: ws2_32/tests: Add test for AF_UNIX sockets fix.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are supported by this patch.
--
v36: ws2_32/tests: Add test for AF_UNIX sockets fix.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to connect() to abstract AF_UNIX sockets.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
On Thu Jul 6 22:55:31 2023 +0000, Fabian Maurer wrote:
> I could have sworn `windows.devices.geolocation.geolocator.dll` exists,
> but on my Win10 it doesn't. How does one check which DLL the code
> resides in?
It's in the registry under `HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsRuntime\ActivatableClassId`. It lists the classes there and if you click one there's a `DllPath` string that contains the housing dll.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38262
On Thu Jul 6 22:14:53 2023 +0000, Mohamad Al-Jaf wrote:
> Isn't this supposed to be in `geolocation.dll`?
I could have sworn `windows.devices.geolocation.geolocator.dll` exists, but on my Win10 it doesn't. How does one check which DLL the code resides in?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38261