Add Windows7 support

[mrx23dot]

Description of the new feature / enhancement

Not everyone is going to upgrade to Windows 10, think older HW/third countries/industrial apps.

Admins still have to support these, even after MS dropped support.

Proposed technical implementation details

No response

[TreeBranches]

How do you expect this to happen when the Windows Store is not on Windows 7?

[mrx23dot]

winget install python golang

Is it hardcoded to use Windows Store? (is it just an empty cli interface for Windows Store?)

Or winget.exe could download the installer over https and run it in the background, without any MS login.

[Masamune3210]

The store isnt required at least to retrieve apps as msstore source isn't required. Getting the app and modifying the code to run on older versions of Windows is probably the issue more than the store part

[mrx23dot]

Well, github says it's written 86% in C++, it shouldn't be that hard to write portable code (even to compile it to 32bit, -m32),
path names have general format %APPDATA% etc.
Starting an installer is cmd.exe installer.exe parameters.
I guess you keep a database of installed apps in a .ini file, which is fully portable.
openssl lib can handle TLS 1.3 transfer.

[OfficialEsco]

Knew i've seen a similar question before #1020

Somewhat relatable #847

[RokeJulianLockhart]

This comment is response to "http://github.com/microsoft/winget-cli/issues/1686#issuecomment-980389836":

@ItzLevvie, MSIX is available for Windows 7 as "MSIXCore". Do observe "http://docs.microsoft.com/windows/msix/msix-core/msixcore" for verification of support.

[mrx23dot]

Not sure why the MSIXCore win+R restriction, "echo %appdata%" works great on local cmd.exe.
I also assume you would run WinGet as admin, which should be very close to win+R cmd.
Maybe if it changes system-env-vars you might need win+R, but Chocolately has a great script to reload them from normal cmd.exe.

There shouldn't be many win10 dependencies in WinGet to compile it to win7, I would imagine getting windows version and paths. Could someone try to compile it to win7 and share the compiler error log to see how much work is it?

What are the minimum .NET requirements for WinGet?

[sredna]

It looks like you can only run WinGet in Win + R

This is probably related to the alias. Win+R is ShellExecute which means it probably has registered an App Paths in the registry meaning start /b winget ... should work in cmd.exe or you can just modify %path% yourself.

[mrx23dot]

This should work in that case:

• setx PATH "C:\myfolder;%PATH%"
• Open a new cmd session. (As setx activates from new session)

Instead last step use this script in same window: https://github.com/chocolatey-archive/chocolatey/blob/master/src/redirects/RefreshEnv.cmd
from
https://stackoverflow.com/questions/46758437/how-to-refresh-the-environment-of-a-powershell-session-after-a-chocolatey-instal

[mrx23dot]

Wasn't the goal to build it on .NET which suppose to provides abstraction?

[Masamune3210]

You can only do so much abstraction before you require a specific feature from the system.

[denelon]

We will not be targeting below Windows 10 (1809).

[sskras]

@Masamune3210 commented on Nov 29, 2021:

You can only do so much abstraction before you require a specific feature from the system.

So what specific features does winget-cli need that are missing from Windows 7 ?

[TreeBranches]

@Masamune3210 commented on Nov 29, 2021:

You can only do so much abstraction before you require a specific feature from the system.

So what specific features does winget-cli need that are missing from Windows 7 ?

See here:
#1686 (comment)

[mrx23dot]

Isn't possible to read os version/type universally, without GetPackageFamilyName ?

[sskras]

@TreeBranches:

See here: #1686 (comment)

OK, it's the API for "Packaging, deployment, and query of Windows Store apps".
Do you mean it's the only feature that is missing on w7 ?

[sredna]

Isn't possible to read os version/type universally, without GetPackageFamilyName

Windows 7 does not support UWP/SparsePackage so all they would have to do is use GetProcAddress on GetPackageFamilyName and if it is not there then winget is not packaged.

[TreeBranches]

Isn't possible to read os version/type universally, without GetPackageFamilyName

Windows 7 does not support UWP/SparsePackage so all they would have to do is use GetProcAddress on GetPackageFamilyName and if it is not there then winget is not packaged.

That would mean that "They" would have to cater the tool to work on an OS that "They" haven't supported for over three years, and currently has a global market share of 3.6% (according to gs.statcounter.com) and declining.

If your hardware can run 7, it can run 10.

Else, fork it and you can do it.

[sskras]

That would mean that "They" would have to cater the tool to work on an OS that "They" haven't supported for over three years,

Yes, just like the tool workder before v0.2.2941 Preview circa Oct 29, 2020:

Binaries removed. We have discontinued support for versions of Windows 10 prior to version 1809

and currently has a global market share of 3.6% (according to gs.statcounter.com) and declining.

To make comparison more fair, it will need to count only installations that were running winget in a permanent manner during 2020, before dropping the aforementioned support. Which numbers now are probably hard to get (if possible at all).

If your hardware can run 7, it can run 10.

I take this an off-topic at the very least. With the same success I could say that anyone running w10 can run Debian or Ubuntu instead and replace winget with apt which supports everything down to Debian 2.1.

I stress that it's quite offensive to say. The UX is entirely different (both 7-vs-10 and 10-vs-Ubuntu).

Else, fork it and you can do it.

Sure, that's why asked you to summarize / if I got the needed features missing from w7 right from the comment (and since you pointed me to it).

[Masamune3210]

I mean, the issue is closed and the statement has been made. 7 has been out of support for quite a while now, is it really surprising to see that this isn't going to ever support it when even open-source projects with communal effort behind it is also doing the same thing?

[sskras]

@Masamune3210:

is it really surprising to see that this isn't going to ever support it

Partly yes. The EOL OSes usually stops being moving targets (their APIs don't change anymore). Which means the code to support them needs little changes (if any). If the code runs on 7, it runs. Things will not change here anymore.

And statements about 7 being insecure has nothing to do with the real expectations.
If the OS is EOL, no single tool would make it fully secure, and no user expects that.

The only exception I see here could be network related: the SSL handling. I don't know how the SSL handshakes are handled in winget http client part yet, so just guessing if it would be an issue on 7.

when even open-source projects with communal effort behind it is also doing the same thing?

That's a project (or even mindset) specific thing. Eg last two coming to my mind right now:

• midipix project (a better Cygwin) support things down to XP/2003.
• Ziglang welcomes the support for 7 too.

So it depends.

[TreeBranches]

Partly yes. The EOL OSes usually stops being moving targets (their APIs don't change anymore). Which means the code to support them needs little changes (if any). If the code runs on 7, it runs. Things will not change here anymore.

They won't change, but the application will. It was evidently left as an "if it works, great if not, well we don't support it anyway" state.

I take this an off-topic at the very least. With the same success I could say that anyone running w10 can run Debian or Ubuntu instead and replace winget with apt which supports everything down to Debian 2.1.

I stress that it's quite offensive to say. The UX is entirely different (both 7-vs-10 and 10-vs-Ubuntu).

Of course they can, but if the end-user wants to stick to their EOL OS for whatever reason, they can't be shocked that people are going to drop support for it.

You linking to other projects which do support them is irrelevant.

[sskras]

They won't change, but the application will. It was evidently left as an "if it works, great if not, well we don't support it anyway" state.

Yes, but the logic that only works on 7 would not. If yes, for what reasons?

Of course they can, but if the end-user wants to stick to their EOL OS for whatever reason, they can't be shocked that people are going to drop support for it.

We are not shocked. At least me. We are demanding.

You linking to other projects which do support them is irrelevant.

And earlier you wrote:

when even open-source projects with communal effort behind it is also doing the same thing?

Do you think your last statement could be applied to that quote too?

[Masamune3210]

Compilers have a support list, as well as other things like code signing. Both have been removing support for older OS's. Most people do not have the time, patience, and, frankly, the inclination, to support multiple codebases just because some people want to be stubborn and use a OS that lost general support years ago, and has been EOL for almost 4 months now.

[denelon]

Sometimes, it's not about being stubborn. I know of a few cases with highly regulated industries or special purpose hardware using older OSs can't easily be updated. If there is enough of a business case to invest in "legacy" technologies vs. the forklift update scenario, that's what needs to be done.

Unfortunately, we aren't in a position with enough business justification to apply our limited resources to support older versions of the OS, but there might be value in forking the project and seeing what can be done to muscle through a problem by a determined community.

[erkinalp]

@denelon Would you accept if a third party backport is offered in a pull request?

[denelon]

I believe this could be a reasonable option. The real concern here is the statement on support, and the risk of future changes we make potentially breaking an older OS that we don't test or certify. Any SKU of Windows that we "support" would be a limitation of what we're able to maintain. I'll need to discuss this with a few other internal folks to determine if it makes sense.