Terminal Preview 1.3 breaks Windows PowerShell 5 (32-bit x86)'s history save and view and its command line colors

[metathinker]

Environment

Windows build number: Microsoft Windows [Version 10.0.19042.422] for x64
Windows Terminal version (if applicable): 1.3.2382.0

Using the default Terminal settings.json file and without any PowerShell profile files.

Steps to reproduce

1. Make sure that Windows Terminal Preview is registered to be run as wt.exe in Settings -> Apps -> Apps and features -> App execution aliases, and log out and log in if needed to make the setting fully take effect.
2. Run this command from Start -> Run: wt.exe "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"
3. Type get-help gv -ful with one L, press Tab.
4. Observe get-help gv -Full with 2 letters L, and the colors of that string.
5. Press Enter to run the command.
6. Exit Terminal and restart it using the same command you previously used in Start -> Run.
7. Press the up arrow key repeatedly.

Expected behavior

• In the get-help command you ran, get-help was in yellow and -Full was in a darker shade of gray than the other text.
• After relaunching Terminal, you could use the up arrow key to see your command history, including the get-help command you just ran.

Actual behavior

• In the get-help command, all the text was the same color.
• The command history was not accessible.
• If you now run PowerShell (x86) using the old console window, you see that the get-help command and other commands you ran in PowerShell within Terminal were not recorded in the history.

[DHowett]

This is absolutely wild. PSModulePath contains the unexpanded token, %ProgramFiles%, which gets either inherited fully-expanded (from Explorer or pre-1.3 WT) or inherited unexpanded (post-1.3 WT) and expanded at CreateProcess-time.

It looks like PowerShell (x86) has been working thanks to a fluke this whole time. Neat!

[paulomorgado]

The PSReadline module can't be found on 32-bit Windows PowerShell on Windows Terminal 1.3.

get-module -l | measure gives me a count of 143 on Windows Terminal 1.3 and 497 on Winodes Terminal 1.2 for PowerShell 32-bit.

On Windows Terminal 1.2 get-module -l shows modules from ´C:\Program Files\WindowsPowerShell\Modules` and C:\Program Files (x86)\WindowsPowerShell\Modules\ and on Windows Terminal 1.3 it only shows modules from C:\Program Files (x86)\WindowsPowerShell\Modules\.

[paulomorgado]

If I explicitly import C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1, it imports without any problems.

[DHowett]

It's very curious that PowerShell ships every module in both places except PSReadline. It is additionally concerning that this has simply worked forever (except perhaps there have been maybe ten users using weird configurations who have gotten the 32-bit module path and written it off as a fluke.)

We can fix this by expanding the environment variables in our newly-minted block before passing them off, but ... I'd like to understand how PowerShell expected this to work 😄

[zadjii-msft]

Summoning @SteveL-MSFT - Do you have any idea why PSReadline is the special case here?

[DHowett]

I'm reverting the environment fix for 1.3's move to stable this week because we do not otherwise have a good solution for this.

[iSazonov]

We can fix this by expanding the environment variables in our newly-minted block before passing them off, but ... I'd like to understand how PowerShell expected this to work 😄

Windows PowerShell (and pwsh too but code was a bit updated) expands env variables in PSModulePath internally.
I can find some GetModulePath methods here https://github.com/PowerShell/PowerShell/blob/c748652c34c3e208fad4d9b8abcf061b7f371c83/src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs#L731

So Windows Terminal has no need to expand env variables. I guess there was a bug in commit reverted.

[DHowett]

So Windows Terminal has no need to expand env variables.

Unfortunately, Terminal launches many, many things that are not PowerShell.

In general, though: Terminal is not expanding environment variables. It is using the system API¹ to generate a new environment block, which it then passes to the newly-spawned application.

On launch with a new system environment block, PowerShell x86 receives a module path that contains %ProgramFiles%. It then expands it, as you said. It is incorrect to do so: Powershell x86's module folder (Program Files (x86)\...) does not contain PSReadline.

When we use the old environment block, that value was already expanded, to C:\Program Files. That directory does contain PSReadline. Therefore, PowerShell x86 works fine.

¹ The public one, which is clearly incorrect.

[iSazonov]

@DHowett To be clear, PowerShell modify PSModulePath internally and write back to the process env block.
If we look in cmd.exe x64:

PSModulePath=C:\Program Files\WindowsPowerShell\Modules\;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;

If we look in cmd.exe x32:

PSModulePath=C:\Program Files\WindowsPowerShell\Modules\;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;

If we look in Windows PowerShell x64

C:\Program Files\WindowsPowerShell\Modules\;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

If we look in Windows PowerShell x32

C:\Program Files\WindowsPowerShell\Modules\;C:\Program Files (x86)\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;

As you can see, PowerShell add new paths before old ones.

You could run "broken" Windows Terminal version, start Windows PowerShell and run $env:PSModulePath to see real paths are used.
I guess you will see wrong result. It would be interesting to see the result.

[DHowett]

Indeed-

Here's my PSModulePath:

Here's what CMD Says:

and of course, here's what PowerShell x86 says:

And for good measure:

Anyway, that's the central thesis of this issue. When PowerShell x86 expands ProgramFiles, it gets the x86 program files. That's totally by design.

When PowerShell (x86) is launched from Explorer, it never sees %ProgramFiles%. It was already expanded by the time it was launched.

When PowerShell (x86) is launched from Task Manager it has the same problem as Terminal (!).

---

As noted on Aug 26, 2020... "PowerShell x86 has been working properly due to a fluke this whole time"

[iSazonov]

When PowerShell (x86) is launched from Task Manager it has the same problem as Terminal (!).

Ah! Thanks! Now I can reproduce. Although it has nothing to do with this issue at all :-))))) This is the rare case when a simple problem suddenly cloudes our understanding.

What is the user really ask in the issue? - "Why I can not load x86 dll in x64 process?"
Answer: because it is fundamentally impossible!

Should I add more words? :-) Ok!

PS modules can contain dll-s.
The dll-s can be x64 and only right place for them is %Program Files%.
The dll-s can be x86 and only right place for them is %Program Files x86%.
PS x64 must load dll-s from %Program Files% and must not from %Program Files x86%.
PS x32 must load dll-s from %Program Files x86% and must not from %Program Files%.

So for the issue answer should be:
It is neither WT bug nor PowerShell bug. It is by-design. Users must install PSReadline module from PS x86 process to get it work. It is true for other (x86 or platform independent) modules too.

PS: pwsh works the same.

[DHowett]

Ah, but here's the catch!

Open up a working x86 PowerShell and ask it where PSReadline has been loaded from.

PSReadline is an architecture-agnostic .NET assembly with no native PAL DLL!

When x86 PowerShell accidentally loads the "x64" PowerShell's PSReadline, it works properly. That's how the issue of the module path expansion has been hiding this whole time.

[iSazonov]

PSReadline is an architecture-agnostic .NET assembly with no native PAL DLL!

Yes, most modules are like that. I don't even know if we can find a module that is x86 :-) Now everything is x64. So we shouldn't even ask PS x86 to be smarter.

[iSazonov]

And I think you can bring back the reverted commit so that we get more useful feature than that PS x86 by-design issue workaround.

[DHowett]

And I think you can bring back the reverted commit so that we get more useful feature than that PS x86 by-design issue workaround.

Unfortunately, any shell breaking when launched by Terminal when it doesn't break when launched by Explorer (Start Menu, Run dialog, desktop shortcut) is an unacceptable failure case for us! We want to make the console experience on Windows better, not worse. 😄

Like... if it didn't break the first thing a user would do with the shell (like, type a command...) I would be more forgiving. But no- we need to do our best to make the out of box experience perfect.

[iSazonov]

I see your point. But:

• using PS x86 is an edge case today - a small number of users have to use it.
• it is exclusively PS x86 issue
• the issue has clear and simple fix - copy PSReadline folder :-)

You could add a workaround in WT itself (run by cmd.exe?).

But the main thing is that you give up a really useful feature that is needed by a large number of users.

[ghost]

🎉This issue was addressed in #12140, which has now been successfully released as Windows Terminal Preview v1.13.10336.0.:tada:

Handy links:

• Release Notes
• Store Download