You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/zooba'closed_at=<Date2015-02-20.17:13:35.201>created_at=<Date2014-12-09.05:27:42.744>labels= ['type-feature', 'OS-windows']
title='Add version info to python'updated_at=<Date2015-02-20.17:13:35.201>user='https://github.com/zooba'
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.)
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 :)
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.)
$ ./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
Activity
zooba commentedon Dec 9, 2014
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.)
zooba commentedon Dec 9, 2014
Patch for the version info, and also for half of bpo-19143 since I was there.
zooba commentedon Dec 31, 2014
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)
zooba commentedon Jan 12, 2015
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 :)
tjguk commentedon Jan 13, 2015
Steve, could you outline the need / impact for this, please? (ie can you inform my ignorance?).
zooba commentedon Jan 13, 2015
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.)
tjguk commentedon Jan 14, 2015
+1 from me, then.
[-]Add version info to python[w].exe[/-][+]Add version info to python[/+]python-dev commentedon Jan 15, 2015
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
serhiy-storchaka commentedon Feb 20, 2015
PC/python_ver_rc.h now is not compatible with clinic.py.
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)".
zooba commentedon Feb 20, 2015
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?
serhiy-storchaka commentedon Feb 20, 2015
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?
zooba commentedon Feb 20, 2015
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.
python-dev commentedon Feb 20, 2015
New changeset 843a8ee94270 by Steve Dower in branch 'default':
Closes bpo-23018: Replace copyright symbol with escape.
https://hg.python.org/cpython/rev/843a8ee94270