[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
From:       "Bugbee, Larry" <larry.bugbee () boeing ! com>
Date:       2008-02-26 22:06:20
Message-ID: 9418DB6C0B9D434190E54A78E931C3D1036F8BED () XCH-NW-7V1 ! nw ! nos ! boeing ! com
[Download RAW message or body]

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@v.loewis.de] 
  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/python-dev%40progressive-comp.com



[prev in list] [next in list] [prev in thread] [next in thread]