Add draft of PS7 bootstrapper

[SteveL-MSFT]

This is the current thinking on being inbox in Windows

[awakecoding]

Is the goal of the PowerShell 7 to bootstrap an installation, or literally serve as a shim executable that is smaller than the complete installation, and will automatically bootstrap the installation on the first call, forwarding all the calls to an on-demand PowerShell installation?

I'm not entirely sure than an on-the-fly installation from a pwsh shim is a good idea, but I could be wrong. I would be very happy with a simple, in-box way to just get the latest and greatest PowerShell. I would stay away from solutions that just launch a child pwsh.exe to interact with it using standard input/output, this can only be flaky at best. Do not forget that we'd also need to correctly report back the child process exit code, etc.

However, if you want to pursue the pwsh shim idea, one thing I've already put some thought into would be to create a self-contained Rust executable and make it a PowerShell native host process. Here's the latest code Rust I have to do this: pwsh-host-rs. Since a Rust executable is easy to keep self-contained, and since the PowerShell native host does not rely on PowerShell or .NET, it can easily be improved to detect PowerShell and install it if necessary.

Even better: rather than deal with a subprocess, it can literally load PowerShell from the disk and become a full pwsh.exe replacement. This was actually the first prototype I did, where the only thing I did was launch the same entry point as the real pwsh.exe from my PowerShell native host process, but it would entirely run within the current process. All we'd need to do is pass it the same command-line parameters and it would be entirely transparent.

[LeonarddeR]

Have you considered the way WSL works in Windows 10/11? It is able to download distributions from the Windows Store, so it somehow behaves like a bootstrapper, right? Also, how are the WSL kernels tight to the lifecycle of Windows releases?

I'm not sure whether I follow the Admin vs. Non-Admins scenario yet. Are you suggesting that PowerShell 7 will be installed under the current user when pwsh is started non-elevated? I really think this is a scenario to avoid. Again, it makes sense tosee how bash behaves in this case.

[SteveL-MSFT]

@awakecoding I believe the RFC covers pwsh shim vs pwshup. I don't think they are mutually exclusive, so pwshup could be something we invest into in the future and would be cross-platform while this is Windows specific.

@leonardder this concept was taken from WSL. However, the Windows Store is not available on Server which is a motivation to go a slightly different route. WSL kernels (the Linux distro) is updated outside of Windows and wouldn't be affected by Windows lifecycle while WSL itself would be. Similarly, the pwsh shim would be under Windows lifecycle support, but not the installed PS7. As for admin vs non-admin, we need to support the case where the user is not admin and not require an admin to install.

[LeonarddeR]

@leonardder this concept was taken from WSL. However, the Windows Store is not available on Server which is a motivation to go a slightly different route.

Ah, so my assumption that WSL is able to install distros from the store on server is incorrect.

As for admin vs non-admin, we need to support the case where the user is not admin and not require an admin to install.

I see.

I have two other thoughts:

Updates

While I understand that the PWSH shim can be used to check for updates and keven keep it up to date, wouldn't it be better to just handle this by Windows Update, unless the currently installed version of PowerShell is out of date? To put it another way, why is relying on Windows Update unsufficient, apart from ensuring that we're on a supported version of .NET?

PowerShell vs .NET

Another concern is decoupling PowerShell from .NET. As far as I understand, every PowerShell release (e.g. 7.2) is tight to a particular release of .NET (6 in this case). Wouldn't it be interesting to have the .NET team on board for an installation strategy .NET would benefit from? E.g.

1. Have a dotnet shim together with a pwsh shim
2. The psh shim internally uses the dotnet shim to install a dotnet runtime and then installs PowerShell, preferably as a runtime dependant package.
3. As the pwsh shim calls the dotnet shim to ensure there's a runtime, both .NET and PowerShell can be kept up to date.

[awakecoding]

Regarding the pwsh shim, the best approach would be to use a PowerShell native host process instead of launching a pwsh subprocess. This is something I have done in the past, if you look close enough in my screenshot you'll see I'm using the pwsh command-line entirely in-process from a C program.

A cleaned up version of my PowerShell native host prototype was rewritten in Rust under the pwsh-host-rs project, which is what would be ideal to build a pwsh shim. It uses a helper function that was introduced in PowerShell 7.2 to avoid using files on disk other than vanilla PowerShell.

[Karl-WE]

Have you considered the way WSL works in Windows 10/11? It is able to download distributions from the Windows Store, so it somehow behaves like a bootstrapper, right? Also, how are the WSL kernels tight to the lifecycle of Windows releases?

Good questions about WSL. Some components included in Windows seem hard to be serviced. Naively I would not understand why it's not possible to patch them via CU. Example Windows Optional Feature of OpenSSH.

As you mentioned the store there unfortunately no store or business store or its future sub on Windows Server nor on Windows 10 LTSC.

Not to forget about the Windows Server Core Installation Option. On top of that Windows Server Core unfortunately cannot be joined to AAD due to missing dsregcmd.

If we had these modern options (doubt it will happen for some conceptual reasons) it could make things easier for PowerShell, winget, Windows Terminal and many other applications to be provisoned.

[iSazonov]

While bootstrapper looks technically interesting it is actually useless - I see no benefit for corporations or individuals.

Bootstrapper and the described process is contrary to experience. What did we have in the past? MSFT has released hundreds of updates continuously at unpredictable times. And where did we gradually come to? MSFT now releases single cumulative updates once a month or less for select products. Enterprises and individuals can plan update process. It is reasonable to ask whether the bootstrapper will be as reliable and secure as WU/MU? Obviously no, WU/MU is a large, complex, reliable and secure system, bootstrapper cannot compete with it. Enterprises use WU/MU over Internet directly or through WSUS or SCCM. They do not need just another channel of updates - for them this is an additional cost.

The question is WHAT exactly will be updated through WU. And if the goal is to have PS7+ on all Windows systems, then a reasonable question arises - for what? What are the benefits? Cross-platform? Then as Enterprise administrator I expect:

1. PS7+ can be automatically installed, updated and configured on all Windows systems by traditional means - implemented partially
2. All Microsoft modules are ported to PS7+ - implemented partially
3. PS7+ can be automatically installed, updated and configured on all Unix systems by traditional means - implemented partially
4. Remoting works crossplatform - not implemented at all
5. PS7+ is more small and more fast - no, it is large and more slow
6. PS7+ has features which "kill" Windows PowerShell - no

Looking at this, any IT department will reject the move to PS7. The absence of remoting is especially disagreeable. Without it PS7+ is a toy for Enterprises. If we talk about cross-platform as a benefit of PS7 +, then it is not enough to have PS7 + on all Windows systems - we need to have PS7 + on all Unix systems, and transparent remoting should work OOB on all platforms.

Let's get back to "The question is WHAT exactly will be updated through WU/MU." Now we see that we need to add Unixes and their update channels here. And the main thing remains - WHAT.

What does experience tell us? Windows PowerShell is distributed as WMF for years and this WMF has not always been in-box. See https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/overview?view=powershell-7.2

From this experience MSFT should release cross-platform WMF 7. This package may have a Windows-independent update cycle. WMF 7 possible content:

1. Mandatory component - .Net 7+
   • optional .Net components - ASP.NET Core, Entity Framework, Windows Forms, .NET MAUI, WCF, WPF, ...
2. PS 7+
3. Common modules
4. Common DSC classes
5. ...

It is important to have .Net as separate component in the WMF so that other applications can benefit. It does not prevent distribution of self-contained applications but allow other developers create and distribute small applications using shared .Net.

And WMF 7 should have Unix version too.

[sharpninja]

And WMF 7 should have Unix version too.

I would think this would make life at Azure's operations much better.

[essentialexch]

2. All Microsoft modules are ported to PS7+ - implemented partially

I know the PS Team doesn't care - but I curse PS 7 every time I try to use it and gwmi isn't there by default.

I'm curious as to what percentage of enterprises have migrated their corpus of 15+ years of PS 1-5 to PS 7.x? I expect it's quite small.

[Karl-WE]

from my perspective I do see good features in PS7. Have a look at network commands or *-service commands etc.

I do not see the need to have a package such as WMF 7, while it would be consistent with the experience we had. PS 7 can be easily deployed via MSI and updated WU etc. I often Windows Servers where WMF 5.1 is not installed, limiting remote manageability.

You mentioned there is no remoting, there is remoting but it is disabled by default, but could be enabled, isn't this the case?

[iSazonov]

You mentioned there is no remoting, there is remoting but it is disabled by default, but could be enabled, isn't this the case?

@Karl-WE If you ask me I wrote crossplatform remoting.

[daxian-dbw]

Remoting works crossplatform - not implemented at all

SSH remoting is a cross-platform remoting.

[Karl-WE]

You mentioned there is no remoting, there is remoting but it is disabled by default, but could be enabled, isn't this the case?

@Karl-WE If you ask me I wrote crossplatform remoting.

Given what I've seen how Systems get compromised with remote PowerShell from kali Linux to Windows using PS 5.1 I am not sure if cross platform remoting is feasible.

I can remember a request from icinga admins how they could connect via remote PowerShell, so it seems there are other usecases than this 😉

[SteveL-MSFT]

After some internal discussion, we're likely going to pursue a install-powershell type cmdlet instead of this bootstrapper primarily because it will be significantly less work for the team and almost the same result. RFC for that will come later.

[Karl-WE]

Thanks @SteveL-MSFT for the follow-up, would be glad to link the new RFC here so participants can review (if public).

[sharpninja]

After some internal discussion, we're likely going to pursue a install-powershell type cmdlet instead of this bootstrapper primarily because it will be significantly less work for the team and almost the same result. RFC for that will come later.

Please give an argument to install as a dotnet tool.