I there a way to force Windows to use PS 7 instead of the old 5?

AlterNate37 · Monday at 7:03 PM

Hi,

because of other issues which I'm addressing in another thread I've realized that in my System there is Windows Powershell 5.1, and PowerShell (Core?) 7.5.
When I installed PS7 I've used Chris Titus Utility to make it be the default PS, but it doesn't seem to have worked.
When I evoke PS from Win+X by clicking on "Windows PowerShell (Admin)" (or also the non admin) what opens is the older PS, which has a lighter blue icon.
The new PS is triggered by default only in Terminal.

I was told that trying to forcibly uninstall PS5 can mess up the system. I was told that eventually I can try renaming the exe of PS5 so it can't be triggered anymore, but I wonder if that means that nothing would be triggered or that the system would automatically look for PS7.

I wish to reach two things:
1. that every and each single time where the system or some program needs to run PS, they'll evoke PS7 and not PS5. Or at least that they do whenever possible.
2. that all entries about PS in Win+X are about PS7 and not PS5, or at least that both of them are present (if it's not possible to have only PS7).

How do I achieve that?

I've tried removing PS5 in the environment variables, and pushing up PS7. No idea if I did it properly, but it doesn't seem to be having any effect.

Thanx

garlin · Monday at 8:00 PM

It's a common mistake for a non-programmer to believe PowerShell 7 replaces PowerShell 5.1.

Both versions are designed to run side by side, and PS7 is not considered a "direct replacement" for PS5. Just like you can have multiple versions of .NET and Visual C++ Runtime on the same Windows. And CMD shell is still around for those scripts which need it.

1. PS5 is executed by calling "powershell.exe", and PS7 is "pwsh.exe". They are deliberately different.

Code:

powershell.exe -f myscript.ps1
pwsh.exe -f myscript.ps1

2. Some library features are only available in PS5, and others only exist in PS7. If a PS script absolutely needs to run on a specific version, it can add "#Requires -Version 7" on the first line. PS5 was originally written specifically to run on Windows, and PS7 was made host-independent and is available for both Windows and Linux.

3. Both of them have separate PS Module paths and profiles.

4. Removing PS5 will break some Windows functionality, as a number of scripts exist which expect powershell.exe to be present.

5. What you can do is change your preference between them in the Terminal app. PS5 is referred to as "Windows PowerShell", and PS7 is known as "PowerShell".

6. You can modify the Win+X shortcut, under folder %LocalAppdata%\Microsoft\Windows\WinX\Group3.

AlterNate37 · Monday at 8:29 PM

garlin said:
If a PS script absolutely needs to run on a specific version

Well, that's what I meant too: what if a script does not require to run specifically on PS5?
In a case like that, what can I do to ensure that the system will give preference to PS7?
Environment Variable?
Some tweak in Gpedit or Regedit?
Some PS code with permanent effect?
A utility?

I just want that whenever PS5 isn't absolutely needed it stays put, and PS7 goes on stage instead.

Thanx for the Win+X trick, I'll try it immediately.

pseymour · Monday at 8:44 PM

Both versions are designed to run side by side, and PS7 is not considered a "direct replacement" for PS5. Just like you can have multiple versions of .NET and Visual C++ Runtime on the same Windows. And CMD shell is still around for those scripts which need it.

When I say PowerShell below, I mean the newer host, pwsh. Windows PowerShell refers to the "classic" host, powershell.exe.

garlin's quote hints at the actual reason for the separation: Windows PowerShell is based on .NET Framework, and PowerShell is based on .NET (what used to be called .NET Core). The two .NETs have a lot in common, but they are not the same. Modules and such built for Windows PowerShell may indeed work on PowerShell, but one cannot assume that. They have to be tested and then put into PowerShell's modules folder, for example.

garlin · Monday at 8:52 PM

Why do you need to force one version for all running PS instances? There's a brute-force way to do that, but it's discouraged because you can silently break things without realizing it.

Most of the time when you interact with PS, it's whatever version that's launched from the Start Menu, a desktop shortcut or from Terminal. If you're configuring a shortcut or a command to run, you instinctly type "C:\Program Files\PowerShell\7\pwsh.exe" or "pwsh.exe" whenever someone references old powershell.exe.

If you want to run with scissors:

Code:

Windows Registry Editor Version 5.00

[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\powershell.exe]
"Debugger"="C\\Program Files\\PowerShell\\7\\pwsh.exe"

Code:

Windows Registry Editor Version 5.00

[-HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\powershell.exe]

AlterNate37 · Monday at 9:00 PM

garlin said:
Why do you need to force one version for all running PS instances?

If you want to run with scissors:

Can you explain what those scissor codes there do exactly? So I can choose if running with scissors or with wolves.

Anyway I don't want to "force" PS7 always.
I want it to be the preferred choice anytime that the system or some third-party something will need to run PS but will not need a specific version of it.
I want to set the system so that in those cases it will be PS7 to be used.

And when PS5 is specifically needed, it should be that to run.

Is this possible and how?

AlterNate37 · Monday at 9:13 PM

Btw my Powershell 5.1 32bit isn't working.
Not to open a new thread just for that I'll ask here: is there a way to repair it or reinstall it?
I only find WMF but it's for other Windows.
I didn't find any download of PS5.1 or WMF5.1 for Windows11.
Maybe a DISM command to repair specifically PS5.1 without having to do the whole restorehealth?
Or WinGet?

If anybody knows, let me know

LesFerch · Monday at 9:16 PM

AlterNate37 said:
Anyway I don't want to "force" PS7 always.
I want it to be the preferred choice anytime that the system or some third-party something will need to run PS but will not need a specific version of it.

Thousands of scripts exist that assume the default is PowerShell.exe and will break with pwsh.exe. Pwsh.exe should never be set as the default for all scripts. If a script is written to only work with pwsh.exe it will usually check the version (or at least it will be mentioned in a readme). You won't often find it the other way around.

As already mentioned, it's fine to set PowerShell Core as your default for Terminal.

AlterNate37 · Monday at 9:33 PM

LesFerch said:
Thousands of scripts exist that assume the default is PowerShell.exe and will break with pwsh.exe. Pwsh.exe should never be set as the default for all scripts.

I think that we might be talking of different things without realizing, because we have different level of knowledge about Windows.

Let's bring out the things we take for granted, so that we can check if the other person takes for granted the same things.

I take for granted that:

If a script specifically needs PowerShell.exe or Pwsh.exe it will specifically ask for it (and I'm not trying to change or bypass this, nor force something else)
If a script does NOT specifically need PowerShell.exe or Pwsh.exe it won't mind if I run it on Pwsh.exe
It's possible to set the system so that those scripts which do NOT specifically need one of the two PS will use Pwsh, without preventing those script which specifically need PowerShell from using PowerShell

If any of that is not correct, let me know.
Otherwise I'd still want to have a way to achieve what written in the last point, as it would not create any issue to e.g. scripts like your WinSetView (which would still be able to "call" PowerShell.exe -hopefully soon the 64bit version).

LesFerch · Monday at 9:44 PM

AlterNate37 said:
If a script specifically needs PowerShell.exe or Pwsh.exe it will specifically ask for it

Not correct. Most PowerShell scripts will get interpreted by whatever version of PowerShell is the default for running PS1 files. Of course, if the script is run by another process, that process can specify powershell.exe or pwsh.exe but it doesn't have to.

Edit: There isn't a default interpreter for PS1 files. You cannot double-click PS1 files. You have to right-click and "Run with PowerShell" or open a PowerShell window and run the script. However, you could set an Image File Execution option (as noted by @garlin) so that "Run with PowerShell" runs pwsh.exe instead of powershell.exe, but that would not be a good idea.

Since PowerShell.exe existed long before pwsh.exe, changing the default (via IFEO) is guaranteed to be a problem at some point. It could only work correctly if pwsh.exe were 100% backwards compatible with powershell.exe. It definitely is not.

AlterNate37 · Monday at 9:51 PM

LesFerch said:
Not correct. Most PowerShell scripts will get interpreted by whatever version of PowerShell is the default for running PS1 files. Of course, if the script is run by another process, that process can specify powershell.exe or pwsh.exe but it doesn't have to. Since PowerShell.exe existed long before pwsh.exe, changing the default is guaranteed to be a problem at some point. It could only work correctly if pwsh.exe were 100% backwards compatible with powershell.exe. It definitely is not.

So, I can set PS7 as default in Terminal because terminal is only used manually but not "called" by scripts, but I can't set PS7 as default system wide because there isn't a way to do that without preventing scripts which need PS5 from using PS5?

LesFerch · Monday at 9:55 PM

AlterNate37 said:
So, I can set PS7 as default in Terminal because terminal is only used manually but not "called" by scripts, but I can't set PS7 as default system wide because there isn't a way to do that without preventing scripts which need PS5 from using PS5?

Yup.

AlterNate37 · Monday at 10:12 PM

should I mark this as solved even if it's not "solved" like in "I got what I wanted"?
What's the etiquette in this forum about it?

garlin · Monday at 10:13 PM

The thing to realize is Windows (by design) doesn't associate a specific PS interpreter or File Type Association for .ps1 files.

This forces any instance of trying to run a PS script to have some part of Windows explicitly declare it's choosing powershell.exe or pwsh.exe. When you're calling a script from running one of the two PowerShell's as your command shell, you've already made that choice.

But you can override which PS is used on a per-script instance.

Code:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\GARLIN> pwsh -f myscript.ps1

Code:

PowerShell 7.5.0
PS C:\Windows\System32> powershell -f myscript.ps1

AlterNate37 · Monday at 10:37 PM

garlin said:
When you're calling a script from running one of the two PowerShell's as your command shell, you've already made that choice.

What about when the script is not run by me from within a PS session, but e.g. when a windows feature triggers the script, or while using third-party utilities like LesFerch's WinSetView?

Your sentence about "some part of Windows explicitly declare it's choosing powershell.exe or pwsh.exe" seems implying that there's no such a thing as a "default PS for PS1 scripts" registered somewhere in the system.
And so I'm now again wondering if it's possible to set Pwsh as default in a permanent way, or if this would be problematic because programmers take for granted that we didn't change the default PS for PS1 and they won't include in their scripts an instruction to specifically choose PowerShell.exe?

garlin said:
But you can override which PS is used on a per-script instance

I didn't understand how to use those two codes, can you explain?

garlin · Monday at 10:50 PM

The first registry file uses Image File Execution Options (IFEO) as a brute force way to make Windows to substitute another command whenever "powershell.exe" is called. In this case, replaced by "pwsh.exe". Whatever process is calling powershell doesn't know the difference, it believes the command executed as it request.

Copy the file into Notepad, save to a filename with ".reg" extension. Double-click on the file in Explorer, Windows will ask you if approve of modifying the Registry.

The second reg file undoes the previous change.

You'll have to ask @LesFerch about his script.

LesFerch · Monday at 10:59 PM

AlterNate37 said:
I didn't understand how to use those two codes, can you explain?

@garlin was just showing that you can explicitly run powershell.exe or pwsh.exe to run either PowerShell or PowerShell Core.

WinSetView explicitly runs powershell.exe, but, as noted, the System will automatically run the 32 bit version from SysWOW64 because WinSetView.exe runs as a 32 bit process.

If you were to redirect all attempts to run powershell.exe to pwsh.exe using IFEO, as noted by @garlin, WinSetView would still work because the WinSetView.ps1 script is compatible with PowerShell Core, but that's not typical. A lot of scripts will break.

I stand corrected in regards to PS1 file association, but the fact that it works in a more subtle way doesn't change the recommendations.

AlterNate37 · Monday at 11:39 PM

garlin said:
The first registry file

I suppose I have to replace Garlin with my username and myscript with the name of whatever script I wanna try forcing to use pwsh?

I tried with LesFerch's WinSetView.ps1, so the code I saved was:

Code:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\UME³> pwsh -f WinSetView.ps1

(which btw, do I need to include all that stuff or can I just use the last line?)

When I double clicked on it after saving it as a reg file I got this:

garlin said:
You'll have to ask @LesFerch about his script.

Sure, although I named his tool just as an example.
My question was in general: when can I use your registry trick?
From what I had understood from LesFerch, there's a system wide default PS for PS1 and that's Windows PowerShell, but you said that there is no such a thing, and I am wondering how does "some part of Windows explicitly declare it's choosing powershell.exe or pwsh.exe" if there's no default PS interpreter for PS1 files.
I can only presume that programmers will have to set their script to automatically choose either powershell.exe or pwsh.exe.
And there I wonder: what happens if a script has been made to automatically trigger powershell.exe but I use your reg trick to have the system use pwsh.exe instead?
If there a predictable outcome or would it depend on each case?

And could you confirm that there isn't a more system wide (vs per-script) way to set pwsh.exe as default ONLY for the scripts which don't specify what PS they want to use?
If that'd be possible, I'd think it's the most acceptable compromise for me. Because if like you say there's no such a thing as a default PS interpeter, this means that if a script can only work with powershell.exe the programmer would make sure that it triggers powershell.exe.
So, a tweak like the one I'm wishing for, would not override that.

pseymour · Monday at 11:45 PM

AlterNate37 said:
Because if like you say there's no such a thing as a default PS interpeter, this means that if a script can only work with powershell.exe the programmer would make sure that it triggers powershell.exe

That just isn’t how it works, period. Scripts were written for Windows PowerShell well before the cross-platform host existed. Windows PowerShell predates PowerShell by 10 years, give or take.

AlterNate37 · Monday at 11:46 PM

LesFerch said:
If you were to redirect all attempts to run powershell.exe to pwsh.exe using IFEO, WinSetView would still work because the WinSetView.ps1 script is compatible with PowerShell Core

Sorry, I got lost, what's IFEO?

Anyway like I just wrote, I tried Garlin's trick with WinSetView.ps1 but I got that popup.

I there a way to force Windows to use PS 7 instead of the old 5?

Member

My Computer

Well-known member

My Computer

Member

My Computer

Windows developer and admіn

My Computers

Well-known member

My Computer

Member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Member

My Computer

Windows developer and admіn

My Computers

Member

My Computer

Similar threads