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.

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.

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.

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".

3.4 was the last version to support XP.

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...

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.

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.

Hello 2018, I reopen the issue and change the version to Python 3.8.

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 3ab064e
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.

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.

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.

See also bpo-29075.

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*?

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

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.

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 d267ac2 by Victor Stinner in branch 'master':
bpo-36778: cp65001 encoding becomes an alias to utf_8 (GH-13230)
d267ac2

I'll at least make a start by updating the minimum API version.

New changeset 0b72ccf by Zachary Ware (Steve Dower) in branch 'master':
bpo-32592: Set Windows 8 as the minimum required version for API support (GH-15951)
0b72ccf

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.

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).

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)

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] izbyshev@6a65eba
[2] https://en.wikipedia.org/wiki/Windows_7

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)

In my limited understanding, all PR bpo-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.

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

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.)

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:
0b72ccf
izbyshev@6a65eba

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)

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.

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.

I took care of the docs changes mentioned in my comment above. Aside from the installer updates and the other breaking security change, have any of the code changes cleanups mentioned in my other comment or discussed further above been made? If so, are they still work making for 3.12?

Just for posterity, since I couldn't find it mentioned anywhere here for some reason, it was PR #21656 that actually dropped support for Windows <8.1 in the installer.