Tests and implementation for IFileOpearation_NewItem, which a Windows file explorer that I really like needs.
--
v3: shell32: Implement IFileOperation_NewItem for directory creation.
shell32/tests: Add tests for IFileOperation_NewItem.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8491
In wined3d_swapchain_cleanup, before decrementing the reference counts of each of the back/front
buffers, we first set their swapchain to NULL, presumably to stop the current under-destruction
swapchain from being used through them. But there is an oversight.
When we call wined3d_texture_decref on the front_buffer, the back_buffers still have their
swapchains pointing to the swapchain being destroyed. In texture_resource_unload, we call
context_acquire(device, NULL, 0), note the NULL texture parameter here. When the texture parameter
is NULL, wined3d_context_gl_acquire (in turn called by context_acquire) will default to using the
first back buffer from the implicit swapchain of "device", which, as previously stated, has not had
their swapchain set to NULL yet. From here, we reach wined3d_context_gl_activate with a texture
whose swapchain is currently being destroyed. This swapchain is then assigned to "context_gl" here
before being freed, leaving a dangling pointer.
When this context_gl is acquired again later, we will try to access
context_gl->c.swapchain->win_handle, thus complete the use-after-free cycle.
This commit makes sure the swapchain pointer of ALL front and back buffers are set to NULL before
decrementing their reference counts.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58325
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8406
I think this dates from a time where every window had its own window surface, and unless I'm missing something this isn't needed anymore. My intention is to refactor the client surfaces, so that they can be manipulated directly from win32u, and unify GL/VK client surfaces. This would make the code simpler, in preparation for that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8504
I noticed that if I Ctrl-C while makedep is re-generating the Makefile, the
Makefile will be gone.
There are two parts to this problem:
1. make deletes the output file if a rule is interrupted.
- Solution: use the special .PRECIOUS target.
2. wine_fn_output_makefile overwrites the existing Makefile, because makedep
is hardcoded to use the output makefile as its input.
- Solution: add a -i command line options to makedep for specifying the
input file name, then don't overwrite Makefile in wine_fn_output_makefile.
--
v2: configure: Don't nuke Makefile if makedep is interrupted.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8502