This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Drop support of Windows Vista and Windows 7
Type: enhancement Stage: resolved
Components: Windows Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: CAM-Gerlach, DMI-1407, ZackerySpytz, eryksun, izbyshev, kj, lukasz.langa, paul.moore, pitrou, python-dev, steve.dower, terry.reedy, tim.golden, veso266, zach.ware
Priority: normal Keywords: patch

Created on 2018-01-18 09:37 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 5231 closed vstinner, 2018-01-18 09:38
PR 11457 closed vstinner, 2019-01-07 14:59
PR 11457 closed vstinner, 2019-01-07 14:59
PR 11457 closed vstinner, 2019-01-07 14:59
PR 15951 merged steve.dower, 2019-09-11 13:52
PR 22586 closed python-dev, 2020-10-07 10:53
PR 26429 kj, 2021-05-28 14:18
Messages (44)
msg310227 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-18 09:37
https://docs.python.org/dev/using/windows.html#supported-versions

"As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.7 supports Windows Vista and newer. If you require Windows XP support then please install Python 3.4."

But Windows Vista extended supported already ended last year, in April 2017.

Attached PR removes code to support Windows Vista.
msg310233 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-01-18 11:01
The only changes necessary in the installer should be in PythonBootstrapperApplication.cpp to make it an error when run on pre-Win7 OS. The pattern is already there, and the string references are in Tools/msi/bundle/Default.wxl

If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.
msg310234 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-18 11:02
> If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.

I like that :-) Will me. Right now, my PR doesn't compile, I broke something and I don't understand the error.
msg310296 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-01-19 22:26
I believe that PEP 11 originally said, or should have said "3.6 supports Windows Vista and newer."  I believe 3.5 supports XP, so it should be "please install Python 3.5".
msg310297 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2018-01-19 22:29
3.4 was the last version to support XP.
msg310303 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-19 23:50
Terry: see my notes about platforms suported by Python.
http://vstinner.readthedocs.io/cpython.html#supported-platforms

The PEP 11 doesn't want to have an explicit list of supported Windows versions, but I'm unable to *guess* which Windows version is supported by which Python version, so I wrote my own doc...
msg310308 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-01-20 00:45
I personally think it was a mistake to stop being explicit about Windows support in PEP 11.  The rationale was to avoid having to update it.  But it is updated for other systems; an explicit list is needed somewhere (as illustrated by my memory lapse; and PEP 11 is the most obvious and discoverable place.
msg318103 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-05-29 21:50
I failed to fix failures on my PR. It's now too late for Python 3.7.

If someone is interested to drop Vista support from Python 3.8, I suggest to open a new issue instead.
msg333160 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-07 14:57
Hello 2018, I reopen the issue and change the version to Python 3.8.
msg333161 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-07 15:01
> I failed to fix failures on my PR. It's now too late for Python 3.7.

I will try to redo PR 5231 in small chunks to better control the risk. I extracted os.cpu_count() changed as a new PR: PR 11457.

I already updated time.monotonic() documentation in a previous change:

commit 3ab064e80a9be1e6e9c62437fffb92bde9c5e1fb
Author: Victor Stinner <vstinner@redhat.com>
Date:   Mon Dec 17 12:12:34 2018 +0100

    bpo-23451: Update time.monotonic() documentation (GH-11190)
    
    bpo-23451, bpo-22117: Python 3.5 requires Windows Vista or newer,
    time.monotonic() is now always system-wide.
msg333186 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-01-07 20:33
AFAIK, it was specifically Martin Loewis who did not want a specific list in PEP 11.  Since he is long inactive, I think you and Steve should feel free to change that.
msg333187 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-07 22:46
I'd rather leave it specified as it is in PEP 11, though perhaps specifying it explicitly in the release schedule PEPs would be helpful? Up to release managers.
msg341393 - (view) Author: Zackery Spytz (ZackerySpytz) * (Python triager) Date: 2019-05-04 17:12
See also #29075.
msg341534 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-06 15:34
I marked bpo-29075 as duplicate of this issue.

IMHO it's too late to remove code from Python 3.8. We are too close from the feature freeze: removing Vista code is a risk of introducing subtle issue. I prefer to now wait for Python 3.9. It's not like the "dead code" is causing any major issue. Or does someone see a good reason to remove Vista support *right now*?
msg341535 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-06 15:35
Before Vista, the code page 65001 behaved differently than official UTF-8 codec. Vista changed that. Maybe it's time to remove Lib/encodings/cp65001.py and make it an alias to utf_8 codec: see https://bugs.python.org/issue36778#msg341531
msg341612 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-05-06 19:18
> Maybe it's time to remove Lib/encodings/cp65001.py and make it an 
> alias to utf_8 codec

Note that Unicode console support already assumes they're equivalent. For stdin, we read UTF-16LE via ReadConsoleW and encode bytes to the UTF-8 BufferedReader via WideCharToMultiByte with CP_UTF8 (65001). For stdout/stderr, we decode bytes from the UTF-8 BufferedWriter via MultiByteToWideChar with CP_UTF8 and write UTF-16LE via WriteConsoleW.
msg342041 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-10 02:11
> Before Vista, the code page 65001 behaved differently than official UTF-8 codec. Vista changed that. Maybe it's time to remove Lib/encodings/cp65001.py and make it an alias to utf_8 codec: see https://bugs.python.org/issue36778#msg341531

FYI it's exactly what I did:

New changeset d267ac20c309e37d85a986b4417aa8ab4d05dabc by Victor Stinner in branch 'master':
bpo-36778: cp65001 encoding becomes an alias to utf_8 (GH-13230)
https://github.com/python/cpython/commit/d267ac20c309e37d85a986b4417aa8ab4d05dabc
msg351882 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-09-11 13:55
I'll at least make a start by updating the minimum API version.
msg351965 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2019-09-11 16:03
New changeset 0b72ccff56fb47e14f7b1f6590eafff8d104c229 by Zachary Ware (Steve Dower) in branch 'master':
bpo-32592: Set Windows 8 as the minimum required version for API support (GH-15951)
https://github.com/python/cpython/commit/0b72ccff56fb47e14f7b1f6590eafff8d104c229
msg352476 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-15 13:56
3.9 can drop support for console pseudohandles in set_inheritable in Python/fileutils.c and Popen._filter_handle_list in Lib/subprocess.py. 

Also, _Py_write_impl in Python/fileutils.c can remove the 32767 byte limit for console files (and other character devices such as NUL, since it over-generalizes via isatty). The same applies to _io__WindowsConsoleIO_write_impl in Modules/_io/winconsoleio.c.

---
Discussion

In Windows 8+, the console uses "\\Device\\ConDrv" with kernel file objects. The console host process opens a file object for the ConDrv device itself in order to handle IOCTLs from clients. A console client process opens virtual files on ConDrv such as Connect (for generic functions such as GetConsoleCP), Input (default StandardInput), Output (default StandardOutput, StandardError), Console (//./CON), CurrentIn (//./CONIN$), and CurrentOut (//./CONOUT$). There's no practical limit on the size of reads and writes via these files.

Prior to Windows 8, console API requests are instead sent over an LPC port. Large messages that don't fit in a LPC packet are passed in a 64 KiB window of shared memory that's overlayed by a heap. This is the heap referred to by claims in the console API docs such as "[i]f the total size of the specified number of characters exceeds the available heap, the function fails with ERROR_NOT_ENOUGH_MEMORY".

With the LPC implementation, file handles for the console input buffer and screen buffer(s) are not real handles for kernel File objects. Rather, the console host process maintains a private table of pseudohandles for console buffers. These console pseudohandles are tagged for routing in the Windows API by setting the lower 2 bits. They're also verified in functions such as GetFileType via the undocumented function VerifyConsoleIoHandle. These pseudohandles have to be identified in Python because they're not supported by SetHandleInformation or the PROC_THREAD_ATTRIBUTE_HANDLE_LIST of CreateProcess, both of which require real kernel handles.
msg352502 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-16 02:29
Here are a couple more:

* WSA_FLAG_NO_HANDLE_INHERIT is supported. Code related to `support_wsa_no_inherit` in Modules/socketmodule.c can be removed.

* AddDllDirectory and RemoveDllDirectory are supported. os__add_dll_directory_impl and os__remove_dll_directory_impl in Modules/posixmodule.c no longer need to manually link to them via GetModuleHandleW and GetProcAddress.
msg353307 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-26 14:21
Steve, in PR 15951 you updated Py_WINVER to 0x0602. I think it should be 0x0603 (_WIN32_WINNT_WINBLUE) and 
Py_NTDDI should be NTDDI_WINBLUE. Windows 8 hasn't been supported since 2016. Windows 8.1 is supported until 2023.
msg353308 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-09-26 14:25
> Steve, in PR 15951 you updated Py_WINVER to 0x0602. I think it should be 0x0603 (_WIN32_WINNT_WINBLUE) and Py_NTDDI should be NTDDI_WINBLUE. Windows 8 hasn't been supported since 2016. Windows 8.1 is supported until 2023.

Dropping Windows 7 support allows us to remove code to support Windows 7.

I'm not sure that there is a big benefit for us to drop Windows 8 support (only Windows 8 but continue to support Windows 8.1), compared to the annoyance for users.
msg353312 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-09-26 14:51
There shouldn't be any annoyance to users, as nobody should be using Windows 8 anymore (the update to 8.1 was free and difficult to avoid).

Updating to NTDDI_WINBLUE is fine, but not essential. Nothing about that flag has a real impact until we need or want to directly call functions that were only added in that version.
msg353328 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-26 16:31
> I'm not sure that there is a big benefit for us to drop Windows 8 
> support (only Windows 8 but continue to support Windows 8.1), 
> compared to the annoyance for users.

According to statcounter.com and netmarketshare.com, Windows 8 still has 1% or less of the desktop market (across all platforms), while Windows 8.1 has about 5%. In comparison, Windows 7 has about 25-30% share, and Windows 10 has about 45-50%. I expect to see complaints about dropping Windows 7 support in 3.9. It's still quite popular and may take longer to die off than even Windows XP. I don't expect much noise, if any at all, about dropping Windows 8. Microsoft hasn't supported it for over 3 years.

A minor benefit of requiring Windows 8.1 would be support for process snapshotting (*). We could re-implement win32_getppid based on PssCaptureSnapshot and PssQuerySnapshot. This would only snapshot basic information about the current process (a few NtQueryInformationProcess system calls), whereas a Toolhelp snapshot, as is currently used, captures information about every process and thread in every session. Like I said, it's a minor benefit -- especially if we make the parent pid a static variable, so it only has to be looked up once. But this also opens up other features provided by this facility, including walking the handle table and virtual memory, if someone finds a use for them.

(*) For some reason ProcessSnapshot.h requires NTDDI_WIN8 instead NTDDI_WINBLUE, so this isn't actually a case for changing the value of  Py_NTDDI, but it should be in principle. The docs for process snapshotting require Windows 8.1, and the Windows 8 version of kernel32.dll (6.2.9200.*) does not export any of the Pss* functions, so it really was/is not available in Windows 8 as far as I can tell.
msg363348 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 13:25
I'd be happy to submit a PR to resolve all the issues that I note here. Just say the word and I'll go right ahead.

I presume the Windows installer code [0a] should be updated to refuse to install on Windows <8 and given an informative warning instead letting the user know their system is not supported, as well as logging the appropriate messages in each case? Appropriate failure IDs would also be defined in the associated WXL [0b].

[0a] https://github.com/python/cpython/blob/master/Tools/msi/bundle/bootstrap/PythonBootstrapperApplication.cpp#L3041
[0b] https://github.com/python/cpython/blob/master/Tools/msi/bundle/Default.wxl

The relevant Using Python on Windows docs [1a] should be updated to reflect this, along with PCBuild/readme.txt [1b]. Also, given it is dropping 2 major Windows versions, including one seeing widespread use, it should probably be mentioned in What's New; I don't see it there as it stands now.

[1a] https://github.com/python/cpython/blob/master/Doc/using/windows.rst
[1b] https://github.com/python/cpython/blob/master/PCbuild/readme.txt

As a more trivial docs change, references to "Vista's" UAC ([2a], [2b], [2c]) could be updated to simply refer to "Windows'" UAC to avoid confusion since it presumably applies to all >=Vista versions which have said feature.

[2a] https://github.com/python/cpython/blob/master/Lib/distutils/command/bdist_wininst.py#L52
[2b] https://github.com/python/cpython/blob/master/PC/bdist_wininst/install.c#L2187
[2c] https://github.com/python/cpython/blob/master/Doc/distutils/builtdist.rst#vista-user-access-control-uac

Finally, maybe this is stretching the scope a bit, but the relevant part of [1a], namely [3a], should also be updated to state that Windows CE is not supported (it currently states the opposite), as this was removed in 3.6.0b1 [3ai], and additionally the Sourceforge (!) project it links to [3bii] is on an legacy archived CVS repo that hasn't been meaningfully updated since 2008 and the current versions of CE (5 and 6) at the time is long EoL now (in fact, 7 is coming up on its EoL in a year). Out of date references to Windows CE support could also be removed from the ctypes doc [3b] and the condavar code comments [3c], [3d].

[3a] https://github.com/python/cpython/blob/master/Doc/using/windows.rst#L1165
    [3ai] https://github.com/python/cpython/blob/master/Misc/NEWS.d/3.6.0b1.rst#L217
    [3aii] https://sourceforge.net/projects/pythonce/files/
[3b] https://github.com/python/cpython/blob/master/Doc/library/ctypes.rst 
[3c] https://github.com/python/cpython/blob/master/Include/internal/pycore_condvar.h#L30
[3d] https://github.com/python/cpython/blob/master/Python/condvar.h#L85
msg363352 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 14:48
Here's a further conservative list of low-hanging <Win8 bitrot in the  code itself not already mentioned that can be eliminated as a result of this change, focusing on the Python side of the code and tests; again, I can offer a PR if desired.

Python Code:
* ntpath.py | Win9x (!) | Check for pre-NT versions can be simplified along the lines of the check for darwin in posixpath.py: https://github.com/python/cpython/blob/master/Lib/ntpath.py#L675
* multiprocesing/connection.py | >=Win 8 | Branch can be inlined and outdated comments removed: https://github.com/python/cpython/blob/master/Lib/multiprocessing/connection.py#L866
* pathlib.py | >= Vista | Branch can be inlined and else block removed: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L19


Tests:
* test_winreg.py | Vista | Multiple tests and constants (All the checks and tests requiring registry reflection/`HAS_REFLECTION`):  https://github.com/python/cpython/blob/master/Lib/test/test_winreg.py
* test_winreg.py | <Vista | No-reflection Test: https://github.com/python/cpython/blob/master/Lib/test/test_winreg.py#L309
* test/support/__init__ | <=Win 9x (!) | Test initialization branch can be inlined and out of date comments removed: https://github.com/python/cpython/blob/master/Lib/test/support/__init__.py#L987
* test_winconsoleio.py | <=Win7 | Test branch: https://github.com/python/cpython/blob/master/Lib/test/test_winconsoleio.py#L99
* test_winconsoleio.py | <=Vista | Skipif decorator : https://github.com/python/cpython/blob/master/Lib/test/test_winconsoleio.py#L99
* test_import/__init__.py | <Vista | Skipunless decorator in test initialization: https://github.com/python/cpython/blob/master/Lib/test/test_import/__init__.py#L1025


Other:
* "Since we limit WINVER to Windows 7 anyway, it doesn't really matter which WinSDK version we use." -> can be updated to 8? https://github.com/python/cpython/blob/master/PCbuild/python.props#L101
msg363356 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 15:37
What Eryk said wrt Windows 8 seems sound, looking at some additional data.

Per Statcounter [0], Windows 8 market share has dropped to 1.32% from 2.20% of all Windows users over the past 12 months, or 1.75% -> 1.01% of all desktop users. Extrapolating a constant linear decrease, this would imply a usage share of 0.55-0.60% at Python 3.9 release, or considering a more conservative (and realistic) constant-percent decrease, this would put the amount at 0.75%. For comparison, by Statcounter's same metrics, Windows XP which was EoL 5 versions ago is still at 1.13% of the Windows or 0.90% of the total desktop market today, WinVista is at 0.41%/0.33%, Win8.1 at 4.7%/3.8% (~4x Win8) and of course the EoL and also dropped Windows 7 is at no less than 23.2%/18.5%, nearly 20 times the amount of Win 8 today and dropping more slowly besides.

[0] https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

Conducting a similar analysis with the NetMarketshare data [1], we see a 0.78% -> 0.66% year on year share for Win8, which extrapolates to a 0.57% share at Py2.9 release. Vista is much lower at only 0.15%, but XP is over 2x higher at 1.35%, and Win8.1 well over 5x as large at 3.5%. Windows 7 is, again, at no less than 25.2%, nearly 40x the Win 8 marketshare.

[1] https://netmarketshare.com/operating-system-market-share.aspx

Users likely to be most concerned with wanting or needing to use the latest and greatest version of Python are more than likely to be power users, enthusiasts and developers, a group that was particularly averse to adopting Windows 8 when it came out, was more likely to upgrade to 8.1 , and is more aware of EoL timeframes than the average consumer. This is empirically supported by the Steam survey [2], which samples a population substantially more similar to the profile of a developer than the average web user captured by the previous two surveys. Here, the numbers are much more stark: A mere 0.17% of their >96% Windows userbase runs Windows 8, vs. 2.10% (>10x) for Windows 8.1 and 12.4% for Windows 7 (~75x). Given an infinitesimal fraction of such remaining users are likely going to require upgrading to a bleeding-edge Python version but not their OS that would have been EoL for nearly 5 years, over a year longer than Vista itself  and 4 years longer than 7, I don't think supporting that EoL OS per PEP 11 for another >5+ years with another new Python version need be a priority.

[2] https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
msg364793 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-22 09:53
Hey, any update on this? As I mentioned, I'm willing to implement everything I mention here in one or more PRs, but I wanted to wait for a go-ahead in case some of the changes were not desired. Let me know and I'll go ahead. Thanks!
msg364798 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-03-22 12:01
Go ahead. I think you should create three PRs (docs, tests and code), with only as many tests in the code PR as are needed to keep it passing.
msg364899 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-23 20:39
Thanks, will do as requested. I was planning on knocking it out yesterday, but some unexpected things came up so I might have to push it all the way to next weekend, but I'll get it done.
msg388700 - (view) Author: (DMI-1407) Date: 2021-03-15 02:09
Is a Windows Version dropped on "normal" end of life or when the extended support ends?
Windows 7 extended support ends in 2023 (april i think).
Source: https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-7-eos-faq/windows-7-extended-security-updates-faq#what-are-the-coverage-dates-for-the-three-windows-7-esu-skus

As far as i understood it, Windows 7 gets unsupported from Python 3.9 because of code removal?
So wouldnt it be better to keep the code until the extended support of Windows 7 ends?
msg388703 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-15 02:59
PEP 11 says that "[a] new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired". There was no such thing as Extended Security Updates (ESU) when that provision was accepted. As defined by PEP 11, extended support for Windows 7 ended on 2020-01-14. 

> So wouldnt it be better to keep the code until the extended support of
> Windows 7 ends?

IMO, Windows 7 is either supported or it's not. If it's not, then workarounds and fallback code for Windows 7 should be removed.
msg388705 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2021-03-15 03:58
Sorry I never got around to this, I was planning on it and then life and COVID intervened. I can give it another look now to get it in before the 3.10 feature freeze (since I at least documented in detail what each change should be, so it should be relatively straightforward) unless someone else would rather take it.

> PEP 11 says that "[a] new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired". There was no such thing as Extended Security Updates (ESU) when that provision was accepted. As defined by PEP 11, extended support for Windows 7 ended on 2020-01-14. 

Yeah, "Extended Support" has a very specific, defined meaning [1] in Microsoft standard terminology (and other vendors as well), as the support phase after "Mainstream Support" but before the product end of life, where security updates and potentially limited bugfixes are still offered to all customers and the product is still considered supported, but new features and phone support is not. This ended 2020-01-24.

[1] https://docs.microsoft.com/en-us/lifecycle/policies/fixed

ESU [2] is a specialized, paid program available to high volume enterprise customers as a "last resort option" that pay big $$$ to continue receiving critical security updates for a limited time. This fulfills neither the letter nor the spirit of the policy defined in PEP 11; if such vendors need support for bleeding-edge Python versions for some reason, it certainly should be well within their means to fund someone to do so.

[2] https://docs.microsoft.com/en-us/lifecycle/faq/extended-security-updates
msg389225 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2021-03-21 11:49
As a data point, my Windows development VM uses Windows 7.  It would be a major annoyance for me to reinstall a new development VM from scratch (going through the usual hurdles to have a usable development environment would probably be a full day of work, perhaps more).
msg389377 - (view) Author: Mitja kocjančič (veso266) Date: 2021-03-23 08:49
I have to agree with msg389225, I use windows 7 on my dev machine as well as I use some programs and devices that unfortionatly do not work on windows 10 so update is not possible, now it would be realy anoying that I would loose python support as well since I use one device with python that does not work on win10

so I am in favour that python keeps the workarounds and fallback code for Windows 7 at least until ESU supports ends (since if its a dead code why would you remove it just leave it in, if it works well and you don't touch it often it does no harm)
msg389378 - (view) Author: Alexey Izbyshev (izbyshev) * (Python triager) Date: 2021-03-23 09:23
As far as I understand, commit [1] explicitly prevents CPython from running on Windows 7, and it's included into 3.9. So it seems to be too late to complain, despite that, according to Wikipedia, more than 15% of all Windows PCs are still running Windows 7 [2].

[1] https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5
[2] https://en.wikipedia.org/wiki/Windows_7
msg389385 - (view) Author: Mitja kocjančič (veso266) Date: 2021-03-23 11:13
doh, thats unfortunate I was too late to complain, and now its all gone
oh well, I guess people will not roll back commits now, I hoped windows 7 supported could be kept at least til python4 (or when microsoft completly abandons  win7 (when the API will change as well, just like with python3 there was python2.7 which was like a LST release for ubuntu)
msg389398 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2021-03-23 18:17
In my limited understanding, all PR #15951 does is set a compiler macro to allow use of Win API calls present on >=Win8 instead of >=Win7. If Win8-only calls are not used, then presumably it should still build and run on Windows 7, presumably with the flag flipped back to Win7. And if there are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC compiler will catch any instances of Win8-only calls at build time? Is this understanding correct?

If the latter is true, its very likely a lost cause. However, if the former is the case, then at least devs using Python 3.9+ on Windows 7 will be able to easily build their own versions with support, though that could change at any time. If the upside to supporting the latest Python versions on an EoL platform that is no longer receiving security updates but still has significant use is greater than the (seemingly pretty small) benefits of dropping support, then I imagine it would at least be conceivable to switch the flag back, though it probably is a lost cause now that a major version has been released without support and the buildbots have been presumably retired. At least third parties should be able to easily release patched versions, for now.

For those in the know, have there been a lot of reports/discontent surrounding the dropping of support in Py3.9, by anyone aware of that? 

However, I don't think it should be tied to the ESU date at all, as opposed to real-world usage of bleeding-edge Python on that version; ESU is a paid-only service for large corporate customers; if they're willing to pay through the nose for updates to their EoL OS and also need the latest bleeding-edge Python, surely they can fund the pittance required for maintenance or building it themselves.

All that said, I'll hold off on doing anything further until there's consensus. I'd think whatever we do it should be consistent, at least in the docs and installer; if dropping support in the code itself is more risk and pain than benefit, then that needn't be done.
msg389413 - (view) Author: Alexey Izbyshev (izbyshev) * (Python triager) Date: 2021-03-23 22:35
> If Win8-only calls are not used, then presumably it should still build and run on Windows 7, presumably with the flag flipped back to Win7. And if there are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC compiler will catch any instances of Win8-only calls at build time? Is this understanding correct?

It's the latter. In the patch, calls to functions like PathCchCanonicalizeEx(), which had previously been conditional on runtime availability of those functions, were made direct. Those functions are not from UCRT (so you can't just distribute it to regain Windows 7 support) and are not available in Windows 7.

There was also another patch that adds a check to Python 3.9+ installer that prevents installation on Windows 7 (but again, even if you take the Windows "embedded" distro instead of the installer, it won't run due to Win8-only functions).

> If the latter is true, its very likely a lost cause. However, if the former is the case, then at least devs using Python 3.9+ on Windows 7 will be able to easily build their own versions with support, though that could change at any time.

For now, it's not entirely lost cause in the sense that the number of Win8-specific patches and their size is very small (I'm not aware of anything not already mentioned, but I may be not up-to-date). So an interested party can probably revert them locally without much hassle.

> For those in the know, have there been a lot of reports/discontent surrounding the dropping of support in Py3.9, by anyone aware of that? 

I semi-casually follow the bug tracker and remember only bpo-41412 and bpo-42027.

Personally, I do consider tying of Windows support in CPython to arbitrary support periods set by Microsoft unfortunate, and it's also true that Win8-specific changes I'm aware of are not critical and don't remove any significant maintenance burden. For now, both relative and absolute usage of Windows 7 is huge and hard to ignore, so developers who use CPython in their own software are faced with an unpleasant choice of sticking to 3.8 or dropping Win 7. (I'm one of them since software I work on has to run in build environments setup for other projects, and such environments routinely stick to old OS versions due to breakage on updates). But this is what we have according to PEP 11, and a little grumbling here certainly won't change that :)
msg389445 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-03-24 11:55
FWIW, the installer change was only to forcibly warn naive users that they need to stick with the previous version, so I wouldn't read much into it. It's easily rolled back.

The real issue is that we need to decide how to drop support _somehow_, and following the company that has the most to gain/lose from declaring support for one of their platforms makes the most sense.

If we had a dedicated maintainer who was supporting Win7 and making releases for it, then we (i.e. they) could support it. But then, there's nothing to stop someone doing that already, and even to stop them charging money for it if they want (which they wouldn't be able to do under the auspices of python-dev). So I suspect nobody is really that motivated ;)

(Also, a "little bit of complaining" here is totally worthwhile, as it helps us gauge community sentiment. Without it, we're limited to trawling forums and Twitter - especially without conferences to actually meet and hear directly from people - and so our inputs are biased. Having polite, informed, discussion on the tracker is a great way for us to see and capture these positions.)
msg389449 - (view) Author: Mitja kocjančič (veso266) Date: 2021-03-24 12:44
not sure about the strategies here but maybe a better approach would be to kill support for unsupported version of windows in a major release
since I guess python 3 was a complete rewrite of python2 (at least the low level side I assume it was) 

and it would be easier for people to remeber (eg, if I have to rewrite my app because python4 has a major language differences I might as well drop support for older OSes in it), eg, python2 works on XP, python3 works on vista and up, python4 works on windows 10

for instance, I didn't even know you can run python3 on XP, I always thought that python2.7 is the last version that would run there

and since the code to support windows 7 is still present (almost, just the installer change would need to be rolleed back and some compiler declaratives: 
https://github.com/python/cpython/commit/0b72ccff56fb47e14f7b1f6590eafff8d104c229
https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5

I see no reason to touch it (it probably just stays there serving its purpose) and when python4 comes along (if its a rewrite then windows 7 hacks (would just not be written anymore)
msg389460 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-03-24 14:38
> not sure about the strategies here but maybe a better approach would be to kill support for unsupported version of windows in a major release

We do, but the "major" release is the second field of the version number (you can think of the first field as the "series" or "product" number).

Yes, this is not SemVer. Sorry. We pre-date SemVer.

Python 3.8 and earlier are just as supported for Windows 7 as our volunteers can handle, which is all that has ever been offered here. If people need better support than that, I'd suggest paying someone.
msg389476 - (view) Author: Alexey Izbyshev (izbyshev) * (Python triager) Date: 2021-03-24 16:59
> If we had a dedicated maintainer who was supporting Win7 and making releases for it, then we (i.e. they) could support it. But then, there's nothing to stop someone doing that already, and even to stop them charging money for it if they want (which they wouldn't be able to do under the auspices of python-dev). So I suspect nobody is really that motivated ;)

That's totally fair.

> (Also, a "little bit of complaining" here is totally worthwhile, as it helps us gauge community sentiment. Without it, we're limited to trawling forums and Twitter - especially without conferences to actually meet and hear directly from people - and so our inputs are biased. Having polite, informed, discussion on the tracker is a great way for us to see and capture these positions.)

I agree. In my comment, I only intended to contrast "complaining" with stepping up to do the work. I didn't mean to imply that it's inappropriate per-se.
History
Date User Action Args
2022-04-11 14:58:56adminsetgithub: 76773
2022-03-21 20:38:56steve.dowersetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2021-05-28 14:18:23kjsetnosy: + kj
pull_requests: + pull_request25026
2021-03-24 16:59:21izbyshevsetmessages: + msg389476
2021-03-24 14:38:18steve.dowersetmessages: + msg389460
2021-03-24 12:44:09veso266setmessages: + msg389449
2021-03-24 11:55:28steve.dowersetmessages: + msg389445
2021-03-23 22:35:20izbyshevsetmessages: + msg389413
2021-03-23 18:17:48CAM-Gerlachsetmessages: + msg389398
2021-03-23 11:13:31veso266setmessages: + msg389385
2021-03-23 09:23:55izbyshevsetmessages: + msg389378
2021-03-23 08:49:15veso266setnosy: + veso266
messages: + msg389377
2021-03-21 11:49:33pitrousetnosy: + pitrou
messages: + msg389225
2021-03-20 23:25:26gregory.p.smithsettype: enhancement
title: Drop support of Windows Vista and 7 in Python 3.9 -> Drop support of Windows Vista and Windows 7
2021-03-15 03:58:11CAM-Gerlachsetmessages: + msg388705
versions: + Python 3.10, - Python 3.9
2021-03-15 02:59:00eryksunsetmessages: + msg388703
2021-03-15 02:09:29DMI-1407setnosy: + DMI-1407
messages: + msg388700
2020-10-07 10:53:40python-devsetnosy: + python-dev
pull_requests: + pull_request21578
2020-03-23 20:39:39CAM-Gerlachsetmessages: + msg364899
2020-03-22 12:01:48steve.dowersetmessages: + msg364798
2020-03-22 09:53:53CAM-Gerlachsetmessages: + msg364793
2020-03-04 22:23:11vstinnersetnosy: - vstinner
2020-03-04 15:37:42CAM-Gerlachsetmessages: + msg363356
2020-03-04 14:48:31CAM-Gerlachsetmessages: + msg363352
2020-03-04 13:25:28CAM-Gerlachsetnosy: + CAM-Gerlach
messages: + msg363348
2019-09-26 16:31:33eryksunsetmessages: + msg353328
2019-09-26 14:51:19steve.dowersetmessages: + msg353312
2019-09-26 14:25:22vstinnersetmessages: + msg353308
2019-09-26 14:21:01eryksunsetmessages: + msg353307
2019-09-16 02:29:31eryksunsetmessages: + msg352502
2019-09-15 13:56:19eryksunsetmessages: + msg352476
2019-09-11 16:03:39zach.waresetmessages: + msg351965
2019-09-11 15:20:09zach.wareunlinkissue33166 dependencies
2019-09-11 13:55:16steve.dowersettitle: Drop support of Windows Vista in Python 3.8 -> Drop support of Windows Vista and 7 in Python 3.9
messages: + msg351882
versions: + Python 3.9, - Python 3.8
2019-09-11 13:52:53steve.dowersetpull_requests: + pull_request15586
2019-05-10 17:25:51ned.deilysetnosy: + lukasz.langa
2019-05-10 02:11:35vstinnersetmessages: + msg342041
2019-05-06 19:18:53eryksunsetnosy: + eryksun
messages: + msg341612
2019-05-06 15:35:22vstinnersetmessages: + msg341535
2019-05-06 15:34:16vstinnersetmessages: + msg341534
2019-05-06 15:32:47vstinnerlinkissue29075 superseder
2019-05-04 20:55:22terry.reedysettitle: Drop support of Windows Vista in Python 3.7 -> Drop support of Windows Vista in Python 3.8
2019-05-04 17:12:30ZackerySpytzsetnosy: + ZackerySpytz
messages: + msg341393
2019-01-24 00:06:12cheryl.sabellalinkissue33166 dependencies
2019-01-07 22:46:25steve.dowersetmessages: + msg333187
2019-01-07 20:33:44terry.reedysetmessages: + msg333186
2019-01-07 15:01:31vstinnersetmessages: + msg333161
2019-01-07 15:00:07vstinnersetstage: resolved -> patch review
pull_requests: + pull_request10929
2019-01-07 14:59:58vstinnersetstage: resolved -> resolved
pull_requests: + pull_request10928
2019-01-07 14:59:46vstinnersetstage: resolved -> resolved
pull_requests: + pull_request10927
2019-01-07 14:57:44vstinnersetstatus: closed -> open
resolution: out of date -> (no value)
messages: + msg333160

versions: + Python 3.8, - Python 3.7
2018-05-29 21:50:12vstinnersetstatus: open -> closed
resolution: out of date
messages: + msg318103

stage: patch review -> resolved
2018-03-08 17:45:23izbyshevsetnosy: + izbyshev
2018-01-20 00:45:54terry.reedysetmessages: + msg310308
2018-01-19 23:50:30vstinnersetmessages: + msg310303
2018-01-19 22:29:19zach.waresetmessages: + msg310297
2018-01-19 22:26:28terry.reedysetmessages: + msg310296
2018-01-19 22:26:15terry.reedysetmessages: - msg310295
2018-01-19 22:25:49terry.reedysetnosy: + terry.reedy
messages: + msg310295
2018-01-18 11:02:12vstinnersetmessages: + msg310234
2018-01-18 11:01:27steve.dowersetmessages: + msg310233
2018-01-18 09:38:45vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request5078
2018-01-18 09:37:18vstinnercreate