search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.27k stars 1.45k forks source link

Add Windows7 support #1686

Closed mrx23dot closed 2 years ago

mrx23dot commented 3 years ago

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 commented 2 years ago

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

mrx23dot commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Knew i've seen a similar question before https://github.com/microsoft/winget-cli/discussions/1020

Somewhat relatable https://github.com/microsoft/winget-cli/discussions/847

ItzLevvie commented 2 years ago

Related to https://github.com/microsoft/winget-cli/issues/1008#issuecomment-850524370: image

Since WinGet includes OS dependencies (and possibly APIs) that are not available in older versions of Windows, it would likely be a hard feat to achieve since these OS dependencies (and possibly APIs) are only available for Windows 10 version 1809 and above.

There are also some dependencies that have Windows 7 support stripped out from their code which will mean two things:

So, I don't think it would be worth for the engineering team to spend their engineering resources and budget to support Windows 7 for WinGet; especially when most people are on Windows 10 and above.

If the community wanted to make their own fork of WinGet to bring Windows 7 support, it will need some changes to how the pre-defined source is pulled down as MSIX isn't available in Windows 7, and more.

An alternative solution would be to use Chocolately or Scoop for Windows 7, or for the community to design their own solution similar to how it's done for Evergreen or Nevergreen.

RokeJulianLockhart commented 2 years ago

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.

ItzLevvie commented 2 years ago

Thanks ;)

I didn't know that MSIX is available for Windows 7, but there seems to be some downsides with it: https://docs.microsoft.com/en-us/windows/msix/msix-core/msixcore#considerations-of-msix-core.

It looks like you can only run WinGet in Win + R instead of Command Prompt or Windows PowerShell which will be a big issue because most, if not all, people run the winget command in Command Prompt or Windows PowerShell.

It also looks like WinGet must first support older versions of Windows before attempting to use MSIX Core, according to: MSIX Core enables the installation of MSIX apps on previous versions of Windows, provided that the apps are already built to work on those versions of Windows, so OS dependencies (and possibly APIs) are still an issue.

mrx23dot commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

This should work in that case:

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

ItzLevvie commented 2 years ago

There shouldn't be many win10 dependencies in WinGet to compile it to win7, I would imagine getting windows version and paths.

I believe it's more than that.

It uses APIs from Windows 10 as well; which aren't available in Windows 7, so you'll either have to remove those from the code or workaround that in the code.

This particular error is because WinGet is using the GetPackageFamilyName function in the kernel32.dll file, but it's not available in Windows 7: image

If you don't want to workaround that issue, the engineering team will have to make OS level changes to backport functions from Windows 10, and the chances of that happening is slim because Windows Servicing & Delivery (WSD) are largely focused on high-priority bug and security fixes for Windows 7's ESUs.

and the more code and dependencies you remove from WinGet using Visual Studio, the more functionality you break in WinGet, which makes it less useful for commercial users, as Delivery Optimization is used quite a lot in businesses.

So, rather than going through those hurdles mentioned above, it would be best for those admins to use Chocolately or Scoop under Windows 7.

Could someone try to compile it to win7 and share the compiler error log to see how much work is it?

Your best place to start would be to run AppInstallerCLI.exe + resources.pri with your REST API source under Windows 7 and then make code changes and work your way up from there.

but I do think that there won't be WinGet for Windows 7 because the engineering team will have to maintain two different versions of WinGet, and it won't be a sustainable long-term solution, as there aren't many people on Windows 7, compared to Windows 10 and above.

It'll require a bit of thinking of how WinGet updates will work on Windows 7. Potentially requiring AppInstallerCLI.exe to be wrapped under MSI (or Inno or others) and add it to the %PATH% environment, as App Installer (which WinGet is part of)'s .msixbundle file is strictly for Windows 10 because it's built under UWP and its dependencies were made for Windows 10.

What are the minimum .NET requirements for WinGet?

I don't have a build environment set up, so I'm not entirely sure.

It looks like WinGet used to have support for all versions of Windows 10, but was dropped: image

mrx23dot commented 2 years ago

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

Masamune3210 commented 2 years ago

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

denelon commented 2 years ago

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

sskras commented 1 year ago

@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 commented 1 year ago

@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: https://github.com/microsoft/winget-cli/issues/1686#issuecomment-981799599

mrx23dot commented 1 year ago

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

sskras commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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:

So it depends.

TreeBranches commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

denelon commented 1 year ago

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.