Order of environment variables different in WT

[vefatica]

Environment

Microsoft Windows 10 Pro for Workstations
10.0.19042.804 (2009, 20H2)
Windows Terminal Preview
Version: 1.6.10412.0

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

See below.

Expected behavior

Same behavior whether in WT or not

Actual behavior

Behavior different and undesirable when in WT.

In my three Windows shells (CMD, Powershell, TCC), when running in WT

1. the environment block is ordered differently, and
2. new environment variables seem to go in the wrong place

Here's a new CMD.EXE running in a Windows console; this is expected behavior.

And here's a new CMD.EXE running in Windows Terminal. Note that the variables __VIP (from the user environment) and WT (newly created) are out of place.

[DHowett]

I do not believe that the order of environment variables is a contract anybody needs to uphold. WT requests that the system generate a new environment block for every new subprocess, so this is the order returned by the system.

[DHowett]

I'm marking this "Won't Fix". If you can provide a reason why this matters to any software, I'll be happy to reopen it 😄

[eryksun]

See Changing Environment Variables:

All strings in the environment block must be sorted alphabetically by name. The sort is case-insensitive, Unicode order, without regard to locale. Because the equal sign is a separator, it must not be used in the name of an environment variable.

One aspect left unstated by the above quote is that the case-insensitive comparison converts to uppercase. For example, 'A' (ordinal 65) and 'a' (ordinal 97) should sort before '_' (ordinal 95).

An incorrect order may cause GetEnvironmentVariableW and SetEnvironmentVariableW to misbehave, if they assume a particular sorted order when searching for and inserting variables. Hopefully they're more robust than that nowadays.

Windows Terminal calls _wcsicmp, which is locale based (limited to ASCII A-Z in the "C" locale) and converts to lowercase. The expected sort order is possible using CompareStringOrdinal.

[eryksun]

so this is the order returned by the system.

To be clear, it is not the order that CreateEnvironmentBlock returns. As shown by vefatica, it is also not the order used by SetEnvironmentVariableW, which inserts WT before __VIP in accordance with the expected uppercase, non-linguistic sort order.

[vefatica]

The behavior I mentioned seems to conflict with the documentation mentioned by @eryksun.

I don't know about upholding contracts, but what about tradition ... programs working as thay have for decades?

This just plain looks bad.

As for

why this matters

it makes environment variables hard to find when they're not where they're expected to be (and where they belong) in the list.

[vefatica]

I, too, have confirmed (as @eryksun alluded to) CreateEnvironmentBlock() puts __VIP at the end.

[vefatica]

Please reopen this issue.

[DHowett]

Huh, wild.

[vefatica]

Thank you!

[zadjii-msft]

This might've been fixed by #14999. We should double check. Maybe not, if we're still just dumping into an unordered map and then dumping back out.

Actually yea I'm gonna reckon it probably wasn't.

[ianjoneill]

This is fixed by #15082

[ianjoneill]

This might've been fixed by #14999. We should double check. Maybe not, if we're still just dumping into an unordered map and then dumping back out.

Actually yea I'm gonna reckon it probably wasn't.

The map was ordered, it was just ordered wrongly 🙂