-- Regarding python27.dll, a comment on stackoverflow
(https://stackoverflow.com/questions/25053761/location-of-python27-dll-from-python-itself)
says On 64-bit Windows the 32-bit python27.dll is really in
C:\Windows\sysWOW64. But if you try opening the
C:\Windows\system32\python27.dll in a 32-bit process, it'll open just fine. If
I'm not mistaken, WOW stands for Woodoo Of Windows. ;-)
-- Maybe a free tool like Dependency Walker (http://www.dependencywalker.com/)
would be useful. Might need to use the application profiling feature. There's
also a potentially useful FAQ.
-- I think you said a slightly earlier version of zim runs ok. Can you get a
list of DLLs a program used, sorted by time of first access? If so, perhaps
would be useful to compare the lists from the old and new versions of zim. The
first significant difference might well be the DLL the new version isn't
finding.
On Thursday, August 31, 2017, 3:42:12 PM PDT, mystyc <[email protected]>
wrote:
In looking for the alleged offending dll file, I rebuilt and subsequently ran
the rebuilt zim from within a sandbox program (sandboxie) while monitoring the
resources accessed during that time. Attached, you will find these 2 log
files, one with only the output resulting from python windows\build_ win32.py,
and the other from Zim Desktop Wiki Portable.exe.
Actually, the build command uses "pyx2" (in place of "python"), a unique
environmental variable that I use to invoke my 32-bit python-27 interpreter. I
also have the 64-bit version of python-27, as well as both 32 and 64-bit
versions of python-3, but each exists in its own directory accessing the
appropriate python libraries and packages therein. The directory for the
32-bit 2.7 interpreter is "python27x32\", and the attached build-time log seems
to confirm that the script accesses the dll files corresponding to the correct
python version, but I cannot say the same for the windows system dll files. At
one point, the build-time log records the script accessing the file (or image
of) "c:\windows\system32\python27.dll," which I cannot seem to find.
As for the runtime log, most of the dll files are within the zim directory
tree, except for a bunch of windows system dll files.
Is anyone else able to build this version of Zim on windows 7?
~Kevin
On Thu, Aug 31, 2017 at 1:57 PM, Loren Rosen <[email protected]> wrote:
(This may appear as a top-level message rather than as a response, due to email
client and launchpad problems.)
Don't know much about DLLs specifically, so let me ask a potentially dumb
question. When does it try to load a DLL? Could it be that the difference seen
is because one program tries to load libraries and the other doesn't get that
far? I ask because, at least with the old C and Unix dynamic libraries, it
would be quite easy to compile your program with no errors and yet have it fail
to actually run.
Other things:Is there an easy way to tell where it's looking for libraries,
and/or where it found them?In particular, could there be a 32- vs 64-bit
problem?An example in wikipedia (in https://en.wikipedia.org/wiki/
Dynamic-link_library#Python) suggests you can directly try to load a DLL:
import ctypes
my_dll = ctypes.cdll.LoadLibrary(" Example.dll")
Looking at the Python docs, seems like ctypes.util.find_library( name) will
return the path for the library. Also, perhaps ctypes.OleDL and ctypes.WinDLL
will be useful. Maybe they have better error handling. (I think you'd use these
instead of ctypes.cdll.)
______________________________ _________________
Mailing list: https://launchpad.net/~zim- wiki
Post to : [email protected]
Unsubscribe : https://launchpad.net/~zim- wiki
More help : https://help.launchpad.net/ ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~zim-wiki
Post to : [email protected]
Unsubscribe : https://launchpad.net/~zim-wiki
More help : https://help.launchpad.net/ListHelp
