Note that the test is interactive since it requires a reboot (on windows) and a rerun on wine. AFAIK there's no way around those limitations, so this is the test I came up with.
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/ntdll/tests/env.c | 57 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+)
diff --git a/dlls/ntdll/tests/env.c b/dlls/ntdll/tests/env.c index 4e2ef8222d..41cb44ecd2 100644 --- a/dlls/ntdll/tests/env.c +++ b/dlls/ntdll/tests/env.c @@ -515,6 +515,59 @@ static void test_process_params(void) } }
+static BOOL setup_environment(void) +{ + HKEY key; + LSTATUS status; + LPCSTR value1 = "%WINETESTVAR2%"; + LPCSTR value2 = "test ok"; + BOOL is_ready; + const char *path = "System\CurrentControlSet\Control\Session Manager\Environment"; + status = RegOpenKeyExA(HKEY_LOCAL_MACHINE, path, 0, KEY_ALL_ACCESS, &key); + ok(status == ERROR_SUCCESS, "RegOpenKeyExA failed with %d\n", status); + + status = RegQueryValueExA(key, "WINETESTVAR1", NULL, NULL, NULL, NULL); + ok(status == ERROR_SUCCESS || status == ERROR_FILE_NOT_FOUND, "RegQueryValueExA failed with %d\n", status); + is_ready = (status == ERROR_SUCCESS); + if (!is_ready) + { + status = RegSetValueExA(key, "WINETESTVAR1", 0, REG_EXPAND_SZ,(LPBYTE)value1, strlen(value1) + 1); + ok(status == ERROR_SUCCESS, "RegSetValueExA failed with %d\n", status); + status = RegSetValueExA(key, "WINETESTVAR2", 0, REG_EXPAND_SZ,(LPBYTE)value2, strlen(value2) + 1); + ok(status == ERROR_SUCCESS, "RegSetValueExA failed with %d\n", status); + } + RegCloseKey(key); + + return is_ready; +} + +static void test_peb_environment(void) +{ + static const WCHAR result1[] = {'W','I','N','E','T','E','S','T','V','A','R','1','=','t','e','s','t',' ','o','k',0}; + static const WCHAR result2[] = {'W','I','N','E','T','E','S','T','V','A','R','2','=','t','e','s','t',' ','o','k',0}; + BOOL found1 = FALSE; + BOOL found2 = FALSE; + BOOL is_ready = setup_environment(); + if (is_ready) + { + WCHAR *env = NtCurrentTeb()->Peb->ProcessParameters->Environment; + for (; *env; env += lstrlenW(env) + 1) + { + if (lstrcmpW(env, result1) == 0) + found1 = TRUE; + if (lstrcmpW(env, result2) == 0) + found2 = TRUE; + } + todo_wine + ok(found1, "Didn't find %s in the PEB environment variables\n", wine_dbgstr_w(result1)); + ok(found2, "Didn't find %s in the PEB environment variables\n", wine_dbgstr_w(result2)); + } + else + { + skip("Preparation finished. Restart when running windows, then rerun the test for the results.\n"); + } +} + START_TEST(env) { HMODULE mod = GetModuleHandleA("ntdll.dll"); @@ -535,4 +588,8 @@ START_TEST(env) testSet(); testExpand(); test_process_params(); + if (winetest_interactive) + { + test_peb_environment(); + } } -- 2.21.0
Does it pick up updated registry values after WM_SETTINGCHANGE? New explorer child processes should get updated variables after such notification. Asking to reboot is unrealistic.
Does it pick up updated registry values after WM_SETTINGCHANGE? New explorer child processes should get updated variables after such notification.
Only partially. WM_SETTINGCHANGE or logout/login don't reproduce the effect I want to show with this test. To have environment variables updated out of order (i.e. not only expanded in alphabetical order), you have to do a reboot.
Asking to reboot is unrealistic.
I'm sorry, it's the only time this specific behavior is triggered.
Regards, Fabian Maurer
On 4/24/19 4:37 PM, Fabian Maurer wrote:
Does it pick up updated registry values after WM_SETTINGCHANGE? New explorer child processes should get updated variables after such notification.
Only partially. WM_SETTINGCHANGE or logout/login don't reproduce the effect I want to show with this test. To have environment variables updated out of order (i.e. not only expanded in alphabetical order), you have to do a reboot.
Asking to reboot is unrealistic.
I'm sorry, it's the only time this specific behavior is triggered.
That's fine for standalone test program that you can attach to bug report for example.
Having it in tests just adds a path that virtually will never be executed, that's what I'm saying.
Regards, Fabian Maurer
That's fine for standalone test program that you can attach to bug report for example.
Having it in tests just adds a path that virtually will never be executed, that's what I'm saying.
I'd still prefer to have it in the tests, that way it's easy available if you want to run it. I mean, it's an interactive test, they are meant to be run on demand, no?
Regards, Fabian Maurer