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

Chris Lambacher chris at kateandchris.net
Wed Sep 7 05:24:15 CEST 2011


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


More information about the python-win32 mailing list