Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#64 dll conflicts via windows registry

closed-invalid
nobody
None
5
2004-11-24
2004-11-23
Anonymous
No

Py2exe places the zip file it generates as only item in
sys.path. This works correctly for normal modules.

However, python's "import" statement looks in the
windows registry in HKLM\Software\Python\PythonCore
_before_ using sys.path.

If the py2exe'd applications loads pythoncom23.dll or
pywintypes23.dll, the versions that are configured in the
registry (e.g., HKLM\Software\Python\PythonCore\2.3
\Modules\pythoncom\(Default)) are loaded instead of
the versions shipped with the executables.

If a user has an incompatible version of those DLLs on
his system (e.g., an older installation), the py2exe’d
applications will exit with an error. For example, a popup
dialog complains: “The procedure entry point bladibla
could not be located in the dynamic link library
pythoncom23.dll)” and the application exits with a
traceback and the message “ImportError: DLL load
failed: The specified procedure could not be found.”.

There is no way to disable the registry lookup that I
know of, except by temporarily overriding
sys.meta_path. This registry lookup occurs, in python
2.3.4, in Python/import.c, function find_modules():

#ifdef MS_COREDLL
fp = PyWin_FindRegisteredModule
(name, &fdp, buf, buflen);
if (fp != NULL) {
*p_fp = fp;
return fdp;
}
#endif

There are several solutions that I can see:
- Python should not do a registry lookup for frozen code
(would require modification of Python's C code)
- py2exe could use sys.meta_path to circumvent this
problem (I am currently using this method as a
workaround)

Discussion

  • Thomas Heller
    Thomas Heller
    2004-11-23

    Logged In: YES
    user_id=11105

    It *should* work.
    The PyWin_FindRegisteredModule() function builds the
    registry key containing PyWin_DLLVersionString, which is
    initialized in DllMain, in file PC\dl_nt.c.

    It is initialized from a string resource (which is also
    exposed to the Python interpreter as sys.winver) in
    python23.dll.

    py2exe patches the private copy of python23.dll as part of
    the build process to something different (no longer '2.3',
    instead something like 'py2exe samples'), so the registry
    lookup should no longer return success.

    If you still have some 2.3 registry entries on the path, it
    must mean that the wrong python23.dll is loaded, imo. Does
    this make sense?

     
  • Logged In: NO

    Theller, thank you very much for your remark about
    sys.winver.

    First of all, we appeared to be using py2exe 0.5.0. This
    version of py2exe creates executables with sys.winver = 2.3,
    leading to the incorrect DLLs being loaded.

    After upgrading to py2exe 0.5.4, the executables all get
    sys.winver based on the 'name' parameter of the setup() call
    in our build script:

    setup(name="tools", ...)

    so in the example sys.winver becomes 'tools'. Unless we use

    setup(name="2.3", ...)

    the correct DLLs are loaded.

     
  • Thomas Heller
    Thomas Heller
    2004-11-24

    Logged In: YES
    user_id=11105

    Sounds as if this can be closed, then.

     
  • Thomas Heller
    Thomas Heller
    2004-11-24

    • status: open --> closed-invalid