It appears there have been some console related changes in Windows 11

======================================================================
ERROR: test_open_name (test.test_winconsoleio.WindowsConsoleIOTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeremy\source\repos\cpython\lib\test\test_winconsoleio.py", line 95, in test_open_name
    f = open('C:/con', 'rb', buffering=0)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'C:/con'

======================================================================
FAIL: test_conout_path (test.test_winconsoleio.WindowsConsoleIOTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeremy\source\repos\cpython\lib\test\test_winconsoleio.py", line 118, in test_conout_path
    self.assertIsInstance(f, ConIO)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: <_io.FileIO name='C:\\Users\\Jeremy\\AppData\\Local\\Temp\\tmpoqx235b0\\CONOUT$' mode='wb' closefd=True> is not an instance of <class '_io._WindowsConsoleIO'>

----------------------------------------------------------------------

Note that I have a pending PR for adding a Windows 11 build worker that will, once merged, help in testing a solution.

This will be the change to make "special" filenames only be special when used on their own, and not as part of a path (e.g. you shouldn't have any trouble with "aux" or "com" filenames either). I had expected it to roll out sooner, but I guess Windows 11 is when it arrives.

We'll have to go through our regression tests that rely on this behaviour. Happily, I don't think we merged any major "fixes" for the old behaviour (I've been discouraging them, but haven't been able to say that the fix was coming :( ).

> This will be the change to make "special" filenames only be 
> special when used on their own, and not as part of a path

For some reason, Windows 11 still reserves case-insensitive "nul" in qualified paths, but none of the other DOS device names. Thankfully it's just "nul", and not "nul.txt", since they changed it to never reserve a name with an extension. So "./nul" -> "\\.\nul", but "./nul.txt" resolve to the filename in the current directory.

For cases such as "./con" vs "con", this is another example in favor of changing ntpath.normpath() and pathlib.Path to preserve an initial leading dot component. Other cases include alternate data streams on single-letter filenames (e.g. accessing "C:stream" as "./C:stream") and executable paths that should explicitly refer to the current directory (e.g. "./spam.exe").

New changeset de4052fe0633e3a053e66c8477f13677054d6ede by Jeremy Kloth in branch 'main':
bpo-45354: Skip obsolete device name tests on Windows 11 (GH-28712)
https://github.com/python/cpython/commit/de4052fe0633e3a053e66c8477f13677054d6ede

Thanks, Jeremy! And thanks for being on top of getting the Win11 buildbot set up!

New changeset d0d0909a3a0b553826d1ddbb04a676fdabb61359 by Miss Islington (bot) in branch '3.10':
bpo-45354: Skip obsolete device name tests on Windows 11 (GH-28712)
https://github.com/python/cpython/commit/d0d0909a3a0b553826d1ddbb04a676fdabb61359

New changeset 63c9a6cc8b48740c88199b5150c9948b1a61756b by Miss Islington (bot) in branch '3.9':
bpo-45354: Skip obsolete device name tests on Windows 11 (GH-28712)
https://github.com/python/cpython/commit/63c9a6cc8b48740c88199b5150c9948b1a61756b

I reopen the issue: test_winconsoleio fails on the "AMD64 Windows11 3.x" buildbot, whereas the purpose of this issue was to get test_winconsoleio pass on Windows 11.

First AMD64 Windows11 3.x failure:
https://buildbot.python.org/all/#/builders/733/builds/243

The embedded manifest in python[_d].exe is missing, so the process is running with Windows 8 compatibility mode (i.e. 6.2.9200), and thus the check for Windows 11+ (10.0.22000+) is false. It's disappointing that compatibility mode doesn't restore the old DOS device behavior, but whatever.

bpo-45220 removed the winuser.h include from the PC\*.rc files, so the RT_MANIFEST resource type macro isn't defined. It needs to be defined in the file or a common header. For example:

    #define RT_MANIFEST 24
    1 RT_MANIFEST "python.manifest"

It would also work to add RT_MANIFEST=24 to the ResourceCompile PreprocessorDefinitions in PCbuild\pyproject.props. Though to me, adding the definition there is obscure compared to including a private header, such as "resourcetype.h".

> bpo-45220 removed the winuser.h include from the PC\*.rc files, so the RT_MANIFEST resource type macro isn't defined. It needs to be defined in the file or a common header. For example:
> 
>      #define RT_MANIFEST 24
>      1 RT_MANIFEST "python.manifest"

I vote for this approach, since apparently RC doesn't complain about 
undefined macros. Otherwise I'd put it in the build scripts.

It's weird that the WinSDK breaks RC with the winuser.h header, but 
since it does, we don't really have a choice but to hard-code the value.

> #define RT_MANIFEST 24

If possible, add a comment with a reference to this issue (bpo-45354) to help future readers ;-)

FYI, adding a fix for this on issue45220