Fabian Maurer dark.shadow4@web.de writes:
If the problem is the initial environment, it would be hard to write a test, yes. FWIW my reading of that bug is that Windows behaves the same way, except maybe that the registry key order is different. I'm not sure there's anything to fix here.
Well, my manual tests show there definitely is a bug here, wine doesn't expand variables properly. I'll rework it and send in a proper test and fix.
On that matter, there's two ways we currently load variables from the environment:
- In kernel32 - process.c: set_registry_variables
- In userenv - userenv_main.c: CreateEnvironmentBlock -
set_registry_variables
Both seem to do approximately the same (and both need better expansion), so maybe we could have one logic there. But I need to look into that if that even makes sense. If that is the case, would a private exported function in kernel32 make sense, or how should I handle that? I mean, deduplication would make sense, no?
We don't want to add private exports to kernel32, and I don't think we want to have kernel32 depend on userenv, so keeping the duplication is preferable.