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