Status of Windows 7 support

[lazka]

This is regarding mingw packages, so not pacman, bash etc msys packages will remove Windows 7/8 support ~ end of 2022: msys2/MSYS2-packages#2696

Some upstream packages have decided to drop support for Windows 7, and the amount of packages affected will likely increase in the future.

In case upstream removes support we can do multiple things:

• Revert upstream changes (as long as that doesn't remove upstream features, or only degrades them a slightly)
• Patch things ourselves to get back Windows 7 support
• Stay on an older version longer, as long as there are no security issues
• Package multiple versions so packagers can install an older version if needed.

As you can see this all means work which we'd rather not do, so we will decide what to do on a package by package basis, also taking into account your feedback and how important a package is.

Likely scenario: Windows 7 support will slowly be phased out during 2022.

[Biswa96]

Shouldn't MINGW64 dropped (replaced by UCRT64) simultaneously with WIndows 7/8.1

That is the future plan. But the first blocker is that many packages can not be built with ucrt64 right now https://packages.msys2.org/queue?repo=ucrt64

[lazka]

Shouldn't MINGW64 dropped (replaced by UCRT64) simultaneously with WIndows 7/8.1.

It's still unclear how we can easily move existing users from mingw64 to ucrt64 :/

[mmuetzel]

This escalated pretty quickly from slowly dropping support for Windows 7/8.1 (which is probably fine) to potentially discontinuing MINGW64.
I might not be understanding the entire picture. But please also consider some border(?) use cases of MSYS2:
The "main" distribution of GNU Octave for Windows is cross-built on Linux using MXE Octave (which is an old fork of MXE). It uses MSYS2 as it's "base". Everything else is cross-built using the MinGW-w64 headers.
Is cross-compilation for UCRT64 possible from Linux? What would be the general changes necessary for MXE Octave in case support for mingw64 would be dropped in MSYS2?

[lazka]

The "main" distribution of GNU Octave for Windows is cross-built on Linux using MXE Octave (which is an old fork of MXE). It uses MSYS2 as it's "base". Everything else is cross-built using the MinGW-w64 headers.
Is cross-compilation for UCRT64 possible from Linux? What would be the general changes necessary for MXE Octave in case support for mingw64 would be dropped in MSYS2?

That's a good point, thanks. I think it should be possible, but I don't know any ready available Linux toolchain targeting ucrt. Let's leave this out of this discussion then.

[mmuetzel]

I probably wasn't clear in my original comment. Trying again:
We are using mingw64 (and mingw32) packages built by the MSYS2 project (this!) as a "base" for packaging Octave for Windows. Additional packages (including Octave itself) are cross-built using a mingw-w64 toolchain.
If the MSYS2 project discontinues their MINGW64 packages, will it be possible to use the UCRT64 packages (from the MSYS2 project) to "mix in" with the packages that we cross-built with a mingw-w64 toolchain (with MXE Octave)?

[mmuetzel]

I didn't want to take over this discussion. But since we already are there: Is there a Linux toolchain for UCRT?

[Biswa96]

@mmuetzel Removing Win7/8 support does not mean removal of mingw32/mingw64 build environment. It is just a future plan. UCRT in mingw-w64 itself may need some fixes too. You can see the plans here https://pad.ccc-mannheim.de/p/63tSa4McuD. These are discussed in Discord meetup. You can join too 🤗

will it be possible to use the UCRT64 packages (from the MSYS2 project) to "mix in"

Never mix ucrt and mscvrt (mingw32/64) packages. See details here https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt. For example, see the difference of struct _iobuf aka. FILE in msvcrt and ucrt.

[mmuetzel]

@Biswa96: Thanks for confirming what I already thought.
Also thanks for stressing again that this is not about removal of mingw32/mingw64. I was afraid that the discussion would take that direction after the first few comments.

[oscarfv]

Going back to the original topic...

Thank you for bringing in this discussion so early.

I'm afraid that there is no easy solution. Ideally, we could mark packages with a "minimum required OS version" tag, then pacman would refuse to update those packages displaying a prominent notice.

The problem is that packagers often would forget to check and set the tag, and once the problematic package is distributed, fixing the mishap would be quite complex in some cases.

If upstream decides to abandon users of older Windows versions, that's an issue to be discussed among upstream and its users. A different case is when the package is a core dependency of other outstanding packages, then we could consider the line of action on a case-by-case basis.

My 0.02 €.

[stahta01]

Would it be logical to assume mingw32/mingw64 GCC package would be one of the last packages to fail to build? And, of course all the packages needed to build GCC.

Tim S.

[longnguyen2004]

I didn't want to take over this discussion. But since we already are there: Is there a Linux toolchain for UCRT?

There's a standalone LLVM toolchain targeting UCRT available at https://github.com/mstorsjo/llvm-mingw. If you're comfortable with using clang and building dependencies from source, this toolchain is a good alternative.

[TheDeadFish]

Retaining some level of win7 support even if its only keeping archived packages would probably be a good idea, it would at least minimize the number of suicides for the time being.

[lazka]

@mmuetzel Fedora 37 will have a ucrt toolchain: https://fedoraproject.org/wiki/Changes/F37MingwUCRT

[rubyFeedback]

I think regardless of any change to the toolchain (see the libui comment), if it is decided to abandon Win 7 perhaps it would be useful to provide a "last working Win 7 snapshot", so others could, if they'd want to, continue from there, if you guys decide to abandon windows7. That could be hosted on github I suppose and perhaps some replacement server too as last backup. That way people who may need Win 7 support could continue to work on that last forked code base.

Personally I am not affected by this really as I use linux most of the time and my only windows-specific computer runs Win 10, but there are always people who can not easily switch/change.

[asmwarrior]

Hi, as rubyFeedback said, are there any way to get a "last working Win 7 snapshot" of msys2?

Many of my users and friends are still using Windows 7. But currently msys2 is using something which can't work under Win7, such as when using OpenCV library, it's highgui module is depends on QT6, but QT6 can't work under Win7.

Any ideas?

Thanks.

[ZachBacon]

Upgrade windows.

[asmwarrior]

Oh, I think this is the last choice I have to do. In this post: Deprecation of Windows 7 support · Issue #2696 · msys2/MSYS2-packages — msys2/MSYS2-packages#2696

I see there is a plan to have an achieve for old Win7? Any news about this achieve?

[asmwarrior]

Here is my test for installing an old version of OpenCV, I just download a file named:
mingw-w64-x86_64-opencv-4.6.0-10-any.pkg.tar.zst — https://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-opencv-4.6.0-10-any.pkg.tar.zst, this package of opencv is the latest one which support QT5. Since QT6 can't be used under Win7.

And Now, I just run the pacman command to install this file, here is the command line:

# pacman -U mingw-w64-x86_64-opencv-4.6.0-10-any.pkg.tar.zst
loading packages...
warning: downgrading package mingw-w64-x86_64-opencv (4.7.0-7 => 4.6.0-10)
resolving dependencies...
looking for conflicting packages...

Packages (1) mingw-w64-x86_64-opencv-4.6.0-10

Total Installed Size:  89.30 MiB
Net Upgrade Size:      -1.79 MiB

:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring                                                                                                                                     [####################################################################################################] 100%
(1/1) checking package integrity                                                                                                                                   [####################################################################################################] 100%
(1/1) loading package files                                                                                                                                        [####################################################################################################] 100%
(1/1) checking for file conflicts                                                                                                                                  [####################################################################################################] 100%
(1/1) checking available disk space                                                                                                                                [####################################################################################################] 100%
:: Processing package changes...
(1/1) downgrading mingw-w64-x86_64-opencv                                                                                                                          [####################################################################################################] 100%
New optional dependencies for mingw-w64-x86_64-opencv
    mingw-w64-x86_64-qt5-base: for the HighGUI module [installed]

You see, the installation works correctly, and it's dependency QT5 library is also installed.

But if I create a simple OpenCV sample code, and try to show an image in its highgui module, I got an error:

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I believe that the C runtime library (mainly from GCC) is different. So, it can's solve the issue.

[Biswa96]

msys2 no longer supports Windows versions lower than 8.1. See this news https://www.msys2.org/news/#2023-01-15-dropping-support-for-windows-7-and-80

[MehdiChinoune]

i686 libs/apps are built against Qt5. Use them if you want to avoid Qt6.

[mirh]

Even the latest Qt 6.4 can still work on W7.
https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2-2-running-on-windows-7

EDIT: https://github.com/crystalidea/qt6windows7

[ZachBacon]

And yet, windows 7 is end of life. Ergo, shouldn't really be supported anymore.

[hickford]

@lazka Is there a provisional timetable for dropping support for later versions of Windows, such as Windows 8.1 and eventually Windows 10?

[Biswa96]

Is there a provisional timetable for dropping support for later versions of Windows, such as Windows 8.1 and eventually Windows 10?

Only Microsoft knows 😭

[lazka]

@lazka Is there a provisional timetable for dropping support for later versions of Windows, such as Windows 8.1 and eventually Windows 10?

I haven't though about that yet. Windows Server 2012 R2 still has (non-ESU) support until October, so we could drop support for 8.1 some time after that, but not sure. No idea re Windows 10.

[sskras]

Out of curiousity: what specific things does the support provided by Microsoft have to do with building open source apps using an open source compiler toolchain?

For the life of me I can't think of any reason other than formality. Especially when the target platform stops being a moving target with their APIs (DLL ABIs and the related header files) not being changed anymore due to the stopped OS development.

[Biswa96]

what specific things does the support provided by Microsoft have to do with building open source apps using an open source compiler toolchain?

The main thing is availability of public APIs. You can look into the sdkddkver.h and grep all the macros recursively to get an idea about which APIs are disabled/enabled. Though not all programs are affected in the same way. For example, compilers may not use latest Windows APIs.

Another thing is Windows versions usage share. If majority of developers and users use Windows 10 and 11, then they may not be interested in fixing issues for Windows 7 or 8.

[totszwai]

I think regardless of any change to the toolchain (see the libui comment), if it is decided to abandon Win 7 perhaps it would be useful to provide a "last working Win 7 snapshot", so others could, if they'd want to, continue from there, if you guys decide to abandon windows7. That could be hosted on github I suppose and perhaps some replacement server too as last backup. That way people who may need Win 7 support could continue to work on that last forked code base.

Personally I am not affected by this really as I use linux most of the time and my only windows-specific computer runs Win 10, but there are always people who can not easily switch/change.

Hello, is there a "last working Win 7 snapshot" somewhere? While almost nobody still uses Windows 7, the aviation industry are still using them... heck they even need to use Windows XP on their planes!!!

[ognevny]

Hello, is there a "last working Win 7 snapshot" somewhere? While almost nobody still uses Windows 7, the aviation industry are still using them... heck they even need to use Windows XP on their planes!!!

but anyway they have their own sofware that fully support an outdated systems. that thing is everywhere

[totszwai]

Hello, is there a "last working Win 7 snapshot" somewhere? While almost nobody still uses Windows 7, the aviation industry are still using them... heck they even need to use Windows XP on their planes!!!

but anyway they have their own software that fully support an outdated systems. that thing is everywhere

No no, I mean I need to compile/maintain/update some software in order to run in those totally outdated Windows 7 environment and I couldn't right now! Is there a snapshot I could use? 😢

We shipped them the software ~6 years ago and need to maintain it STILL. However, everything else we work/do has been migrated/updated to work with Windows 10 and the greatest/latest... so we lost the old build environment long time ago.

And I have no way of getting it to run in Windows 7, I've tried many different ways in the past whole week without success.
https://stackoverflow.com/questions/77685837/possible-to-force-msys2-mingw-to-build-without-ucrt

[longnguyen2004]

Found this link on a random Stack Overflow page that's supposed to be the last version for Windows 7
https://github.com/msys2/msys2-installer/releases/tag/2022-10-28

[MehdiChinoune]

Found this link on a random Stack Overflow page that's supposed to be the last version for Windows 7 https://github.com/msys2/msys2-installer/releases/tag/2022-10-28

But, you shoudln't run pacman -Sy

[lokapal]

This installer has only installer and msys2 itself, we need in the full mirror of all packages for Win 8.1/Win 7 (frankly speaking, abandoning of Win 8.1 / Win 7 is complete nuisance, e.g. Ubuntu 16.04 LTS still obtaining patches!). Does anybody know the existing snapshot of all packages required for msys2? I'd prefer to have local mirror, or mirror it to the private cloud. We have A LOT of Win 8.1 notebooks and even Win 7 computers are beautifully working behind firewall, and from time to time we need in msys2 to compile some legacy programs for these computers. E.g. right now I need to install libcurl-devel and pacman simply cannot find packages at the server:
error: failed retrieving file 'libpsl-devel-0.21.1-2-x86_64.pkg.tar.zst' from mirror.jmu.edu : The requested URL returned error: 404

[MehdiChinoune]

Ubuntu 16.04 LTS still obtaining patches!

Windows 7 was released in 2009, while Ubuntu 16.04 was released in
2016, support for normal users ended in 2021. Only paid users get updates until 2026.
(I am ready to maintain Windows 7 if I get enough money 1000$/month).
Don't forget that MSYS2 is maintained by volunteers.

[lokapal]

Windows 7 was released in 2009, while Ubuntu 16.04 was released in
2016, support for normal users ended in 2021. Only paid users get updates until 2026.

First of all, MSYS2 dropped support to Win 8.1 too (regular updates stopped January 2023). Secondary, I guess, MSYS2 dropped support of Windows 2012 Servers (that are Win 8.1 based) that finished regular support October 2023.
And, finally, I don't ask for any SUPPORT! I ask only for possibility to make/download LOCAL mirror snapshot of complete MSYS2 for all these systems (that definitely are not required in any support if they are inside firewall and IDS perimeter, moreover, don't fix it if it doesn't broken!).

P.S. About Ubuntu 16.04 - all who need can FREELY subscribe (up to 5 computers) to Ubuntu ESM - 10 years of updates.
https://ubuntu.com/security/esm

[MehdiChinoune]

Are you talking about Windows 8.1 or Windows 8, 8.1 still supported by MSYS2 (https://www.msys2.org/news/#2023-01-15-dropping-support-for-windows-7-and-80) even It's dropped by MS itself after 10 years of support.
Windows 7 got its 10 years of security updates, nothing to compare with Ubuntu 16.04
Only supported packages (main repo) get security updates. universe and multiverse packages don't get any update.

No one knows which the latest working snapshot on Windows 7. Many packages stopped working on Windows 7, but MSYS2 did nothing for that. I was packages upstream decision.
MINGW64 still target Windows 7 '_WIN32_WINNT=0x0601' https://github.com/msys2/MINGW-packages/blob/d74377dd/mingw-w64-headers-git/PKGBUILD#L47

[totszwai]

It doesn't matter if Windows 7 or XP is end of life or supported is being officially dropped by Microsoft. The fact is that many things, such as aircraft, still use Windows XP and Windows 7 (yes, you read that right). I am in complete agreement here with @lokapal , it would be nice to get a snapshot of a working MSYS2 environment to be able to build Windows 7.

[MehdiChinoune]

@totszwai Will you pay for that, or just want it for free?

[totszwai]

@totszwai Will you pay for that, or just want it for free?

I am not paying for anything, I am just a worker, a grunt grinding out code. There is technically no maintenance involve, I haven't try the following snapshot below yet, but it wouldn't hurt just to keep that particular tag for Windows 7 (if it really work). 👇🏻

Found this link on a random Stack Overflow page that's supposed to be the last version for Windows 7 https://github.com/msys2/msys2-installer/releases/tag/2022-10-28

[MehdiChinoune]

I wrote above, no one knows when was the latest working snapshot. What you are referring to is the latest working installer on Windows 7.
pacman doesn't have such a thing as tag or something similar to that.
You could take that installer and copy database files (without running pacman -Syu) into your MSYS2 installation to get the latest packages at that date, but no guarantee that all of them work on Windows 7. Also some packages were already removed from repos and there is no way to restore them, so you couldn't install them (vcpkg project encountered that issue manu times).

What you're asking for is almost impossible to do. pacman was designed for rolling-release based platforms.

[lokapal]

AFAIK msys2 (unfortunately, I'd say) is based upon Arch Linux' (it's freaking rolling release distro) pacman packet management system. But even Arch has archive! https://wiki.archlinux.org/title/Arch_Linux_Archive with 5 years of history.
Moreover, there are ISOs of ALL Arch releases (unfortunately, with no packages).
The example of required snapshot:
http://tardis.tiny-vps.com/aarm/repos/ (it's ARM archive unfortunately, but the principle is clear: you can set your repository address to the required date, and voilà! - you'll have the complete repository of OS and all required packages for the desired date!), e.g. http://tardis.tiny-vps.com/aarm/repos/2022/08/13/

P.S. MSYS2 WAS the marvelous software collection that permitted me to compile for Windows with full functionality a lot of really complex command-line programs, and it is the MOST important collection for Win 7/8.1 especially, since they don't have something like WSL.

[MehdiChinoune]

There was a plan to setup a similar project for archiving MSYS2 packages https://github.com/msys2/msys2-archive but never realized.