[PATCH] ntdll: Expand environment variables when querying them
Alexandre Julliard
julliard at winehq.org
Wed Mar 27 14:12:12 CDT 2019
Fabian Maurer <dark.shadow4 at 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:
> 1) In kernel32 - process.c: set_registry_variables
> 2) 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.
--
Alexandre Julliard
julliard at winehq.org
More information about the wine-devel
mailing list