msvcr71.dll revisited

[Don Dwiggins]

Here's a somewhat different problem with this DLL, using it on a program
that updates a database:

On a machine that doesn't have the DLL already, the program appears to
run OK (no crash, no error messages), but nothing is done to the
database; if I put a copy of the DLL into the folder with the
exectuable, it updates the DB properly.

Also, on a machine that has the DLL in \Windows\system32, if I rename
the DLL, the program again fails to change the database.

I've verified, using Process Explorer, that the DLL is in fact extracted
during execution into the temp folder, but apparently it's not being
referenced. I'm guessing that the temp folder needs to be added to the
"path" environment of the process, since IIRC that's how DLLs are
located by executables. Is there any way to make that happen? I'll be
happy to make the changes and test it out if someone can guide me.

--
Don Dwiggins
Advanced Publishing Technology

[Giovanni Bajo]

On 13/03/2007 21.57, Don Dwiggins wrote:

> Here's a somewhat different problem with this DLL, using it on a program
> that updates a database:
>
> On a machine that doesn't have the DLL already, the program appears to
> run OK (no crash, no error messages), but nothing is done to the
> database; if I put a copy of the DLL into the folder with the
> exectuable, it updates the DB properly.
>
> Also, on a machine that has the DLL in \Windows\system32, if I rename
> the DLL, the program again fails to change the database.

Which operating system are you using? If it's Windows XP, which service pack?

Windows XP SP2 and above use a different DLL search path from all the previous
Windows versions. I was wondering if this was related somehow...

> I've verified, using Process Explorer, that the DLL is in fact extracted
> during execution into the temp folder, but apparently it's not being
> referenced. I'm guessing that the temp folder needs to be added to the
> "path" environment of the process, since IIRC that's how DLLs are
> located by executables. Is there any way to make that happen? I'll be
> happy to make the changes and test it out if someone can guide me.

Uhm. This is in fact pretty weird. The point is that if MSVCR71.DLL wasn't
found by Windows in the DLL search path, the program would not even start:
PYTHON24.DLL requires it, and so all the .PYDs do.

What database library are you using? Is a library shipped with a .PYD? Can you
verify with a dependency viewer ('bindepend.py' part of PyInstaller, or
http://www.dependencywalker.com/ if you like GUI) that the .PYD of the
database library does *explicitally* reference MSVCR71.DLL?
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

[Don Dwiggins]

Giovanni Bajo wrote:
> Which operating system are you using? If it's Windows XP, which service pack?

This has occurred on at least two Win XP machines, one at SP1 and the
other at SP2.

> Uhm. This is in fact pretty weird. The point is that if MSVCR71.DLL wasn't
> found by Windows in the DLL search path, the program would not even start:
> PYTHON24.DLL requires it, and so all the .PYDs do.

I've finally figured out what's going on -- you'll be relieved to know
it's not PyInstaller's fault. For reference, in case someone else
stumbles onto this, here's the essence of it:

In addition to pyodbc, I'm using osql.exe (a SQL Server utility) to run
SQL batch files on the database, starting it up using os.popen3 so I can
catch the error output. The problem is, apparently, that the PyI-built
app's environment isn't inherited by the subprocess (and yes, osql needs
msvcr71.dll); compounding the problem was that osql dies silently when
it can't find the dll.

I tried switching to subprocess.Popen, which has an env= argument, but
that didn't work either, due to a subtle problem in the way it calls
Windows CreateProcess. (See
http://mail.python.org/pipermail/python-dev/2004-October/049656.html for
the gory details.)

So, unless someone has any bright ideas, I'm going to have to work
around this one way or another. I'll probably go back to the
py2exe-style approach of just ensuring that msvcr71.dll is in the
directory with the executable whenever I use an exe, that needs that
dll, in a subprocess.

Thanks for the assistance anyway,