Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en…
Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes.
With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded.
This is useful when a user has very long environment variables in their system for reasons unrelated to Wine.
Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941
Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6140
Normally Cyberpunk 2077 spawns #cpu_threads of dispatcher threads.
However with Freebsd, since create_logical_proc_info was a stub,
the game would instead spawn a single dispatcher thread, causing
the game to just crawl.
Working around the issue by adding a barebone implementation of
create_logical_proc_info for FreeBSD so that the game would at
least get a thread count through ntdll.
--
v2: Fix Cyberpunk 2077 spawning only one dispatcher thread in FreeBSD
https://gitlab.winehq.org/wine/wine/-/merge_requests/5213
Add Expat as a dependency, and use it to parse the XML returned from FreeBSD's kern.sched.topology_spec sysctl.
--
v6: ntdll: implement create_logical_proc_info on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7339
Salvage tests and fix a leak found in another review: see https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9175 points 1 and 2. 3. is why !897 was reverted.
This does not contain the (incorrect) changes to VariantCopyInd, but instead fixes the leak identified in VariantClear (VT_RECORD needs to free pvRecord), and the wrong allocator being used in VariantCopy (it should have been IMalloc, rather than `HeapAlloc`, as shown by the fact IMallocSpy observes these allocations).
This also cleans up some dubious behavior by the test IRecordInfoImpl, which was modifying a VARIANT that it did not own or receive as an argument in the middle of VariantClear. This was likely undefined behavior, and in any case concealed the heap leak.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1035