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
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
--
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
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
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
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
You most likely want to always use the script, not only for unknown locale.
For unknown countries we should probably fall back to neutral locale in all cases.
Also the user_locale variable needs to be updated.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357#note_52528