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

[Bugbee, Larry]

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:martin at v.loewis.de] 
  Sent: Tuesday, February 26, 2008 1:10 PM
  To: Christian Heimes
  Cc: Bill Janssen; Bugbee, Larry; python-dev at 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