Jun-16-2021, 12:50 AM
On my Debian Install I loaded v3.9 in /opt and all worked out fne. It doesnt mess with system Python. All is well.
Then comes Win.
I have Win7.1. I am *not* going to update this macjhine to Win10, and Win8.1 is garbage also.
The problem is that some propellorheads decided that because Win7 is no longer 'supported' by M$, is that it is somehow a 'risk'!
I regard it as a feature. This machine has *never* been updated, as I avoid M$ as much as possible. And has never had a problem because of that.
v3.9x depends on api-ms-win-core-path-l1-1-0.dll for apparently no good reason other than to prevent Win7 usage.
The source code seems to say that Win7 is OK for now, but wont compile without api-ms-win-core-path-l1-1-0.dll.
I tried converting the install exe to msi and used orca to blank out the requirements part, but no luck. It is hardcoded into the binary.
Someone did a hack of api-ms-win-core-path-l1-1-0.dll for Blender, but did not include the function Python wanted.
So the question is:
Is there a hack, or a FAQ for getting by this nonsensical booby-trap?
Then comes Win.
I have Win7.1. I am *not* going to update this macjhine to Win10, and Win8.1 is garbage also.
The problem is that some propellorheads decided that because Win7 is no longer 'supported' by M$, is that it is somehow a 'risk'!
I regard it as a feature. This machine has *never* been updated, as I avoid M$ as much as possible. And has never had a problem because of that.
v3.9x depends on api-ms-win-core-path-l1-1-0.dll for apparently no good reason other than to prevent Win7 usage.
The source code seems to say that Win7 is OK for now, but wont compile without api-ms-win-core-path-l1-1-0.dll.
I tried converting the install exe to msi and used orca to blank out the requirements part, but no luck. It is hardcoded into the binary.
Someone did a hack of api-ms-win-core-path-l1-1-0.dll for Blender, but did not include the function Python wanted.
So the question is:
Is there a hack, or a FAQ for getting by this nonsensical booby-trap?