[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