Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57343
This is what the Java JRE installer does:
- It calls MsiInstallProductW - this opens the msi read/write
- The msi runs installer.exe
- installer.exe tries to open the msi readonly
--
v2: msi: Make MsiInstallProductW open msi readonly
msi/tests: Add test for MsiOpenDatabaseA during MsiInstallProductA
https://gitlab.winehq.org/wine/wine/-/merge_requests/6760
This should allow the CI to fully pass on this merge request.
If it does, master branch could have CI tests enabled to ensure
any actual broken test caused by a merge request is visible just
by the CI status, and master can also reflect the passing status.
Signed-off-by: Damien Zammit <damien(a)zamaudio.com>
--
v2: test-linux32: Disable broken tests that are already released broken
https://gitlab.winehq.org/wine/wine/-/merge_requests/7410
These invalid formats are rejected when creating WIC render targets. Otherwise, Wine may create a WIC render target with an unsupported format and in turn, will make testing IsSupported() method difficult.
--
v3: d2d1: Test creating WIC bitmap render targets.
d2d1: Reject unsupported formats when creating WIC bitmap render targets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1321
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
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v7: ntdll: Work around AMD SYSRET SS descriptor behavior on FreeBSD.
ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073