[PATCH 1/2] ntdll/tests: Refactor RtlSetEnvironmentVariable() tests.

[Dmitry Timoshkov]

Alexandre Julliard <julliard at winehq.org> wrote:

> Dmitry Timoshkov <dmitry at baikal.ru> writes:
> 
> > Gijs Vermeulen <gijsvrm at gmail.com> wrote:
> >
> >> Op wo 21 apr. 2021 om 21:14 schreef Dmitry Timoshkov <dmitry at baikal.ru>:
> >> 
> >> > Removing dynamic loading of ntdll APIs will unnecessarily break building
> >> > the tests with older PSDK versions, in particular Windows 7/8 ones. I'm
> >> > occasionally use Windows 7 to test things, I'd appreciate if building
> >> > under that platform keeps working.
> >> >
> >>  Isn't this already the case? (i.e. RtlInitUnicodeString in set_env_var()
> >> and RtlSetCurrentEnvironment in test_RtlSetCurrentEnvironment())
> >
> > I haven't built the ntdll tests for some time, so probably something went
> > in and broke things, however fixing a couple APIs is much less trouble than
> > dealing with completely broken test. Is keeping dynamic API loading something
> > that can't be left as it is, without making things worse? Honestly, it doesn't
> > require that much effort.
> 
> It does require some effort, because there's no way of testing it in
> standard setups, so it gets constantly broken and needs to be fixed up
> after the fact. And it's clearly not that important to you either if you
> didn't bother to fix the previous breakages.

As I've mentioned, I compile the ntdll tests under Windows 7 occasionally,
I didn't claim that I promise to continuously monitor the tests for breakages.
Still, it's nice to spend less effort when it comes to building the tests.

> AFAICT the env.c test would have been broken for a year, and the ntdll
> tests as a whole for at least five years now. So you can't demand that
> everybody do extra work for something that you don't seem to be actually
> using.

I hope that I asked nicely enough, and didn't ask that much, I wouldn't
call this as a demand. I think that it doesn't count as an extra work
simply keeping existing API pointers.

-- 
Dmitry.