I won't pretend to know where the *best* place to put the include is, but python.c was suggested to me some time ago. Just so you know, we tried putting the include in some C code that is part of M2Crypto and it did not work because, as we discovered, the applink table needs to be part of main().
Extending that thought... If somebody wanted to somehow embed python is part of the same process in their program as with perhaps IIS, I submit it would not be part of main() and therefore benign. Now, I would like very much to be in a position to experiment with all the combinations and prepare a patch that worked, but I do not have the requisite Microsoft toolset. I primarily work with gcc under OSX, Linux, cygwin/mingw. This last raises a curiosity question. Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio? Would not requiring the same VS version cause a problem in the field if someone were to receive an extension but had their Python built using a different version of VS? It seems building everything with gcc would get around the problem of having to match VS versions. ...or are we dependent on some specific Microsoft library? I dunno, I gotta ask. Larry -----Original Message----- From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 PM To: Christian Heimes Cc: Bill Janssen; Bugbee, Larry; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
