The LFH being automatically enabled after several allocations of the same sizes are done, its reallocation strategy differs from non-LFH blocks and was messing with the tests. I previously removed the HEAP_REALLOC_IN_PLACE_ONLY flag from LocalReAlloc, based on the test results, but the outcome is different when a non-LFH block size is used.
This adds more tests and restores the flag to fix the regression.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1613
This enabling will be done on a file basis (instead of directory) to ease review.
This serie contains "simple" file migration (mostly refcount and status/GetLastError())
changes.
I likely post afterwards each file change in a single MR to ease up review (and
potentially changes) without blocking the others.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1589
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.
--
v7: kernelbase: Factor creating a subkey out of create_key().
kernelbase: Use open_subkey() in create_key().
kernelbase: Always try to open the Wow6432Node in create_key()
kernelbase: Add a fast path to create_key().
kernelbase: Move create_key() below open_key().
kernelbase: Factor opening a subkey out of open_key().
kernelbase: Always try to open the Wow6432Node in open_key().
kernelbase: Restructure the open_key() loop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1445