[python-win32] Loading C extensions in Python 2.6/2.7 from classic ASP

Fri Sep 9 05:24:01 CEST 2011

On 9/09/2011 12:58 PM, Chris Lambacher wrote:
> Hi Mark,
>
> It is not Wow64. I did a very basic test to see what I get. I
> installed 2.7.2 x64 and appropriate pywin32 216, and lxml 2.3, throw:
> <script language="python" runat="server">
> import sys
> Response.Write(sys.version)
> import lxml.etree
> Response.Write("<br>Worked")
> </script>
>
> into an ASP file and get:
>
> 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)]
> Python ActiveX Scripting Engine error '80020009'
>
> Traceback (most recent call last): File "<Script Block>", line 3, in
> <module>  import lxml.etree ImportError: DLL load failed: The specified
> module could not be found.

I guess you are saying that that module will have no reference to the 
CRT assembly and that you will rebuild it so it does and that will fix 
the problem?

If so, that surprises me.  To get as far as you did, much of the pywin32 
framework was imported, so all those modules must have imported OK.

Apologies if I'm mis-understanding (ie, if it is vice-versa - you need 
to rebuild to *remove* the manifest reference) - I'm very busy at the 
moment and about to head to the US for a week - I haven't even dug into 
the changes you made to distutils to see exactly what they are doing...

Mark

>
> /test/test.asp, line 4
>
> import lxml.etree
>
>
> Looks like I am continuing to rebuild things for the time being :(
>
> -Chris
>
> On Tue, Sep 6, 2011 at 11:24 PM, Chris Lambacher<chris at kateandchris.net>  wrote:
>> Hi Mark,
>>
>> I make changes to *other* extensions. I documented the change I made
>> to distuils here:
>> http://groups.google.com/group/isapi_wsgi-dev/msg/aa11ed3058e73660
>>
>> Basically I disable the step that filters the MSVCRT out of the
>> manifest. And then re-build the extension. I have not yet ventured
>> into building Pywin32. I ended up modifying distutils because of a
>> link to a Python bug when I searched for the error I got when loading
>> a C extension. | can't remember which bug and I would have to muck
>> with things to generate the error again, which I will do, just not
>> tonight :)
>>
>> I have not tried using x64 all the way though, mostly because when I
>> got started with this project I wanted to use Psyco (which was a
>> miserable failure that I have given up on), which only support x86.
>> I'll try to do a simple x64 test and see what I get. I am on win7 so I
>> can select x64 or x32 Application Pools in IIS and not disrupt my
>> other work.
>>
>> I have also determined that I have no reference to pythoncom26.dll,
>> only pythoncomloader26.dll, in my registry.
>>
>> -Chris
>>
>> On Tue, Sep 6, 2011 at 11:09 PM, Mark Hammond<mhammond at skippinet.com.au>  wrote:
>>> On 7/09/2011 12:56 PM, Chris Lambacher wrote:
>>>>
>>>> Hi Mark,
>>>>
>>>> It looks like it is trying to use pythoncomloader26.dll. Maybe it is
>>>> to due with the Wow64 stuff? I've pasted the Registry values below in
>>>> case you can get any insight into it. If you have any suggestions
>>>> about how to go about debugging it. I am happy to put a little effort
>>>> in here on my end, but this stuff is a little bit beyond my
>>>> experience.
>>>
>>> That looks right to me.  The Wow64 stuff could well be an issue - it appears
>>> you have the 32bit version of Python installed (and therefore its COM
>>> objects got registered in Wow6432Node) which means these objects will only
>>> work with a 32bit version of ASP - but I'm not sure how ASP gets packaged
>>> these days on a 64bit OS.
>>>
>>> However, as you mentioned your problem goes away simply rebuilding the
>>> pywin32 extensions with different flags, it doesn't sound like a simple
>>> 32bit/64bit problem - can you find the exact changes you had to make to the
>>> build process to get things working?
>>>
>>> Mark
>>>
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> Here are what I think are the registry values for the ActiveX Script
>>>> registration:
>>>>
>>>> Windows Registry Editor Version 5.00
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}]
>>>> @="Python ActiveX Scripting Engine"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Debugging]
>>>> @="0"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
>>>> Categories]
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
>>>> Categories\{B3EF80D0-68E2-11D0-A689-00C04FD658FF}]
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
>>>> Categories\{F0B7A1A1-9847-11CF-8F20-00805F2CD064}]
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
>>>> Categories\{F0B7A1A2-9847-11CF-8F20-00805F2CD064}]
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\InprocServer32]
>>>> "ThreadingModel"="both"
>>>> @="pythoncomloader26.dll"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\LocalServer32]
>>>> @="C:\\Python26\\pythonw.exe
>>>> \"C:\\Python26\\lib\\site-packages\\win32com\\server\\localserver.py\"
>>>> {DF630910-1C1D-11d0-AE36-8C0F5E000000}"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\ProgID]
>>>> @="Python.AXScript.2"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\PythonCOM]
>>>> @="win32com.axscript.client.pyscript.PyScript"
>>>>
>>>>
>>>> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\VersionIndependentProgID]
>>>> @="Python"
>>>>
>>>>
>>>>
>>>> On Tue, Sep 6, 2011 at 10:28 PM, Mark Hammond<skippy.hammond at gmail.com>
>>>>   wrote:
>>>>>
>>>>> On 7/09/2011 5:17 AM, Chris Lambacher wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Whenever I load an extension using the ActiveX Script for Python in a
>>>>>> Classic ASP page, I get an error saying the DLL can't be loaded. I
>>>>>> have solved this problem thus far by patching the distutils source for
>>>>>> my local Python instance and rebuilding the extension (see
>>>>>> http://groups.google.com/group/isapi_wsgi-dev/msg/aa11ed3058e73660).
>>>>>> Thus far I have suffered no ill effects for doing this, but suspect
>>>>>> that what actually needs to happen is that the DLL for the python com
>>>>>> server needs to have the MSVCRT part of the manifest instead.
>>>>>>
>>>>>> I had a quick look at the setup.py for pywin32 build 216 and found the
>>>>>> monkey patching of link that includes the _want_assemply_with_crt flag
>>>>>> for perfmondata.dll and PyISAPI_loader.dll. Should that list also
>>>>>> include the COM Server DLL? Is there a better way to solve this than
>>>>>> rebuilding all my compiled extensions to include the full manifest or
>>>>>> am I stuck with rebuilding all the time?
>>>>>
>>>>> "In theory" (gotta love that), COM objects should now be hosted by
>>>>> pythoncomloader.dll.  This DLL should be built with the CRT manifest
>>>>> included, and the DLL itself has some hacks which should mean the
>>>>> extension
>>>>> modules then loaded don't need the manifest reference - these hacks are
>>>>> the
>>>>> same as made by Python itself (ie, any module which imports correctly
>>>>> under
>>>>> normal Python should also import correctly in a COM object hosted by
>>>>> pythoncomloader.dll.  See _build_pycom_loader in the pywin32 setup.py.
>>>>>
>>>>> Is it possible the registration process for asp is still using
>>>>> pythoncomxx.dll as the COM entry-point instead of pythoncomloaderxx.dll?
>>>>>
>>>>> In other words, when you say:
>>>>>
>>>>>> what actually needs to happen is that the DLL for the python com
>>>>>> server needs to have the MSVCRT part of the manifest instead.
>>>>>
>>>>> I believe it already should.  Which isn't to say you aren't having a
>>>>> problem
>>>>> - it is just I don't quite understand it :)
>>>>>
>>>>> Mark.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Christopher Lambacher
>> chris at kateandchris.net
>>
>
>
>