- wine-gitlab - winehq.org

[PATCH v3 0/5] MR4142: Cleanup passing info from dbghelp to WineDbg.
by eric pouech (＠epo) 16 Nov '23

16 Nov '23

We used to have some hack for passing information (mainlyi module related ones) from dbghelp to WineDbg. This series: - reimplements properly the sharing, introducing a Wine entrypoint to dbghelp (sharing debug formats not handled by native, no longer decorating module names for sharing that module was in fact a host module...) - improves "info share" command in WineDbg with more accurate information (host module type...) - improves loading time on MacOs (some system libraries no longer have their images accessible directly on disk by standard file operation). -- v3: dbghelp: Pretend mach-o is present in case of failure. dbghelp: Expose PE native vs builtin information to winedbg. dbghelp,winedbg: No longer decorate ELF/Mach-O module names. dbghelp: Expose some internal information about modules to winedbg. dbghelp: Remove DMT_ entries for .DBG and .PDB files. https://gitlab.winehq.org/wine/wine/-/merge_requests/4142

3 7

[PATCH 0/3] MR4412: shell32: Improve FolderView2::GetViewModeAndIconSize() stub.
by Dmitry Timoshkov (＠dmitry) 16 Nov '23

16 Nov '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4412

2 3

[PATCH v3 0/4] MR4377: Reimplement msvcrt env functions to match native.
by eric pouech (＠epo) 16 Nov '23

16 Nov '23

This serie: - adds a couple of msvcrt env tests (mainly env block inheritance) - introduces env tests for ucrtbase - reimplement most of the env related functions to mimic native behavior (basically when env is modified, native crt uses a per-variable entry allocation block (instead of having pointers inside a single chunk of memory). This fixes programs which keep a pointer on returned getenv() string and expect that pointer content is not modified when other variables in env are modified. @piotr: from previous version - I dropped the synchronization of \_environ and \_wenviron hence requiring the duplication of most of the code in ansi/unicode versions - I also tested the changes with unicode crt startup code (you can find in [1] this MR extended with this test code but I don't think we want to push it upstream) - there are some init code changes because of ucrtbase tests and unicode crt startup tests [1] https://gitlab.winehq.org/epo/wine/-/tree/mr-crt-env-full?ref_type=heads -- v3: msvcrt: Fix ucrtbase environment initialization. msvcrt: Reimplement environ related functions. ucrtbase/tests: Introduce environment tests. msvcrt/tests: Test passing environment in child process. https://gitlab.winehq.org/wine/wine/-/merge_requests/4377

3 6

[PATCH v2 0/2] MR478: vkd3d-shader/hlsl: Parse integers with the 'u' postfix.
by Francisco Casas (＠fcasas) 16 Nov '23

16 Nov '23

-- v2: vkd3d-shader/hlsl: Parse integers with the 'u' postfix. tests: Test integers with the 'u' postfix. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/478

3 3

[PATCH 0/2] MR478: vkd3d-shader/hlsl: Parse integers with the 'u' postfix.
by Francisco Casas (＠fcasas) 16 Nov '23

16 Nov '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/478

3 4

[PATCH v8 0/1] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) 16 Nov '23

16 Nov '23

This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC. Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency The last comment also suggests querying the above registry key for the TSC. To my understanding the calibration code has been successfully in use for some time now without any known issues. I tried to be as faithful to the original history as possible with separating out my changes into their own commits. If everything should be squashed to be prettier, just let me know! FYI @rbernon -- v8: wineboot: Compute and write the TSC frequency to registry ~Mhz. https://gitlab.winehq.org/wine/wine/-/merge_requests/4409

2 4

[PATCH v6 0/6] MR471: vkd3d-shader/dxil: Implement the DXIL GEP and LOAD instructions.
by Conor McCarthy (＠cmccarthy) 16 Nov '23

16 Nov '23

-- v6: vkd3d-shader/dxil: Implement the DXIL LOAD instruction. vkd3d-shader/dxil: Implement the DXIL GEP instruction. vkd3d-shader/dxil: Support global variable initialisers. vkd3d-shader/dxil: Introduce a value type for immediate constant buffers. vkd3d-shader/dxil: Implement default address space global variables. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471

3 13

[PATCH v7 0/1] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) 16 Nov '23

16 Nov '23

This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC. Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency The last comment also suggests querying the above registry key for the TSC. To my understanding the calibration code has been successfully in use for some time now without any known issues. I tried to be as faithful to the original history as possible with separating out my changes into their own commits. If everything should be squashed to be prettier, just let me know! FYI @rbernon -- v7: wineboot: Compute and write the TSC frequency to registry ~Mhz. https://gitlab.winehq.org/wine/wine/-/merge_requests/4409

2 1

[PATCH v6 0/1] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) 16 Nov '23

16 Nov '23

This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC. Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency The last comment also suggests querying the above registry key for the TSC. To my understanding the calibration code has been successfully in use for some time now without any known issues. I tried to be as faithful to the original history as possible with separating out my changes into their own commits. If everything should be squashed to be prettier, just let me know! FYI @rbernon -- v6: wineboot: Compute and write the TSC frequency to registry ~Mhz. https://gitlab.winehq.org/wine/wine/-/merge_requests/4409

2 1

[PATCH v5 0/3] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) 16 Nov '23

16 Nov '23

This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC. Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency The last comment also suggests querying the above registry key for the TSC. To my understanding the calibration code has been successfully in use for some time now without any known issues. I tried to be as faithful to the original history as possible with separating out my changes into their own commits. If everything should be squashed to be prettier, just let me know! FYI @rbernon -- v5: Apply 1 suggestion(s) to 1 file(s) https://gitlab.winehq.org/wine/wine/-/merge_requests/4409

2 3

2025

2024

2023

2022

wine-gitlab