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