It is well known that Python 3.9 / 3.10 don’t work with Windows 7. It is somewhat annoying It would be great if it worked on Win7, because even if Win7 is EOL for consumers, Win7 keeps being supported by paid Extended Support Updates (ESU) till 2023 (and one variant till 2024). Many people (even those not using ESU) still use Win7 for some projects (example: computer not connected to any networking, so no security problem if the OS is not supported).
There are two workarounds:
a fork /NulAsh/cpython on Github
an implementation of api-ms-win-core-path-l1-1-0.dll based on Wine code: /nalexandru/api-ms-win-core-path-HACK on Github (sorry I’m not allowed to post links in my posts)
Problem: installing third-party “hacks” or releases like these is risky in terms of security, it would be better to use a trusted official version.
Would there be a way to provide an official python .org solution?
Here the modifications are really, really minor, so it is inconvenient to not support Win7 only because of a few lines of code. (It the entire Python Windows code used new Win 8/10 API, then it would be a different story, but here it’s really small).
Could the release team publish at least one version (3.9 or 3.10) for Win7?
More details: it does not run because api-ms-win-core-path-l1-1-0.dll is missing (see also bugs.python .org/issue32592, bugs.python .org/issue44656, stackoverflow .com/questions/66718131/software-based-on-python-3-9-is-not-working-on-windows-7)
If you’re paying to get continued support for Windows 7, maybe as part of that you should be asking Microsoft to provide/support api-ms-win-core-path-l1-1-0.dll on Windows 7?
Is there a specific use case where your libraries/applications requires a very recent version of Python >=3.9, but you are also stuck on over a decade-old Windows 7 ESU? This seems like a fairly unlikely corner case, and it seems likely that another solution is possible, even if not ideal.
In any case, in order for this to happen, volunteers have to put in the work to develop, package, test and deploy a Python release for an EOL OS that is only (officially) supported for a handful of high-end corporate customers, at considerable cost. If you’re willing to offer funding to this end, it is possible that this could be arranged. Otherwise, it seems unlikely that the already overloaded release managers and core devs will be able to make this happen, but there are many alternatives (use a still-supported older version, fork it, patch it, add the DLL, pay your vendor to support it, pay a third party to support it, upgrade, etc). More details of your specific use case would be helpful in recommending one.
If you’re paying to get continued support for Windows 7
asking is for volunteers to put in all the work, for free, to develop, package, test and deploy a Python release for an EOL OS that is only supported for a handful of high-end corporate customers, including presumably your firm
@pf_moore@CAM-Gerlach in my case I’m not paying for MS Win7 extended support, I just mentioned ESU because I know lots of people still use it in this context until 2023 or 2024. My use case is for a few hobby projects for which “everything works” fine with Win7, and migrating to Win10 would be unnecessarily complicated (computer with no internet at all anyway so Win7 being obsolete isn’t a security problem), however using latest Python versions would be nice if possible.
As I read many posts on various forums about people wanting the same thing, I posted this question.
Since there are very very very few lines of code that prevent python3.9/3.10 to run on Win7, I thought maybe it would be possible to add something like in future versions of 3.10, at the start of the interpreter:
# pseudo_code
if platform <= "Win7":
use the code from 3.8 before the commit https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5
else:
use the current code requiring api-ms-win-core-path-xxx.dll
This would:
solve a few open posts on bugs.python.org
happily provide a solution for all projects still using Win7
this would, of course, not change anything for Python on Win8.1, Win10, Win11
I was surprised at the aggressive tone of the responses here (yes, we’re volunteers, but usually we don’t give people such a hard time over it) until I saw that the OP started by using the word “annoying” (always a trigger word, even if qualified by “somewhat”) and seemed to think that producing a set of binaries for an antiquated platform is a piece of cake.
I apologize, @josephernest , if my comments above came across as overly aggressive or negative against you. I’ve revised them to better reflect my intent and avoid phrasing that could be read as such.
If I was a bit miffed about the situation, it wasn’t at you or anything you said (even the “annoying” bit, which didn’t bother me so much), but due to what I’d read in the Stack Overflow thread you linked, which contained some pretty nasty statements about Python’s developers, including some directed specifically at my and others’ own comments in bpo-32592, linked above and in the SO issue. Specifically, things like:
It’s not worth time/money to e.g. replace lab computers just because an OCD developer who doesn’t know how to load DLLs wanted to inflate his LoC performance metric.
[…] the developers have decided to arbitrarily drop support quoting “PEP 11” policy which states – for no real reason, it’s made up – that Windows releases […]
there really isn’t a reason to obsessively/compusively delete low-level support code than to annoy users with old computers.
The link you sent [to the above issue] is babbling: they really don’t know what they’re doing.
I was frankly disgusted by the entitlement shown by those users, and the vitriol they were directing at hardworking, volunteer core developers creating something that they not only used gratis, but were also libre to change however they saw fit. However, I shouldn’t have let that leak over into my reply to you, who did none of that, and I’m very sorry about that.
Note that the following claim seems to misunderstand exactly what was deemed “unsafe”:
It appears the “api-ms-win-core-path-l1-1-0.dll” error is because one of the developers does not understand load-time vs. run-time library import. The commit has the word “unsafe”, but “unsafe” relates to the library’s (lack of) interaction with memory management/garbage collection, not how the library’s functions are called/loaded. bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) · izbyshev/cpython@6a65eba · GitHub
The original LoadLibraryW(L"api-ms-win-core-path-l1-1-0.dll") call was unsafe in terms of the default DLL search path in Windows 7. The load was made safe in 3.6-3.8 by changing it to use LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32). Steve opted to use a static import in 3.9+ under the assumption that Windows 7 would not be supported. This static import is safe in Windows 8+ because the API set is not a physical file that gets searched for. The loader maps it to the base API DLL, “kernelbase.dll”.
Yeah, that was pretty on par for StackOverflow. (I hadn’t followed that link.) It’s best to ignore forums like that (there are quite a few others, like Reddit and Hacker News) – occasionally there’s good stuff there (I use StackOverflow occasionally :-), but there’s so much ranting that it’s best to have a blanket “don’t read the comments” policy.
Thanks for your answer @guido! I was wondering the same thing as I was writing the post: “Is the word annoying too strong”? Fun fact: as a non-native English speaker, every now and then I search precisely this same thing, and I even did once again yesterday: how to translate the very-light “C’est dommage que X n’est pas possible” from French to English: all candidates seem too strong: “it’s a pity”, “it’s a shame” (shame is a strong word, isn’t it?) , “it is annoying”, “it is too bad that”: all of these seem a bit too strong, and I never found a good translation. Maybe the best translation would be only “it would be great if X is possible” Sorry for this long off-topic side remark but I was wondering the same thing for a long time (because in this “art” of communicating on internet, you’re right, negative words like annoying can trigger answers based on this).
I apologize, @josephernest , if my comments above came across as overly aggressive or negative against you.
@CAM-Gerlach no no, really no problem at all! I did not take this personally, or negatively - by the way my original post was also not well worded. Thanks for your message.
<end meta>
About the main question, do you think there is a possible solution for Win7 support in future Python 3.10 versions?
Either by using something like:
if platform <= Win7
use 3.8 code, with LoadLibraryExW(...)
else
use current code
The load was made safe in 3.6-3.8 by changing it to use LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) . Steve opted to use a static import in 3.9+ under the assumption that Windows 7 would not be supported. This static import is safe in Windows 8+ because the API set is not a physical file that gets searched for. The loader maps it to the base API DLL, “kernelbase.dll”.
or another solution?
Thanks again for your answers!
I know it shouldn’t, but Windows 7 is really still used on many machines in the world (for example on machines that are never connected to a network, and the potential security risk is really small), and if it’s not too complicated (eg. if a simple branch “if platform <= Win7” and a few lines of code can do it), then the support would be great (if not too time-consuming for the team of course).
In my case, no it wasn’t. I was reacting badly mainly because I’ve been involved in rather too many demands in other forums that volunteers spend time creating work-arounds for bugs in paid-for software. I let that frustration spill over here, for which I apologise.
I don’t know regarding the LoadLibrary call that you mention (I’m not an expert in that area) but the main problem will likely be that people will need to remember not to use functions that are only available in WIndows 8+, and it’s quite likely someone will forget at some point. As (I believe) we no longer have buildbots running Windows 7, nothing will catch such issues, and we’ll be back in the same situation of Python not working on Windows 7. I don’t think we’re likely to take on the maintenance burden of fully reinstating Windows 7 support, so I’m not sure how much practical benefit there would be in a one-off “get it working again” fix.
There are a few other changes in 3.9 that would also make things unsafe on Win7 (including that LoadLibrary fix mentioned a few times). The method we use for installing the UCRT changed significantly, for example.
Changing to dynamic platform detection would be a big step backwards in safety, as we also have to switch a few other function calls to dynamic loads rather than static linking with the standard Windows header files. We also don’t have any build support right now for specifying a target Windows version, and so making it easier to statically build for an earlier version is also non-trivial.
Ultimately, we need to drop things eventually, and the rule we have is the one that’s been in place for almost a decade now. As Paul said, we no longer have access to Windows 7, so upstream testing is impossible. Things are more complicated within Windows 10, where we’ve dropped support for - and probably broken - about 5 updates, none of which are clearly named (but luckily the free updates mean they have little use by now).
So at this point, Windows 7 requires paid support, whether through your own employees or a third-party vendor. If volunteers were suddenly to re-support it for free, we’d be hurting other peoples’ legitimate business models that were developed based on what we said we would(n’t) do.
My French isn’t great, but I would say that “C’est dommage que” in this context best translates to “It’s too bad that”. This does not have the same “red flag” effect (on me at least). The thing with claiming that something is “annoying”, to me, is that it makes my mind go
Oh, you are annoyed? Well, let me tell you how annoyed I am having to answer these stupid emails all the time. No good deed goes unpunished! (etc.)
(Obviously I don’t respond like that, but it’s where my mind goes first, and that clouds how I feel when responding. And no, your email wasn’t stupid, you just had no idea how much work it is for our volunteers to crank out a release for your platform of choice.)
OTOH if you had started with “It’s too bad that Python 3.9 doesn’t support Windows 7” my thoughts would be something like
Yes, it is too bad. Sadly it would be a lot of work to support it.
Which is more easily turned into a good response. (All it needs is a high-level explanation of how much effort it would take.)
From the perspective of a technical writer and copyeditor, language and cultural differences in word usage fascinate me, and I’m usually pretty attuned to the often subtle queues that another user is not an English native, and can often even pick up on what their native language is (or at least language family) based on their “accent” in written English, and typically try to give others more benefit of the doubt in such cases. In this case, though, your English was idiomatically “native” enough to not be readily distinguishable to me from that of a native speaker, and (like @pf_moore ) I’d seen plenty of users express frustration, annoyance and anger at volunteer developers not providing free support for specific corporate use-cases, so I simply assumed it represented that context and responded accordingly.
Yeah, I was about to say the same thing. “Its too bad that” (and to some extent, even “its a pity”/“its a shame”) lacks the same degree of implied negative feeling directed toward project maintainers as “its annoying that”, while still communicating the unfortunateness of the situation. The words may describe strong emotions, but in this context, it is where they are implied to be directed, and their connotations, that matter more for how others respond (especially in light of falling into patterns of similar usage, as you can see from the SO thread, where the users had less kind intentions).
Would it be maybe at least possible to change the installer to not block python installation on windows 7 but instead inform the user that python is not officialy supported on windows 7 and if you wish to use it your are responsible to make it work yourself (with yes/no button)
That would make it easier to install the latest version of it on windows 7 while making users aware that doing that is their own responsibility
Because if I want to install python on windows 7, I first have to install 3.8 (because the installer doesnt just copy files, it also sets PATH and some registry keys), then install 3.9 on windows 11, then copy that installation over to windows 7, add nalexandru/api-ms-win-core-path-HACK dll to it and then I can use it, all this because installer refuses to install on windows 7
This way you dont need to modify cpython to support specific os at all but instead you just change a small behaviour in the installer
Running Tools\msi\build.bat should do everything necessary for you (output goes to PCbuild\amd64\en-us). The source files are in Tools\msi and make up a Wix toolset Burn bundle. You’ll want to be changing Tools\msi\bundle\PythonBootstrapperApp.cpp (or a similar name to that), and probably adding new UI elements to the other bundle files.
Win7 still holds 22% marketshare, we should reconsider about removing Windows 7 supports, it’s a much less bloated OS than Windows 8 and 10, and it uses less memory and CPU.
Sorry for this long off-topic side remark but I was wondering the same thing for a long time (because in this “art” of communicating on internet, you’re right, negative words like annoying can trigger answers based on this).