Eryk Sun added the comment: > it's not possible to tell by inspection the version of a Python > interpreter.
If getting the version of python[w].exe is ever required, it should be simple for 3.5+, for which python[w].exe has standard file version information with the product version (i.e. GetFileVersionInfo, etc). For older versions you could walk the EXE's import directory, looking for a dependency on pythonXY.dll. First map the executable as data via CreateFileW, CreateFileMapping, and MapViewOfFile. Next get pointers to the IMAGE_NT_HEADERS and the first IMAGE_IMPORT_DESCRIPTOR via ImageNtHeader and ImageDirectoryEntryToData. Finally, walk the array of import descriptors (while the "Characteristics" field isn't 0) to get the "Name" of each DLL dependency. It's a relative address that can be converted to a char pointer via ImageRvaToVa. Using relative addresses allows this to work if a 32-bit application is inspecting a 64-bit image and vice versa. That said, it's far simpler to just support versioned executable names (e.g. python3.exe, python3.6.exe, python3.6-32.exe, pythonw3.exe, pythonw3.6.exe, pythonw3.6-32.exe). Even if we don't install links/copies with these names, I don't see the harm in allowing the launcher to look for them. Users can create the links manually; I've seen people on SO that do this. I'm uploading a patch that implements this for "env" shebangs. ---------- keywords: +patch Added file: http://bugs.python.org/file46576/issue_28686_01.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
