--
v5: mfplay/tests: Add MF_SD_LANGUAGE and MF_SD_STREAM_NAME value tests.
winegstreamer: Extract stream name from QT demuxer private data.
winegstreamer: Query stream tags and set MF_SD_LANGUAGE attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1542
--
v4: mfplay/tests: Add MF_SD_LANGUAGE and MF_SD_STREAM_NAME value tests.
winegstreamer: Extract stream name from QT demuxer private data.
winegstreamer: Query stream tags and set MF_SD_LANGUAGE attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1542
Implement a basic GC based on the mark-and-sweep algorithm, without requiring manually specifying "roots", which vastly simplifies the management. For now, it is triggered every 30 seconds since it last finished, on a new object initialization. Better heuristics could be used in the future.
The comments in the code should hopefully understand the high level logic of this approach without boilerplate details. I've tested it on FFXIV launcher (along with other patches from Proton to have it work) and it stops the massive memory leak successfully by itself, so at least it does its job properly. The second patch in the MR is just an optimization for a *very* common case.
For artificial testing, one could use something like:
```javascript
function leak() {
var a = {}, b = {};
a.b = b;
b.a = a;
}
```
which creates a circular ref and will leak when the function returns.
It also introduces and makes use of a "heap_stack", which prevents stack overflows on long chains.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1635
The pop-up dialog requesting installation of Mono can be an inconvenience when automating processes involving Wine. In some cases it's also helpful to be able to install a clean Wine prefix without having Mono auto-installed as part of the prefix initialisation. This MR adds environment variables allowing the user to prevent installation of the Mono and Gecko.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1661
commit 588e5554252 is preventing a 32-bit build on Mojave from finding the 32-bit libfreetype.so which I have in a non-standard location. I suspect that DYLD_FALLBACK_LIBRARY_PATH is somehow being lost.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1616#note_18434
This is in preparation of implementing all logic from the server in kernelbase, which is needed because Nt*Key ignores KEY_WOW64_32KEY. Unfortunately this requires a lot of server calls.
The full branch can be found here
https://gitlab.winehq.org/sbaars/wine/-/tree/shared-classes-new
The old approach that doesn't duplicate code to kernelbase can be found here
https://gitlab.winehq.org/sbaars/wine/-/tree/shared-classes-old
I ran make_requests by the way, not sure if we should still leave that out with the gitlab workflow.
--
v10: kernelbase: Always try to open the Wow6432Node in create_key()
kernelbase: Restructure the create_key() loop.
kernelbase: Add a fast path to create_key().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1445
--
v2: winspool: Call providor in ReadPrinter implementation.
localspl: Add ReadPrinter implementation.
localspl: Add support for Job handles.
localspl: Rename job_t structure to job_info_t.
localspl: Use separate structure to store printserver handles.
localspl: Use separate structure to store XcvPort and XcvMonitor handles.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1659
Also make the device instance id unique (at least to the bus), as required by MS. It is also easily addressable by other drivers.
--
v2: wineusb.sys: Add usbver, revision, busnum and portnum to PDO's instance id.
wineusb.sys: Implement DevClass compatible id for devices with multiple interfaces.
wineusb.sys: Pass interface and interface_index from the event data to the usb device data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1631
On Fri Dec 2 10:52:41 2022 +0000, Alexandre Julliard wrote:
> > I'm more optimistic about 8.0. Anyway, I wouldn't mind committing it
> if we need to. At the same time, since there is an active work on the
> final solution, we may as well wait a few days and see how it goes. Let
> me defer that to Alexandre (I think he took over that optimization work).
> I've committed some fixes inspired by Rémi's work. Hopefully that will
> be good enough to avoid the direct calls, can you please give it a try?
Hello,
I've compared a windows build of [vkoverhead](https://github.com/zmike/vkoverhead) test case 92, which uses descriptor buffers, on latest wine from git. I'm getting a score of around 48000 operations per second without this patch, and around 84000 with this patch using direct calls, so still almost a 2x difference. FWIW, a linux build without using wine gets around 320000 in the same test, all using the RADV vulkan driver.
I haven't tested it with actual games yet, but I expect it to still have a noticeable effect on CPU-bound games with vkd3d-proton.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18427
An array of pointers isn't conformant on 64-bit and will overrun the
destination buffer when unmarshalling. Since the purpose of this
function is to test a conformant FC_BOGUS_STRUCT, use one that is
conformant on both 32-bit and 64-bit.
The revised test coincidentally reveals that there is a problem with the
padding or alignment after a marshalled 16-bit enum, which will need to
be addressed separately.
Co-authored-by: Zebediah Figura <z.figura12(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1623
Cleaning up and splitting subheap creation helpers and free block merge logic.
Should be the last refactoring needed before LFH specific changes, as implemented in https://gitlab.winehq.org/wine/wine/-/merge_requests/1628.
--
v2: ntdll: Keep subheap parent heap pointer and check for mismatches.
ntdll: Move the insertion of the first block out of create_subheap.
ntdll: Split create_free_block into block_init_free / insert_free_block.
ntdll: Merge prev and next free heap blocks in heap_free_block.
ntdll: Split heap blocks before creating or resizing used block.
ntdll: Clear BLOCK_FLAG_PREV_FREE flag out of shrink_used_block.
ntdll: Move heap allocation and initialization into RtlCreateHeap.
ntdll: Split heap region memory allocation to allocate_region helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1629
The test for ISmbiosInformationStatics_get_SerialNumber is broken on Window 10 testbot VMs, presumably because they don't have a serial number? It results in an HRESULT of E_UNEXPECTED. I added a broken test case for it. I'm assuming that normal installations of Windows return a valid serial number or at least something like "Not Specified" and not NULL. Also, on my Linux OS running cat /sys/class/dmi/id/product_serial returns "To be filled by O.E.M". So I added a fallback to return 0 as the number. Or is it fine to just return whatever string is found?
On the Windows 8 VMs, the test crashes at line 75, hr = ISmbiosInformationStatics_get_SerialNumber( smbios_statics, &serial ). Not sure what I should do in this case. I was hoping for a flag that checks if the VM is Windows 8, but there doesn't seem to be one. Should I wrap the test in if (0) or is there an alternative way?
Another weird thing is the test fails prematurely on only the 32-bit version of debian11b, saying that the runtimeclass is not registered. I'm assuming it's an issue with the testbot. Debian11 32 bit runs fine.
--
v4: windows.system.profile.systemmanufacturers: Implement ISmbiosInformationStatics_get_SerialNumber.
windows.system.profile.systemmanufacturers/tests: Add ISmbiosInformationStatics_get_SerialNumber tests.
wbemprox: Provide accurate SMBIOS serial number.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1588
--
v3: winegstreamer: Implement media_object_SetInputType for WMV decoder.
winegstreamer: Add WMV support to wg_format.
mf/tests: Test IMediaObject_SetInputType for WMV decoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1529
--
v5: ntdll: Inline __wine_unix_call(_fast) dispatch in the syscall dispatcher.
ntdll: Restore frame in return path of the x86 syscall dispatchers.
winecrt0: Inline PE __wine_unix_call(_fast) function calls.
ntdll: Only save non-volatile FPU registers for -nofpu syscalls.
opengl32: Use __wine_unix_call_fast instead of __wine_unix_call.
ntdll: Introduce a new __wine_unix_call_fast syscall.
ntdll: Use -nofpu for NtQueryPerformanceCounter and NtYieldExecution.
winebuild: Introduce a new -nofpu syscall spec flag.
ntdll: Add support for syscall flags in the service CounterTable.
ntdll: Avoid double indirection to get x86_64 syscall_frame pointer.
ntdll: Check SYSCALL_HAVE_WRFSGSBASE syscall flag only for wrfsbase.
ntdll: Swap %eax and %edx registers in the i386 syscall dispatcher.
ntdll: Check syscall table and syscall number before saving FPU.
ntdll: Use named labels for jumps in the syscall dispatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1324
In preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1324.
This also begins preparation for a slightly different route than what the MR currently takes, with syscall flags eventually stored in the CounterTable rather than overusing syscall number unused bits.
To do that we're checking the syscall number and loading the syscall table (keeping it in %rbx/%ebx) earlier. This assumes that %rbx isn't modified in between, for instance by the eventual `SYS_arch_prctl` syscall, but I believe it is the case?
--
v2: ntdll: Check SYSCALL_HAVE_WRFSGSBASE syscall flag only for wrfsbase.
ntdll: Swap %eax and %edx registers in the i386 syscall dispatcher.
ntdll: Check syscall table and syscall number before saving FPU.
ntdll: Use named labels for jumps in the syscall dispatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1437
> I'm more optimistic about 8.0. Anyway, I wouldn't mind committing it if we need to. At the same time, since there is an active work on the final solution, we may as well wait a few days and see how it goes. Let me defer that to Alexandre (I think he took over that optimization work).
I've committed some fixes inspired by Rémi's work. Hopefully that will be good enough to avoid the direct calls, can you please give it a try?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18342
Because of padding at the end of the struct, sizeof(*view) is greater
than offsetof(struct memory_view, name[0]). Change the allocation to
overallocate slightly instead of underallocating slightly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1637
This MR implements memory mapping for wow64 using VK_EXT_external_memory_host. This has some problems (more below), but overall, it looks promising as a stopgap. It passes D3D tests and works fine in general.
For proper solution, we'd need a new Vulkan extension. I experimented with a prototype extension https://github.com/KhronosGroup/Vulkan-Docs/pull/1906 and it looks like we can make it work, my WIP implementation is here https://gitlab.winehq.org/jacek/wine/-/tree/vulkan-map-placed. However, it would be nice to have a fallback working on existing drivers as well.
The main problem of this MR is that it breaks Vulkan spec. The main rule it breaks is that according to spec, we should explicitly specify that we plan to use external memory when creating VkBuffer or VkImage. The problem is that we don't know if we will until we bind memory to the buffer. I tried some workarounds for that (delaying actual buffer creation, recreating buffer when needed). I got it mostly working and passing tests without validation errors, but it was more invasive than I'd like and still had other problems. I'd rather avoid that if possible.
After looking at Mesa sources, I think that the way this MR breaks the spec should be harmless for its drivers. I don't have the hardware to test with Nvidia. If it works there, I'm tempted to ignore spec violation for now, given that the right path forward is VK_EXT_map_memory_placed anyway.
Performance-wise, this MR is sub-optimal because we're limited in what memory types we can use. However, I ran Unigine benchmarks on radv and the difference was marginal. In case of Heaven, it was even slightly faster on wow64, which could be explained by 64-bit Vulkan driver being generally slightly faster, but the difference is too small to draw any conclusion.
The last patch is not meant for (eventual) merge, but it's nice for testing the concept. It makes it possible to force using external memory in any kind of Wine build to experiment with its effects without need for wow64. To test that, just set `WINEVULKAN_EXTERNAL_MEMORY` environment variable.
--
v5: winevulkan: Use VK_EXT_external_memory_host extension to map memory on wow64.
winevulkan: Wrap VkDeviceMemory.
winevulkan: Don't try to unwrap missing optional handle struct members.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1502
KeCancelTimer (which is called via KeSetTimerEx) would block indefinitely in the DPC, while waiting for the timer to complete. Which never happens, since the internal thread pool implementation never gets the chance to wake up the "finished_event" condition variable on the DPC exit in tp_object_execute().
--
v2: ntoskrnl.exe/tests: Test resetting a kernel timer in its DPC.
ntoskrnl.exe: Prevent blocking if timer is reset in DPC.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1559
The test for ISmbiosInformationStatics_get_SerialNumber is broken on Window 10 testbot VMs, presumably because they don't have a serial number? It results in an HRESULT of E_UNEXPECTED. I added a broken test case for it. I'm assuming that normal installations of Windows return a valid serial number or at least something like "Not Specified" and not NULL. Also, on my Linux OS running cat /sys/class/dmi/id/product_serial returns "To be filled by O.E.M". So I added a fallback to return 0 as the number. Or is it fine to just return whatever string is found?
On the Windows 8 VMs, the test crashes at line 75, hr = ISmbiosInformationStatics_get_SerialNumber( smbios_statics, &serial ). Not sure what I should do in this case. I was hoping for a flag that checks if the VM is Windows 8, but there doesn't seem to be one. Should I wrap the test in if (0) or is there an alternative way?
Another weird thing is the test fails prematurely on only the 32-bit version of debian11b, saying that the runtimeclass is not registered. I'm assuming it's an issue with the testbot. Debian11 32 bit runs fine.
--
v3: windows.system.profile.systemmanufacturers: Implement ISmbiosInformationStatics_get_SerialNumber.
windows.system.profile.systemmanufacturers/tests: Add ISmbiosInformationStatics_get_SerialNumber tests.
wbemprox: Provide accurate SMBIOS serial number.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1588
The latter is not guaranteed to be equal across events, and in practice may not be.
--
v2: winebus.sys: Search for added devices by devnode path in process_monitor_event().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1510
--
v2: winspool: Use providor for WritePrinter implementation.
winspool: Use providor for print jobs implementation.
localspl: Fix error handling in ScheduleJob.
localspl: Return error if cups port handle is used from different threads.
localspl: Add cups port extension.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1608
--
v3: mfplay/tests: Add MF_SD_LANGUAGE and MF_SD_STREAM_NAME value tests.
winegstreamer: Extract stream name from QT demuxer private data.
winegstreamer: Query stream tags and set MF_SD_LANGUAGE attribute.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1542
Required by Super Arcade Racing.
GetPointerInfo() can only succeed if WM_POINTER message are received, which can happen if there is a pointer device or EnableMouseInPointer(TRUE) is called. We don't currently send any WM_POINTER messages (and EnableMouseInPointer is a stub), so I hope adding a always failing stub won't break anything.
--
v2: user32: Add stub for GetPointerInfo().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1619