Nov. 8, 2023
5:21 p.m.
On Wed Nov 8 17:05:15 2023 +0000, eric pouech wrote:
> on the first point, I'd rather first test how \\\_winitenv is
> constructed. I derived it from \\\_environ\[\], but it could also well
> be directly from GetEnvironmentStringsW (using same logic as how
> \\\_initenv is created) (\*). If it's the case, that would likely solve
> the question about unicode variable names. (not sure yet if such a test
> can be kept around init testing, but I was thinking of something like:
> SetEnvironmentVariableW("foo"n "bar") before winitenv is created and
> check afterwards if foo is present in \\\_winitenv or \\\_wenviron, then
> it means it's derived from kernel data; otherwise from \_environ\[\]).
> for ucrtbase, I started looking at it. all the 4 env (ansi & unicode) +
> init seem to be created at startup (when dynamic linking ucrtbase,
> didn't try with static linking on MSVC). That's one difference from
> msvcrt (but this MR doesn't change this behavior). What's the best
> practice for sharing the tests between msvcrt and ucrtbase? (tests need
> adaptation as some APIs like \__getmainargs doesn't exist in ucrtbase)
1. What I really want to achieve here is to not break something that is currently working. If there is any version of msvcrXX that handles unicode environment variables correctly I want to preserve that to avoid regressions. Regarding testing it, if needed, it should be possible to test it with `CreateProcess` call with `lpEnvironment` argument.
2. There's currently no way of sharing the tests (so you will need to copy the tests).
Note that I don't think it all needs to be fixed so it's working exactly as in native. My concern is that proposed implementation looks risky in regard to A->W conversion.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4313#note_51538