Feature request: rename PowerShell Core to UltraShell

[superbonaci]

Summary of the new feature / enhancement

PowerShell Core should be renamed to UltraShell, otherwise it's mistaken with Windows PowerShell. Since this project is not an update of the other (with full retro-compatibility) they shouldn't be called the same. It's a sort of impersonation and I feel is misleading for the non techie user. In fact I know most people is not aware they are different programs.

Proposed technical implementation details (optional)

No response

[iSazonov]

Since this project is not an update of the other (with full retro-compatibility) they shouldn't be called the same.

MSFT explicitly say that it is next version of PowerShell - Windows PowerShell version is 5 and PowerShell version was 6 and now 7.
Keeping compatibility is main priority.
No doubts PowerShell vNext will replace Windows PowerShell 5.1 in future.

[superbonaci]

I've opened several bugs due to script incompatibility between version 5 and 7 (#12446 #12443). Keeping compatibility "priority" is not any guarantee of any kind. It's like python2 and python3.

[jhoneill]

The names are "PowerShell" and "Windows PowerShell". The executables have different names pwsh vs PowerShell.

Neither of the examples you quoted are incompatibilities. - both are user errors an .EXE wasn't visible, and a script hadn't been installed (to the right place at least).

Genuine incompatibilities do exist, mostly with modules which require an earlier version of .NET - which has retained its name.

[superbonaci]

Neither of the examples you quoted are incompatibilities. - both are user errors an .EXE wasn't visible, and a script hadn't been installed (to the right place at least).

Check this one #16731

[jhoneill]

Neither of the examples you quoted are incompatibilities. - both are user errors an .EXE wasn't visible, and a script hadn't been installed (to the right place at least).

Check this one #16731

Pretty sure that depends on being on .NET Framework 4. You need to ask the person whose code you're cutting and pasting if they have a version for .NET 6.

[superbonaci]

Pretty sure that depends on being on .NET Framework 4. You need to ask the person whose code you're cutting and pasting if they have a version for .NET 6.

Can't the PowerShell script be set to use .NET Framework version 4, or to launch older versions of PowerShell? If I update for .NET 6 it will break backwards compatibility, while @iSazonov just said "Keeping compatibility is main priority". This is a mess and not well designed.

[vexx32]

Keeping compatibility with PowerShell scripts themselves as much as we can has been a priority, yes. However, you're talking about a .NET Core / .NET application being compatible with .NET Framework 4, which has been out of support for many years now (unless you mean 4.8, which I believe is the only version of 4.x still in support?).

.NET Framework applications and libraries are by and large simply not compatible with newer .NET versions; that's not something PowerShell can do anything about. If you want to run something under Windows PowerShell you can do so, and if you're shipping a module you can specify in the manifest that it only supports specific PowerShell versions or platforms.

If the module manifest does not specify supporting the Core edition of PowerShell, pwsh will typically attempt to load the module in 'windows compatibility mode', where it will actually load the module in Windows PowerShell and communicate between the processes to allow you to use it. This isn't perfect, but it's the closest you'll get without just running Windows PowerShell.

[superbonaci]

Also the shortcut should be renamed, from PowerShell 7 (x64).lnk to PowerShell Core 7 (x64).lnk (in this request PowerShell Ultra 7 (x64).lnk). Same for 32 bits version and other architectures.

[jhoneill]

Pretty sure that depends on being on .NET Framework 4. You need to ask the person whose code you're cutting and pasting if they have a version for .NET 6.

Can't the PowerShell script be set to use .NET Framework version 4, or to launch older versions of PowerShell? If I update for .NET 6 it will break backwards compatibility, while @iSazonov just said "Keeping compatibility is main priority". This is a mess and not well designed.

Windows PowerShell 5 is written and compiled for .NET Framework 4
PowerShell 7.2 is is written and compiled for .NET 6

No progress comes with absolute 100% guaranteed compatibility. People find old code on line that they don't understand, paste it into the current version and get upset that the two don't work together. 20 years after .NET was introduced I still hear people complaining that Microsoft should have stayed with VB6 (VB was only 7 years when the shift to .NET happened). Shifting from earlier version of .NET to the current cross platform and open source version has caused some pain. Progress isn't free, sadly.

Also the shortcut should be renamed, from PowerShell 7 (x64).lnk to PowerShell Core 7 (x64).lnk. Same for 32 bits version and other architectures.

Go back and read the documents about why the word "core" was removed when 6 became 7.

[superbonaci]

If I must read documents it means it's not intuitive. Hence I request it's renamed to Ultra or whatever, but not just PowerShell.

[ImportTaste]

I agree with the sentiment that dropping 'Core' from the title has made it confusing to properly distinguish between the two, but calling the project 'UltraShell' is just silly.

[doctordns]

At its heart, PowerShell 7 (aka PowerShell, aka PowerShell Core) is the same PowerShell that is in the core of Windows PowerShell. Cmdlets, objects, the pipeline - all work broadly the same (arguably some work better in PowerShell than in Windows PowerShell). IMHO, any further renaming is fruitless.

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.