-- 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 <myst...@gmail.com> 
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 <lorenro...@yahoo.com> 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     : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim- wiki
More help   : https://help.launchpad.net/ ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~zim-wiki
Post to     : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Reply via email to