I think you should build Python.exe with the option to be statically linked to the VC++-runtime. This way, the executable is a little bigger, but you ensure nobody will have troubles with some VC-runtime different Dll versions.

DETAILS : (I posted it also there http://stackoverflow.com/questions/32748932/python-3-4-3-works-on-windows-vista-but-not-3-5-0-because-of-vc-redist-package )

I am on Windows Vista 32bits. I downloaded Python 3.5.0 but I got the famous api-ms-win-crt-runtime-l1-1-0.dll problem. Then I installed many Visual C++ Redistributable Packages (I tried the 2015's one, then 2013, and 2012) but none of these packages installed any .dll of the correct name. Then, I tried to download a previous version of Python, the 3.3.2 win32 release, I got the same problem !

----> Then, I downloaded the Python 3.4.3 Win32 release, and this-one worked immediately. I suspect that version to have been statically linked with the VC-runtime. This clearly lacks of coherence, some Python releases work, while others don't. So I hope some of the Python developers will see that message and will be able to build some binaries compatible with Windows Vista and the VC-redist-packages.

Question : did anyone understand where that api-ms-win-crt-runtime-l1-1-0.dll comes from ? I suppose it is related to the VC++ compiler options used when building Python.exe (on my VS2010 I have the options code generation/runtime library/multi-threaded, static or dynamic and general/platform_toolset, V100, V110, V120 or V140) ?

With dependency walker I see that :
- in 3.4.3, Python34.exe and also Python.34.dll have been dynamically linked with msvcr100.dll (platform target : v100 in Visual C++ project properties), 
- while  in 3.5.0 (the one you download on python.org main page) Python35.exe and Python35.dll have been dynamically linked with msvcr140.dll and many other dlls (platform v140).

None of them are statically linked, and we looked into that for 3.5 and it had other issues, so we went fully dynamically linked.

This is either an issue specific to your machine, or a Vista issue (we didn't get a lot of testing done on Vista).

Installing the VC 2015 redistributable from http://www.microsoft.com/en-us/download/details.aspx?id=48145 should include the files you need (as should installing Python 3.5.0 itself, but apparently that didn't work). The DLL should be under C:\Windows\System32.

On Vista32bits, the VC++2015 redist package does install msvcr140.dll but none of the api-ms-win-crt-***-l1-1-0.dll, thus (that's why I opened this discussion at first) it is impossible to make many of the Python releases working, at least on Vista 32bits.
There are many compiler options about the msvcr***.dll (platform V100,V110,V120,V140.., statically or dynamically linked to the C runtime, multi-threaded or not...) and obviously the settings used to build Python 3.4.3 work fine on Vista (platform V100), while the settings used to build Python 3.5.0 don't (platform V140).

msvcr140.dll does not exist and was never released. I'm not sure what you've installed, but it seems to be the wrong thing.

I'm familiar with the compiler options and we are using the correct ones. If you want to change them, you should build your own copy.

To help me help you with your installation issue, could you attach a list of all the DLLs in your System32 folder?

Try directly installing the Universal CRT update, [Windows6.0-KB2999226-x86.msu][1]. Run it with the /log option, e.g.

    Windows6.0-KB2999226-x86.msu /log:kb2999226.evtx

You can view this log in the Windows event viewer, or convert it to text XML on the command line as follows:

    wevtutil qe kb2999226.evtx /lf:true /f:XML /e:MSULog > kb2999226.xml

If the update fails, please attach the XML log to this issue. 

Steve, since these updates require an up-to-date Windows installation, maybe you should test for SP2 on Vista, SP1 on Windows 7, and S14 on Windows 8.1. Display a warning if the OS is outdated, including Windows XP, but let the install proceed.

[1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234

As a note, I had problems installing Python 3.5 on a computer at work.
The redist package could not install with access denied error.

But the workaround installing the Universal CRT update helped.
After this I was able to install Python 3.5 without problems.

@steve.dower : the vc_redist packages doesn't list the files it installs, I'm not sure of the names of the files, but who cares, please look at my screenshot of dependency walker, it shows how different versions of Python win32 releases that I downloaded on python.org (3.5.0, 3.4.3,3.3.x) used different vc-runtime settings, and how some of them don't work on Vista.

@Wolfgang Langner : "this update doesn't apply to you system" :-)

So what I'm saying is : please be careful with the compiler options if you want you executables to be compatible with vista/7/8/10

In your original post you refer to the "famous api-ms-win-crt-runtime-l1-1-0.dll problem" - I am not aware of this problem, so you will need to provide more context on what is actually not working for you.

Dependency Walker doesn't know how to resolve those DLLs on any platform - Win10 looks exactly the same. A limitation of a diagnostic tool that hasn't been updated in years does not qualify as something "not working".

But since you've closed the issue I have to assume that it isn't really an issue.

> this update doesn't apply to you system

Was that Windows6.0-KB2999226-x86.msu? Open a command prompt and enter the following:

    wmic os get Version, OSArchitecture

Windows Vista SP 2 is version 6.0.6002, and the OS architecture should be 32-bit.

> Dependency Walker doesn't know how to resolve those DLLs on 
> any platform - Win10 looks exactly the same. 

On older systems the api-ms-win-crt-* DLLs should be physically installed in System32, so Dependency Walker should find them if they exist. For example, on a Windows 7 box:

    >dir /b C:\Windows\System32\api-ms-win-crt*.dll
    api-ms-win-crt-conio-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-multibyte-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-process-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll

In Windows 10 these DLLs are an API Set contract; they don't actually exist in the filesystem. For example, on Windows 10 GetModuleHandle for all of these DLLs returns a handle to ucrtbase.dll, whereas on Windows 7 each is a uniquely loaded module.