We should include the version resource in python[w].exe as well as python35.dll so that it can be properly identified. (If possible, we should do .pyd files too, though I don't think the version info will be displayed, so it's probably not worth it.)

Patch for the version info, and also for half of bpo-19143 since I was there.

Add <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> for Windows 10 (source: http://blogs.msdn.com/b/chuckw/archive/2013/09/10/manifest-madness.aspx)

Anyone have any opinions on this? My only hesitation is adding the Windows 10 UUID, which will fix GetVersion but may cause other API problems, and we're certainly not testing against Windows 10 yet. (On the other hand, it's easy enough to remove that single UUID later if there's an issue we can't fix.)

I'm keen to put it in and forget about it, so if not, I'll just do it :)

Steve, could you outline the need / impact for this, please? (ie can you inform my ignorance?).

Sure :)

If you view Properties in Windows for Python 3.4's python[w].exe and look at the Details tab, it's very blank (for me it shows 'Application', the size and the modification date). However, if you look at python34.dll or py.exe it has a description, version, copyright message, etc. The first part of the patch adds this information to python[w].exe as well.

The second part is dealing with bpo-19143, which is where GetVersion() lies about the Windows version if you haven't explicitly declared that you know about that version. Currently on Windows 8.1 (and 10), sys.getwindowsversion() will tell you that it's Windows 8 (6.2.9200).

The patch here adds the declarations to a manifest file such that Python 3.5 is "aware" of Windows 8.1 and so it doesn't need the compatibility shims/version lies that are otherwise applied. (The patch on bpo-19143 is for the platform module so that it will always read the correct version, but this is intended for logging/system info rather than making decisions about API availability and behaviour.)

+1 from me, then.

New changeset 3f7e483cebef by Steve Dower in branch 'default':
bpo-23018: Add version info to python[w].exe
https://hg.python.org/cpython/rev/3f7e483cebef

PC/python_ver_rc.h now is not compatible with clinic.py.

$ ./python Tools/clinic/clinic.py --make
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 4204, in <module>
    sys.exit(main(sys.argv[1:]))
  File "Tools/clinic/clinic.py", line 4184, in main
    parse_file(path, force=ns.force, verify=not ns.force)
  File "Tools/clinic/clinic.py", line 1743, in parse_file
    raw = f.read()
  File "/home/serhiy/py/cpython/Lib/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa9 in position 199: invalid start byte

Either convert PC/python_ver_rc.h to UTF-8, or escape copyright sign "©" as "\xa9" (if Latin1 is needed), or replace it witch ASCII "(c)".

Looks like the .rc files should actually be UCS-2, since that's how the strings are going to be stored into the executables.

If I rename the .h file to .h_ (and change the encoding to UCS-2 with BOM), will it be ignored by argument clinic?

I afraid that adding source file that can't be easy handled by Unix text tools (such as diff) is not good idea. Does "\xa9" work?

Digging around the likely encodings to be running on Windows machines, it looks like 0xA9 is always the right symbol, so that change should be fine.

New changeset 843a8ee94270 by Steve Dower in branch 'default':
Closes bpo-23018: Replace copyright symbol with escape.
https://hg.python.org/cpython/rev/843a8ee94270