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

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

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

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

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.

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.

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.

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

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.

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