Unfortunately this patch seems to be causing Wine to crash, at least on macOS Ventura and Monterey. After the preloader loads the wine loader, `environ` in the loader is NULL for some reason.
I'm still looking into this, but as a quick hack, using `*(NSGetEnviron())` (and including `<crt_externs.h>`) instead of `environ` in main() works.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1396#note_17218
Also unifies hidden file handling.
Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826).
--
v12: ntdll: Try to avoid requesting the file name for a handle.
ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file.
ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match.
ntdll: Only infer hidden attribute from file name if xattr is not present.
ntdll: Handle hidden file names in fd_get_file_info.
ntdll: Pass file path into fd_get_file_info if available.
ntdll: Do not compute file attributes for info classes that don't need them.
ntdll: Handle hidden file names inside get_file_info instead of after it.
ntdll: Do not open-code hidden file handling in get_dir_data_entry.
ntdll/tests: Add test for file attributes of files with names beginning with a dot.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1148
The first two patches are mostly needed to make wmic.exe work on Windows as well for easier testing and distinguishing between wmic.exe bugs and underlying libraries bugs (although it also makes sense not to depend on wbemprox implementation differences in Wine).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1527
When f7332ab4a6e199d03e4318d82c0b16a0396b935c switched load_so_dll
over to a proper Unix syscall, ntdll.so started providing the
symbol __wine_unix_call_funcs.
When a DLL calls NtQueryVirtualMemory(MemoryWineUnixFuncs), it can
do so speculatively, not knowing whether the corresponding unix
lib actually does provide anything.
When ntdll.so started providing this symbol, then such speculative
calls to NtQueryVirtualMemory(MemoryWineUnixFuncs) would end up
returning ntdll's __wine_unix_call_funcs if the intended DLL's
unix library lacked one.
This is the case with bcrypt, where the unix library doesn't
provide __wine_unix_call_funcs if gnutls is unavailable.
This fixes crashes after f7332ab4a6e199d03e4318d82c0b16a0396b935c,
in builds without gnutls.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
v2: ntdll: Avoid accidentally picking up ntdll's __wine_unix_call_funcs for other DLLs
https://gitlab.winehq.org/wine/wine/-/merge_requests/1525
When f7332ab4a6e199d03e4318d82c0b16a0396b935c switched load_so_dll
over to a proper Unix syscall, ntdll.so started providing the
symbol __wine_unix_call_funcs.
When a DLL calls NtQueryVirtualMemory(MemoryWineUnixFuncs), it can
do so speculatively, not knowing whether the corresponding unix
lib actually does provide anything.
When ntdll.so started providing this symbol, then such speculative
calls to NtQueryVirtualMemory(MemoryWineUnixFuncs) would end up
returning ntdll's __wine_unix_call_funcs if the intended DLL's
unix library lacked one.
This is the case with bcrypt, where the unix library doesn't
provide __wine_unix_call_funcs if gnutls is unavailable.
This fixes crashes after f7332ab4a6e199d03e4318d82c0b16a0396b935c,
in builds without gnutls.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1525
This will end up moving window around only if the old virtual screen
origin is different from the new one. Don't send unnecessary messages
if it didn't change.
This helps speeding up D3D tests on the testbot VMs with multiple
displays and hopefully solve the timeout problems.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1524