[Python-Dev] Python 2.6 and 3.0 ...and applink.c?

["Martin v. Löwis"]

> Do you have an opinion on the initial proposal of applink.c? The
> proposal does neither seem harmful nor problematic but I also don't see
> how it is going to help the op.

The specific change isn't going to help. What could help is the 
inclusion of applink.c into dl_nt.c.

This is not about somehow exposing SSL routines to other libraries, but
about exposing CRT stuff to openssl, specifically stdin/stdout/stderr,
fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open,
_read, _write, _lseek, _close.

Actually, re-reading OpenSSL, adding it to python.exe (and probably
pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the
handle to the executable), then GetProcAddress for OPENSSL_Applink.

So I think it's harmless and could help, except for the maintenance
burden of having to update our local copy of applink.c every time
OpenSSL adds a new slot to their applink table (which they should
rarely do).

Of course, the entire approach breaks in cases where Python gets
embedded: if, e.g., IIS loads the Python interpreter as a COM
scripting host, it would be the IIS executable which would have
to include applink.c :-) As IIS doesn't, extension modules that
link with their own OpenSSL will continue to produce a warning
about the missing applink when they run in the context of a COM
server (or some other Python embedding).

Regards,
Martin