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.