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.
/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 <ch...@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 <mhamm...@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.hamm...@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
> ch...@kateandchris.net
>
--
Christopher Lambacher
ch...@kateandchris.net
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
