Guido van Rossum wrote:
Will the resulting installer still install a working version of Python on old versions of Windows, like win95 and win98?
I don't know; in principle, it should (or atleast, we should be able to make it work if desired).
I presume this will require that the MSI support is present on the target system; does this exist for Win95 etc? How about Windows NT 4.0?
Yes; there is a four-file bootstrap mechanism that we could distribute. It consists of 1. a tiny setup.exe 2. an installer for installer for W9x 3. an installer for installer for WNT 4. the actual MSI file. I believe the setup.exe driver needs to be parametrized as part of the build process to hard-code the name of the MSI file; I have no procedure yet to do this. I would propose to make parts 1..3 optional downloads; we can also (alternatively) point users to the redistributable download at http://www.microsoft.com/msdownload/platformsdk/instmsi.htm With that procedure, they would explicitly need to install installer, then reboot (I think), then install Python. On some installations, installer might be present already, but in a too-old version (I use the schema of Installer 2.0). In principle, the already-present installer should find out that it is too old, and suggest some sort of upgrade.
If not, what's the oldest Windows version still supported?
A different question is the version of shared libraries that the Python binaries depend on. On the one hand, this is msvcr71.dll, which is not present by default on any Windows release, so we need to ship that. Another issue is Winsock 2 (which, I believe, is in wsock32.dll). A quick research indicates that this was present in Win95 already. I don't know whether all of the entry points that we use was present already; confirmation appreciated. In principle, usage of IPv6 could be a problem. In another principle, the platform SDK arranges to transparently emulate the IPv6 API on systems where it is not natively available, by means of GetProcAddress. This all needs testing. Regards, Martin