On Mon Jul 10 16:57:51 2023 +0000, Alex Henrie wrote:
> If thread safety matters here, could you use strtok_r?
I'm not sure if it does, just wanted to make sure there is no race conditions. Not sure why I missed strtok_r, thanks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_38565
I'm aware that winecfg allows unlinking of symlinked folders, but this is very annoying when regularly recreating WINEPREFIXES. This change makes it easy to isolate those folders from the start.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259
> we should test the behavior of ctrl-c
I'm bit late to be reporting this :smile:, but Ctrl-C in (probably all) `-mwindows` Wine apps is now ignored (`winecfg`, `regedit`, etc). On the Windows apps side of things, at least Notepad++ also doesn't close on Ctrl-C.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38548
--
v4: vkd3d-shader/dxil: Read function bodies.
vkd3d-shader/dxil: Read numeric constants.
vkd3d-shader/dxil: Read global function declarations.
vkd3d-shader/dxil: Validate the module format version.
vkd3d-shader/dxil: Read the value symbol table.
vkd3d-shader/dxil: Read the type table.
vkd3d-shader/dxil: Use size_t where applicable.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259
On Mon Jul 10 15:59:56 2023 +0000, Jakub Staroń wrote:
> It is indeed Wine-specific, but on Windows it isn't as much of a problem
> because AllocConsole gives you the same cmd you would use normally,
> while wineconsole is inferior to a normal terminal. Also is there any
> reason to explicitly block console output on GUI apps? If I understand
> it correctly on Windows it's done because otherwise a new console window
> is created, wine doesn't do that though?
all these four configurations should behave the same way regarding log output:
1) app on wine being run from a unix shell
2) app on wine being from with wineconsole
3) app on wine being run from a cmd window
4) app on windows being run from a cmd window
if you see a discrepancy in output between 2 of these four items, please report (or even better file a bug report)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38542
On Mon Jul 10 14:53:19 2023 +0000, Jacek Caban wrote:
> Is it some Wine-specific use case? I think that something like that
> would not work on Windows.
It is indeed Wine-specific, but on Windows it isn't as much of a problem because AllocConsole gives you the same cmd you would use normally, while wineconsole is inferior to a normal terminal. Also is there any reason to explicitly block console output on GUI apps? If I understand it correctly on Windows it's done because otherwise a new console window is created, wine doesn't do that though?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38539
On Mon Jul 10 14:53:19 2023 +0000, Jakub Staroń wrote:
> I know it's relying on broken behavior but before this PR it was nice to
> be able to log to the terminal from GUI apps (!3022 would be a much
> nicer solution for that). Does anyone know if there is a workaround to
> be still able to do that? My main issue is that wineconsole is way
> slower than normal terminal emulators.
Is it some Wine-specific use case? I think that something like that would not work on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38531
I know it's relying on broken behavior but before this PR it was nice to be able to log to the terminal from GUI apps (!3022 would be a much nicer solution for that). Does anyone know if there is a workaround to be still able to do that? My main issue is that wineconsole is way slower than normal terminal emulators.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3145#note_38528
Fix the issue of incorrect linkid calculation due to a lack of judgment on the current type.
Signed-off-by: Zhaoyi <zhaoyi(a)uniontech.com>
--
v10: comctl32/tests: Add a test case to get syslinkid.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3114
On Sat Jul 8 07:23:37 2023 +0000, Rémi Bernon wrote:
> You should only call `WindowsDeleteString` if the refcount gets to 0
> (and then you should also free the hostname, which I also missed).
Yeah, sorry for missing that. I've just been very burned out with life in general.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3249#note_38470
On Mon Jul 10 01:45:21 2023 +0000, Zhao Yi wrote:
> Thank you for reviewing my code and I will fix the above issue later.
There is no need to rush this. Please take your time to carefully review the code by yourself before submitting it for review. Look out for coding style issues and review each line you've changed. Overall, the fix looks good. Thanks for your work.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3114#note_38455
Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/syslink.c:
> }
>
> defwndproc_counter++;
> - ret = DefWindowProcW(hwnd, message, wParam, lParam);
> + switch(message)
You only need to record nml->item.iLink so you don't really need to process the message. So you can move this switch statement before defwndproc_counter++ and let the DefWindowProcW() handle it. Basically, add a switch statement, record nml->item.iLink from WM_NOTIFY, and break on other messages.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3114#note_38452
Fixes regression introduced by 35c8f15bc67f7602438fe0c39a69ff6ddf6b8297
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55215
We already test for an invalid pointer, those tests don't really help.
The test against DrawTextA crashes on windows sometimes, the other test shows that windows probably just overruns the stack variable:
`textheight = DrawTextExA((HDC)0xdeadbeef, (LPSTR)0xdeadbeef, 100, &rect, 0, 0);`
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3276
This MR attempts to bring Wine's handling of `setlocale` and `_create_locale` more in line with the behavior of native >= `msvcr110`. It does this by replacing the usage of the LCID based `GetLocaleInfo` with the sname based `GetLocaleInfoEx`. `GetLocaleInfo` doesn't support neutral locales, even on native, which causes problems with neutral Chinese locales like `zh-Hans` and `zh-Hant`.
It also improves the accuracy of the internal `__lc_locale_name_func`, as tests indicate that it returns `LOCALE_SNAME`s instead of ISO 639 language names.
Potential future improvements:
* Modifying the generation of the `pclmap` and `pcumap` fields of `threadlocaleinfostruct` to work on WCHARs.
* I've done some changes to `__thread_data` which make it not fully match native, I'll submit a follow up which fixes this.
--
v4: make_unicode: rename Hong Kong SAR China to Hong Kong SAR to match native behavior.
msvcrt: Use GetLocaleInfoEx to compare locale info.
msvcrt: Remap synonyms to snames.
msvcrt: Skip exhaustive locale search with valid snames.
msvcrt: Convert locale_to_LCID to snames.
msvcrt: Use snames instead of LCIDs in create_locinfo.
msvcr120/tests: Check ___lc_locale_name_func with neutral Chinese locales.
msvcr110/tests: Add tests for new setlocale behaviors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3050
--
v2: Release 8.0.2.
winedump: Fix out of bounds access (spotted by GCC13).
wordpad: Resize buttons of toolbar to make them align with height of the font list combox.
winemenubuilder: Skip desktop integration for certain associations.
wine.inf: Put the Clients key in the right place.
winemac: Initialize retina_on to avoid incorrect cached display data in high-res/retina mode.
winemac.drv: Force a window in front of its peers if its level is decreased.
threadpoolwinrt: Forward a Release() to a Release() method.
ntdll: Avoid integer overflow in block_get_subheap().
mfreadwrite: Fix an address of operator typo.
winemac: Don't constrain surface dimensions to the onscreen part of a window.
winemac: Set the Cocoa window contentMaxSize to the size limits from constrain_window_frame().
winemac: Refactor constrain_window_frame() to use separate origin and size arguments.
include: Fix IDirectXVideoDecoderService declaration in dxva2api.idl.
include: Fix c++ compiler error with msxml2.idl.
activeds: Free memory on error paths (coverity).
mshtml: Store minimum compat mode required for events in the ctor table.
mshtml: Fix URI leak in NewURI on failure.
mshtml: Fix nsIFile dir leak in init_xpcom.
mshtml: Fix factory leak in init_nsio.
winemac: Fix memory leak in UpdateDisplayDevices.
mshtml: Fix nsparser leak if script_elem_from_nsscript failed.
mshtml: Fix nsuri leak if create_channelbsc failed.
mshtml: Fix nsscript leak in bind_event_scripts.
mshtml: Fix nsevent leak in create_document_event.
evr: Fix incorrect integral computation.
msvcrt: Fix crash when rethrowing after a non-C++ exception on x86_64.
winedbg: Don't crash when no search path has been set.
ntdll: Open application manifest files with FILE_SHARE_DELETE.
kernel32/tests: Test for manifest file open share mode in CreateActCtxW.
wined3d: Add GPU information for AMD Raphael.
shlwapi: Implement StrFormatByteSizeEx.
ntdll: Fix typo in the check for hidden files.
ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match.
ntdll: Only infer hidden attribute from file name if xattr is not present.
ntdll: Handle hidden file names inside get_file_info instead of after it.
ntdll/tests: Add test for file attributes of files with names beginning with a dot.
ntdll: Make fd_set_file_info() static.
mfplat: Implement MFCreatePathFromURL().
dxdiag: Ignore option /64bit on the commandline.
findstr: Add basic functionality.
include/msvcrt: Add __WINE_(DEALLOC|MALLOC) attributes to _strdup and _wcsdup.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3168
In HttpSendRequestW and HttpSendRequestExW, if the header pointer is not
null but the length parameter is 0, the header length should be derived
from the string length instead.
In HttpSendRequestA and HttpSendRequestExA, on the same scenario, the
function should fail instead.
--
v2: wininet: Handle http headers correctly when length is 0
https://gitlab.winehq.org/wine/wine/-/merge_requests/3269
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55187
With this patch winedbg does from a user point of view
not silently exit, instead it can at least give this information
which might be at least better than nothing:
```
Process of pid=0020 has terminated
No process loaded, cannot execute 'echo Modules:'
Cannot get info on module while no process is loaded
No process loaded, cannot execute 'echo Threads:'
process tid prio name (all IDs are in hex)
... (list of still running processes)
System information:
Wine build: wine-8.11-146-gb0faa6fb042
Platform: i386
Version: Windows 10
Host system: Linux
Host version: 6.1.0-9-amd64
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3231
On Sat Jul 8 06:37:56 2023 +0000, Mohamad Al-Jaf wrote:
> That makes sense, it indeed duplicates the string on Windows based on
> the test I added. I'm not sure but there might be an issue with the way
> Wine handles HSTRING duplication as it's failing to create the right HSTRING.
> https://testbot.winehq.org/JobDetails.pl?Key=134593
> All I did was change it to `WindowsDuplicateString( name, &impl->rawname
> );` and add `WindowsDeleteString( impl->rawname );` under `IHostName::Release()`.
You should only call `WindowsDeleteString` if the refcount gets to 0 (and then you should also free the hostname, which I also missed).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3249#note_38391
This fixes an issue when the path includes non-ASCII characters.
Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com>
--
v2: mshtml: Call UrlUnescapeW() with URL_UNESCAPE_AS_UTF8 in is_gecko_path().
shlwapi/tests: Test UrlUnescapeW() with URL_UNESCAPE_AS_UTF8.
kernelbase: Implement URL_UNESCAPE_AS_UTF8 for UrlUnescapeW().
shlwapi/tests: Test UrlUnescapeW() with independent data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/585
On Fri Jul 7 20:46:54 2023 +0000, Nikolay Sivov wrote:
> Shouldn't this duplicate the string?
That makes sense, it indeed duplicates the string on Windows based on the test I added. I'm not sure but there might be an issue with the way Wine handles HSTRING duplication as it's failing to create the right HSTRING.
https://testbot.winehq.org/JobDetails.pl?Key=134593
All I did was change it to `WindowsDuplicateString( name, &impl->rawname );` and add `WindowsDeleteString( impl->rawname );` under `IHostName::Release()`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3249#note_38386
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.
--
v38: 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
This also converts the opaque pointers passed across the PE->Unix interface to opaque types
represented as UINT64 which store the unix side pointer. This makes the thunking simpler and should
avoid anyone accidently dereferencing the unix pointer in the PE code.
This was tested with warcraft 3 (1.26, the last non-reforged release), and is consistent with the standard 32bit build. ~~But since movies on warcraft 3 are broken in standard 32bit builds I could only test that that the gstreamer graph gets built up similarly and not verify the video playback. Id appreciate if someone knew of a working exercise of the gstreamer code.~~ it works great, the issue with cinematics ended up being related to modesetting under xwayland, running with a virtual desktop in winecfg confirms playback working perfectly.
--
v9: winegstreamer: Implement Wow64 entrypoints in the Unix library.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3075
In HttpSendRequestW and HttpSendRequestExW, if the header pointer is not
null but the length parameter is 0, the header length should be derived
from the string length instead.
In HttpSendRequestA and HttpSendRequestExA, on the same scenario, the
function should fail instead.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3269
This is a part of a larger effort to reorganize wined3d a bit so that backend
functions are fully quarantined into their own files. There are a few advantages
to this:
* We avoid including (large) headers in files that don't need them.
* This has helped me find functions that are currently incorrectly tied to
backends [e.g. wined3d_texture_update_desc(), wined3d_texture_set_lod()].
* This may also help find code (struct members, helpers, etc.) which should be
made local to a backend.
* I find that this aids the reader in logically separating wined3d code. For
some time the wined3d code base has resisted modularity of compilation units,
simply on the grounds that this is not necessary. I find files comprising
several thousand lines to be a bit unwieldy, however, and that comprehension
and navigation are eased when drawing physical lines even when such separation
was already obvious. It also can be nice for compilation speed.
There are a few steps to this:
- move GL and Vulkan declarations to wined3d_gl.h and wined3d_vk.h respectively
- introduce "resource_gl.c" and "resource_vk.c", and move most resource code to
those functions. This collapses the separation between buffer, texture,
sampler, and view code, though, and there may be some benefit in keeping those
separate.
It's worth mentioning though that the bulk of those files ends up being the
texture code. It's also worth mentioning that resources are generally
interrelated—e.g. views delegate to buffers or textures—and we've talked about
generalizing more of the buffer/texture code to share more code. Of course,
*everything* is interrelated, so the lines that we're drawing now are kind of
arbitrary. I at least find that GL/Vulkan are *useful* lines to draw.
- add format_gl.c, because there are about 3000 lines of code to deal with GL
format detection.
- add ffp_gl.c, which contains the fixed-function vertex and fragment pipelines.
This is about 3500 lines.
- move other functions to backend-specific adapter or context functions, where
it makes sense. Swapchain code mostly gets moved to context_*.c, though I'm
not sure whether that makes the most sense or not.
--
v2: wined3d: Move struct wined3d_adapter_vk to wined3d_vk.h.
wined3d: Move struct wined3d_context_vk to wined3d_vk.h.
wined3d: Move struct wined3d_query_vk to wined3d_vk.h.
wined3d: Move struct wined3d_image_vk to wined3d_vk.h.
wined3d: Move struct wined3d_bo_vk to wined3d_vk.h.
wined3d: Move some definitions to wined3d_vk.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3238
On Fri Jul 7 08:04:06 2023 +0000, Rémi Bernon wrote:
> Sorry, I should've checked that.
> Fwiw if the module doesn't export anything in particular it should not
> really matter how it's named, the classes are registered with whatever
> module implements them and the code reads the module name from the registry.
Do you want me to create a new MR where I rename it? I agree that it should be in the correct dll, sorry for messing that up.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38336
This is a part of a larger effort to reorganize wined3d a bit so that backend
functions are fully quarantined into their own files. There are a few advantages
to this:
* We avoid including (large) headers in files that don't need them.
* This has helped me find functions that are currently incorrectly tied to
backends [e.g. wined3d_texture_update_desc(), wined3d_texture_set_lod()].
* This may also help find code (struct members, helpers, etc.) which should be
made local to a backend.
* I find that this aids the reader in logically separating wined3d code. For
some time the wined3d code base has resisted modularity of compilation units,
simply on the grounds that this is not necessary. I find files comprising
several thousand lines to be a bit unwieldy, however, and that comprehension
and navigation are eased when drawing physical lines even when such separation
was already obvious. It also can be nice for compilation speed.
There are a few steps to this:
- move GL and Vulkan declarations to wined3d_gl.h and wined3d_vk.h respectively
- introduce "resource_gl.c" and "resource_vk.c", and move most resource code to
those functions. This collapses the separation between buffer, texture,
sampler, and view code, though, and there may be some benefit in keeping those
separate.
It's worth mentioning though that the bulk of those files ends up being the
texture code. It's also worth mentioning that resources are generally
interrelated—e.g. views delegate to buffers or textures—and we've talked about
generalizing more of the buffer/texture code to share more code. Of course,
*everything* is interrelated, so the lines that we're drawing now are kind of
arbitrary. I at least find that GL/Vulkan are *useful* lines to draw.
- add format_gl.c, because there are about 3000 lines of code to deal with GL
format detection.
- add ffp_gl.c, which contains the fixed-function vertex and fragment pipelines.
This is about 3500 lines.
- move other functions to backend-specific adapter or context functions, where
it makes sense. Swapchain code mostly gets moved to context_*.c, though I'm
not sure whether that makes the most sense or not.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3238
--
v3: vkd3d-shader/dxil: Read function bodies.
vkd3d-shader/dxil: Read numeric constants.
vkd3d-shader/dxil: Read global function declarations.
vkd3d-shader/dxil: Validate the module format version.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259
--
v2: vkd3d-shader/dxil: Read function bodies.
vkd3d-shader/dxil: Read numeric constants.
vkd3d-shader/dxil: Read global function declarations.
vkd3d-shader/dxil: Validate the module format version.
vkd3d-shader/dxil: Read the value symbol table.
vkd3d-shader/dxil: Read the type table.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259
On Tue Jul 4 13:08:35 2023 +0000, Henri Verbeet wrote:
> > The part that doesn't thrill me is the fact that DXGI still directly
> accesses the VkQueue object, which I tend to see as an internal
> implementation detail to vkd3d. On the other hand it's nice that we
> don't need new API from vkd3d (even if, in the future, we were to need
> something other than vkQueueSubmit() and vkQueuePresentKHR()).
> For what it's worth, it was a fairly explicit design decision early on
> to expose the underlying Vulkan objects for d3d12 devices and command
> queues, as well as to allow the creation of d3d12 resources on top of
> existing Vulkan images, for the purpose of interoperation with other
> Vulkan code. I.e., the idea is that it should be possible to integrate
> vkd3d into a larger Vulkan application to draw some parts using the
> d3d12 API, while everything else is drawn using Vulkan.
> The internal queueing of command queue operations on the vkd3d level is
> unfortunate in that regard; ideally we just wouldn't do that. This MR
> could probably do a better job of explaining why we need to do that in
> some cases, and what kind of command queue operation sequences could
> result in out-of-order presentation.
> If we're going to need to introduce a DXGI worker thread anyway, could
> we just make vkd3d_acquire_vk_queue() block until there are no longer
> any operations queued?
We already somewhat discussed that internally, but for the benefit of public archival the behavior of `vkd3d_acquire_vk_queue()` and `vkd3d_release_vk_queue()` was documented in https://gitlab.winehq.org/wine/vkd3d/-/commit/b2a1f6b5e4f59fbc7f91ada7e5656…. I'll implement the behavior recommended there in my next MR.
The reason why it was decided to recommend to explicitly synchronize with an `ID3D12Fence` instead of making `vkd3d_acquire_vk_queue()` block until the queue is empty is because it is believed that the application is better than vkd3d at knowing how long it really makes sense to wait before actually acquiring the queue. In other words, `vkd3d_acquire_vk_queue()` doesn't know which queued operations are really required to be serialized with the queue acquisition.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_38301
This serie implements a more robust strategy when winedbg
attaches to process which tries to terminate.
This let --auto mode print some more information (and no longer
crash) in such situation.
Revamped also a bit information displayed in auto mode.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3246
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54699
I added the complete `windows.networking.idl` file since it was small and in case it's needed for mingw build.
--
v4: windows.networking.hostname: Implement IHostName::get_RawName().
windows.networking.hostname: Implement IHostNameFactory::CreateHostName().
windows.networking.hostname/tests: Add IHostNameFactory::CreateHostName() tests.
windows.networking.hostname: Add IHostNameFactory stub interface.
windows.networking.hostname: Add stub DLL.
include: Add windows.networking.idl file.
include: Add windows.networking.connectivity.idl file.
include: Add support for BYTE IReference.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3249
On Fri Jul 7 07:21:06 2023 +0000, Bernhard Kölbl wrote:
> You could also add tests like in media.speech, where you try loading the
> DLL via LoadLibraryW
Sorry, I should've checked that.
Fwiw if the module doesn't export anything in particular it should not really matter how it's named, the classes are registered with whatever module implements them and the code reads the module name from the registry.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38294
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