[spambayes-dev] Re: Open relay, and new release?

[Thomas Heller]

"Mark Hammond" <mhammond at keypoint.com.au> writes:

>> I'm not sure how closely you're monitoring the bug reports at the
>> moment, so in case you're not:
>
> I'm not :)
>
>> Someone that had this problem searched for all instances of the
>> pythoncom dll, found two, and replaced the system one with the
>> spambayes one, and the problem went away (although who knows what
>> other trouble that will cause!).  Another user, reading the comment,
>> did the same thing, and his problem went away, too.
>
> I have discovered the problem.  ActivePython is still registering the
> 'pythoncom' and 'pywintypes' module in the registry.  This is no
> longer necessary, for any version of Python.  Indeed, it is what is
> causing the problem - our binary still *does* look in the registry, as
> python23.dll itself does.

An idea: the ignore environment flag (I do not remember the exact name
now, but you know what I mean: the flag set by the -E command line
switch) should also prevent the python dll to look into the registry,
probably.

> The capability to register modules in the registry was a dumb one that I
> must take full credit for <wink>.

Robin Dunn was also creative: he registers the wxPython version number
in the registry where additional modules are expected - leading to bugs
in Gordon's installer ;-).

> The best thing I can see to do is for us to ship a slightly modified
> python23.dll.  All that needs modification is a string resource in the DLL -
> ie, no code.  This will change where Python looks for its configuration
> information in the registry.  By changing this value, we can ensure that we
> can't possibly conflict with any existing installations.
>
> At this stage, the only way I can change the resource is via MSVC.  With a
> little work, it will be possible to have py2exe write a custom value for
> this string into the DLL - it can already write resources, but strings need
> a little work.  Thomas - if you are listening, do you have any thoughts on
> this?

It is already possible and has for a while even in py2exe 0.4 or so.
At that time, built services required some string table entries.
This little script patches the stringtable in python23.dll:

"""
from py2exe.resources.StringTables import StringTable, RT_STRING from
py2exe.py2exe_util import add_resource

s = StringTable()
s.add_string(1000, "2.3.py2exe")

delete = True
for id, data in s.binary():
    add_resource(ur"c:\tests\python23.dll",
                 data, RT_STRING, id, delete)
    delete = False
"""

The only problem is that py2exe's add_resource function does always
use MAKELINGID(LANGNEUTRAL, SUBLANG_NEUTRAL) as LCID, and the standard
python dll has the string table in 'English US'.
So, the above script has to delete all existing resources first, and
this of course also removes the existing versioninfo resource. OTOH,
this is probably the right thing to do, because it's not the standard
dll anymore.

The other problem, of course, is that the script doesn't throw an error
when Windows fails to update the resource because the file is already
open, not writeable, or whatever.  But that's a windows problem, imo.

Thomas