python · serhiy-storchaka · May 10, 2022 · May 9, 2022 · May 9, 2022 · May 9, 2022
diff --git a/Doc/extending/windows.rst b/Doc/extending/windows.rst
@@ -106,8 +106,7 @@ Using DLLs in Practice
 
 
 Windows Python is built in Microsoft Visual C++; using other compilers may or
-may not work (though Borland seems to).  The rest of this section is MSVC++
-specific.
+may not work.  The rest of this section is MSVC++ specific.
 
 When creating DLLs in Windows, you must pass :file:`pythonXY.lib` to the linker.
 To build two DLLs, spam and ni (which uses C functions found in spam), you could
@@ -134,4 +133,3 @@ Developer Studio will throw in a lot of import libraries that you do not really
 need, adding about 100K to your executable.  To get rid of them, use the Project
 Settings dialog, Link tab, to specify *ignore default libraries*.  Add the
 correct :file:`msvcrtxx.lib` to the list of libraries.
-
diff --git a/Doc/faq/windows.rst b/Doc/faq/windows.rst
@@ -26,8 +26,8 @@ with running programs from the Windows command line then everything will seem
 obvious; otherwise, you might need a little more guidance.
 
 Unless you use some sort of integrated development environment, you will end up
-*typing* Windows commands into what is variously referred to as a "DOS window"
-or "Command prompt window".  Usually you can create such a window from your
+*typing* Windows commands into what is referred to as a
+"Command prompt window".  Usually you can create such a window from your
 search bar by searching for ``cmd``.  You should be able to recognize
 when you have started such a window because you will see a Windows "command
 prompt", which usually looks like this:
@@ -186,9 +186,6 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
    by the Windows ``GetProcAddress()`` routine.  Macros can make using these
    pointers transparent to any C code that calls routines in Python's C API.
 
-   Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf.exe
-   first.
-
    .. XXX what about static linking?
 
 2. If you use SWIG, it is easy to create a Python "extension module" that will
@@ -279,4 +276,3 @@ How do I check for a keypress without blocking?
 Use the :mod:`msvcrt` module.  This is a standard Windows-specific extension module.
 It defines a function ``kbhit()`` which checks whether a keyboard hit is
 present, and ``getch()`` which gets one character without echoing it.
-
diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst
@@ -1360,10 +1360,6 @@ way is to instantiate one of the following classes:
    functions in these libraries use the ``stdcall`` calling convention, and are
    assumed to return :c:type:`int` by default.
 
-   On Windows CE only the standard calling convention is used, for convenience the
-   :class:`WinDLL` and :class:`OleDLL` use the standard calling convention on this
-   platform.
-
 The Python :term:`global interpreter lock` is released before calling any
 function exported by these libraries, and reacquired afterwards.
 
@@ -1664,8 +1660,7 @@ See :ref:`ctypes-callback-functions` for examples.
 .. function:: WINFUNCTYPE(restype, *argtypes, use_errno=False, use_last_error=False)
 
    Windows only: The returned function prototype creates functions that use the
-   ``stdcall`` calling convention, except on Windows CE where
-   :func:`WINFUNCTYPE` is the same as :func:`CFUNCTYPE`.  The function will
+   ``stdcall`` calling convention.  The function will
    release the GIL during the call.  *use_errno* and *use_last_error* have the
    same meaning as above.
 

diff --git a/Doc/library/optparse.rst b/Doc/library/optparse.rst
@@ -131,7 +131,7 @@ option
    These option syntaxes are not supported by :mod:`optparse`, and they never
    will be.  This is deliberate: the first three are non-standard on any
    environment, and the last only makes sense if you're exclusively targeting
-   VMS, MS-DOS, and/or Windows.
+   Windows or certain legacy platforms (e.g. VMS, MS-DOS).
 
 option argument
    an argument that follows an option, is closely associated with that option,

diff --git a/Doc/library/os.path.rst b/Doc/library/os.path.rst
@@ -5,7 +5,7 @@
    :synopsis: Operations on pathnames.
 
 **Source code:** :source:`Lib/posixpath.py` (for POSIX) and
-:source:`Lib/ntpath.py` (for Windows NT).
+:source:`Lib/ntpath.py` (for Windows).
 
 .. index:: single: path; operations
 

diff --git a/Doc/library/tempfile.rst b/Doc/library/tempfile.rst
@@ -84,7 +84,7 @@ The module defines the following user-callable items:
    file-like object.  Whether the name can be
    used to open the file a second time, while the named temporary file is
    still open, varies across platforms (it can be so used on Unix; it cannot
-   on Windows NT or later).  If *delete* is true (the default), the file is
+   on Windows).  If *delete* is true (the default), the file is
    deleted as soon as it is closed.
    The returned object is always a file-like object whose :attr:`!file`
    attribute is the underlying true file object. This file-like object can

diff --git a/Doc/using/windows.rst b/Doc/using/windows.rst
@@ -425,7 +425,7 @@ dependants, such as Idle), pip and the Python documentation are not included.
 .. note::
 
     The embedded distribution does not include the `Microsoft C Runtime
-    <https://www.microsoft.com/en-us/download/details.aspx?id=48145>`_ and it is
+    <https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist#visual-studio-2015-2017-2019-and-2022>`_ and it is
     the responsibility of the application installer to provide this. The
     runtime may have already been installed on a user's system previously or
     automatically via Windows Update, and can be detected by finding
@@ -559,27 +559,22 @@ System variables, you need non-restricted access to your machine
     Windows will concatenate User variables *after* System variables, which may
     cause unexpected results when modifying :envvar:`PATH`.
 
-    The :envvar:`PYTHONPATH` variable is used by all versions of Python 2 and
-    Python 3, so you should not permanently configure this variable unless it
-    only includes code that is compatible with all of your installed Python
+    The :envvar:`PYTHONPATH` variable is used by all versions of Python,
+    so you should not permanently configure it unless the listed paths
+    only include code that is compatible with all of your installed Python
     versions.
 
 .. seealso::
 
-    https://www.microsoft.com/en-us/wdsi/help/folder-variables
-      Environment variables in Windows NT
+    https://docs.microsoft.com/en-us/windows/win32/procthread/environment-variables
+      Overview of environment variables on Windows
 
-    https://technet.microsoft.com/en-us/library/cc754250.aspx
-      The SET command, for temporarily modifying environment variables
+    https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1
+      The ``set`` command, for temporarily modifying environment variables
 
-    https://technet.microsoft.com/en-us/library/cc755104.aspx
-      The SETX command, for permanently modifying environment variables
+    https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/setx
+      The ``setx`` command, for permanently modifying environment variables
 
-    https://support.microsoft.com/en-us/help/310519/how-to-manage-environment-variables-in-windows-xp
-      How To Manage Environment Variables in Windows XP
-
-    https://www.chem.gla.ac.uk/~louis/software/faq/q1.html
-      Setting Environment variables, Louis J. Farrugia
 
 .. _windows-path-mod:
 
@@ -687,22 +682,22 @@ You should find that the latest version of Python you have installed is
 started - it can be exited as normal, and any additional command-line
 arguments specified will be sent directly to Python.
 
-If you have multiple versions of Python installed (e.g., 2.7 and |version|) you
-will have noticed that Python |version| was started - to launch Python 2.7, try
+If you have multiple versions of Python installed (e.g., 3.7 and |version|) you
+will have noticed that Python |version| was started - to launch Python 3.7, try
 the command:
 
 ::
 
-  py -2.7
+  py -3.7
 
-If you want the latest version of Python 2.x you have installed, try the
+If you want the latest version of Python 3 you have installed, try the
 command:
 
 ::
 
-  py -2
+  py -3
 
-You should find the latest version of Python 2.x starts.
+You should find the latest version of Python 3.x starts.
 
 If you see the following error, you do not have the launcher installed:
 
@@ -759,9 +754,9 @@ is printed.  Now try changing the first line to be:
 
 Re-executing the command should now print the latest Python 3.x information.
 As with the above command-line examples, you can specify a more explicit
-version qualifier.  Assuming you have Python 2.6 installed, try changing the
-first line to ``#! python2.6`` and you should find the 2.6 version
-information printed.
+version qualifier.  Assuming you have Python 3.7 installed, try changing
+the first line to ``#! python3.7`` and you should find the |version|
+version information printed.
 
 Note that unlike interactive use, a bare "python" will use the latest
 version of Python 2.x that you have installed.  This is for backward
@@ -814,8 +809,8 @@ shebang lines starting with ``/usr``.
 Any of the above virtual commands can be suffixed with an explicit version
 (either just the major version, or the major and minor version).
 Furthermore the 32-bit version can be requested by adding "-32" after the
-minor version. I.e. ``/usr/bin/python2.7-32`` will request usage of the
-32-bit python 2.7.
+minor version. I.e. ``/usr/bin/python3.7-32`` will request usage of the
+32-bit python 3.7.
 
 .. versionadded:: 3.7
 
@@ -908,19 +903,19 @@ Examples:
   ``python2`` will use the latest Python 2.x version installed and
   the command ``python3`` will use the latest Python 3.x installed.
 
-* The commands ``python3.1`` and ``python2.7`` will not consult any
+* The command ``python3.7`` will not consult any
   options at all as the versions are fully specified.
 
 * If ``PY_PYTHON=3``, the commands ``python`` and ``python3`` will both use
   the latest installed Python 3 version.
 
-* If ``PY_PYTHON=3.1-32``, the command ``python`` will use the 32-bit
-  implementation of 3.1 whereas the command ``python3`` will use the latest
+* If ``PY_PYTHON=3.7-32``, the command ``python`` will use the 32-bit
+  implementation of 3.7 whereas the command ``python3`` will use the latest
   installed Python (PY_PYTHON was not considered at all as a major
   version was specified.)
 
-* If ``PY_PYTHON=3`` and ``PY_PYTHON3=3.1``, the commands
-  ``python`` and ``python3`` will both use specifically 3.1
+* If ``PY_PYTHON=3`` and ``PY_PYTHON3=3.7``, the commands
+  ``python`` and ``python3`` will both use specifically 3.7
 
 In addition to environment variables, the same settings can be configured
 in the .INI file used by the launcher.  The section in the INI file is
@@ -931,21 +926,21 @@ an environment variable will override things specified in the INI file.
 
 For example:
 
-* Setting ``PY_PYTHON=3.1`` is equivalent to the INI file containing:
+* Setting ``PY_PYTHON=3.7`` is equivalent to the INI file containing:
 
 .. code-block:: ini
 
   [defaults]
-  python=3.1
+  python=3.7
 
-* Setting ``PY_PYTHON=3`` and ``PY_PYTHON3=3.1`` is equivalent to the INI file
+* Setting ``PY_PYTHON=3`` and ``PY_PYTHON3=3.7`` is equivalent to the INI file
   containing:
 
 .. code-block:: ini
 
   [defaults]
   python=3
-  python3=3.1
+  python3=3.7
 
 Diagnostics
 -----------
@@ -1132,13 +1127,14 @@ is a collection of modules for advanced Windows-specific support.  This includes
 utilities for:
 
 * `Component Object Model
-  <https://docs.microsoft.com/en-us/windows/desktop/com/component-object-model--com--portal>`_
+  <https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal>`_
   (COM)
 * Win32 API calls
 * Registry
 * Event log
-* `Microsoft Foundation Classes <https://msdn.microsoft.com/en-us/library/fe1cf721%28VS.80%29.aspx>`_ (MFC)
-  user interfaces
+* `Microsoft Foundation Classes
+  <https://docs.microsoft.com/en-us/cpp/mfc/mfc-desktop-applications>`_
+  (MFC) user interfaces
 
 `PythonWin <https://web.archive.org/web/20060524042422/
 https://www.python.org/windows/pythonwin/>`_ is a sample MFC application
@@ -1149,7 +1145,7 @@ shipped with PyWin32.  It is an embeddable IDE with a built-in debugger.
    `Win32 How Do I...? <http://timgolden.me.uk/python/win32_how_do_i.html>`_
       by Tim Golden
 
-   `Python and COM <http://www.boddie.org.uk/python/COM.html>`_
+   `Python and COM <https://www.boddie.org.uk/python/COM.html>`_
       by David and Paul Boddie
 
 
@@ -1163,18 +1159,6 @@ you can distribute your application without requiring your users to install
 Python.
 
 
-WConio
-------
-
-Since Python's advanced terminal handling layer, :mod:`curses`, is restricted to
-Unix-like systems, there is a library exclusive to Windows as well: Windows
-Console I/O for Python.
-
-`WConio <http://newcenturycomputers.net/projects/wconio.html>`_ is a wrapper for
-Turbo-C's :file:`CONIO.H`, used to create text user interfaces.
-
-
-
 Compiling Python on Windows
 ===========================
 
@@ -1184,21 +1168,13 @@ latest release's source or just grab a fresh `checkout
 <https://devguide.python.org/setup/#getting-the-source-code>`_.
 
 The source tree contains a build solution and project files for Microsoft
-Visual Studio 2015, which is the compiler used to build the official Python
+Visual Studio, which is the compiler used to build the official Python
 releases. These files are in the :file:`PCbuild` directory.
 
 Check :file:`PCbuild/readme.txt` for general information on the build process.
 
-
 For extension modules, consult :ref:`building-on-windows`.
 
-.. seealso::
-
-   `Python + Windows + distutils + SWIG + gcc MinGW <http://sebsauvage.net/python/mingw.html>`_
-      or "Creating Python extensions in C/C++ with SWIG and compiling them with
-      MinGW gcc under Windows" or "Installing Python extension with distutils
-      and without Microsoft Visual C++" by Sébastien Sauvage, 2003
-
 
 Other Platforms
 ===============
@@ -1207,12 +1183,12 @@ With ongoing development of Python, some platforms that used to be supported
 earlier are no longer supported (due to the lack of users or developers).
 Check :pep:`11` for details on all unsupported platforms.
 
-* `Windows CE <http://pythonce.sourceforge.net/>`_ is still supported.
-* The `Cygwin <https://cygwin.com/>`_ installer offers to install the Python
-  interpreter as well (cf. `Cygwin package source
-  <ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
-  release/python>`_, `Maintainer releases
-  <http://www.tishler.net/jason/software/python/>`_)
+* `Windows CE <http://pythonce.sourceforge.net/>`_ is
+  `no longer supported <https://github.com/python/cpython/issues/71542>`__
+  since Python 3 (if it ever was).
+* The `Cygwin <https://cygwin.com/>`_ installer offers to install the
+  `Python interpreter <https://cygwin.com/packages/summary/python3.html>`__
+  as well
 
 See `Python for Windows <https://www.python.org/downloads/windows/>`_
 for detailed information about platforms with pre-compiled installers.
@@ -18,16 +18,16 @@ All PC ports use this scheme to try to set up a module search path:
 
   1) The script location; the current directory without script.
   2) The PYTHONPATH variable, if set.
-  3) For Win32 platforms (NT/95), paths specified in the Registry.
+  3) Paths specified in the Registry.
   4) Default directories lib, lib/win, lib/test, lib/tkinter;
      these are searched relative to the environment variable
      PYTHONHOME, if set, or relative to the executable and its
      ancestors, if a landmark file (Lib/string.py) is found ,
      or the current directory (not useful).
   5) The directory containing the executable.
 
-The best installation strategy is to put the Python executable (and
-DLL, for Win32 platforms) in some convenient directory such as
+The best installation strategy is to put the Python executable and
+DLL in some convenient directory such as
 C:/python, and copy all library files and subdirectories (using XCOPY)
 to C:/python/lib.  Then you don't need to set PYTHONPATH.  Otherwise,
 set the environment variable PYTHONPATH to your Python search path.