Re: [Zim-wiki] Zim building problems

[mystyc]

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  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
>
>
(Drive) \Device\HarddiskVolume12
(Drive) \Device\HarddiskVolume2
(Drive) \Device\HarddiskVolume3
(Drive) \Device\HarddiskVolume4
(Drive) \Device\HarddiskVolume5
(Drive) \Device\HarddiskVolume6
(Drive) \Device\HarddiskVolume7
(Drive) \Device\HarddiskVolume8
Clsid   ---
File/Key---
Image   ---
Image   *:\ide+\python\python27x32\python.exe
Image   *:\program files (x86)\nsis\bin\makensis.exe
Image   *:\program files (x86)\nsis\makensis.exe
Image   c:\windows\system32\apphelp.dll
Image   c:\windows\system32\cryptsp.dll
Image   c:\windows\system32\dnsapi.dll
Image   c:\windows\system32\dwmapi.dll
Image   c:\windows\system32\imm32.dll
Image   c:\windows\system32\iphlpapi.dll
Image   c:\windows\system32\msimg32.dll
Image   c:\windows\system32\msvcp60.dll
Image   c:\windows\system32\propsys.dll
Image   c:\windows\system32\python27.dll
Image   c:\windows\system32\rsaenh.dll
Image   c:\windows\system32\uxtheme.dll
Image   c:\windows\system32\version.dll
Image   c:\windows\system32\winmm.dll
Image   c:\windows\system32\winnsi.dll
Image   c:\windows\system32\winspool.drv
Image   c:\windows\syswow64\advapi32.dll
Image   c:\windows\syswow64\cfgmgr32.dll
Image   c:\windows\syswow64\comdlg32.dll
Image   c:\windows\syswow64\crypt32.dll
Image   c:\windows\syswow64\cryptbase.dll
Image   c:\windows\syswow64\devobj.dll
Image   c:\windows\syswow64\gdi32.dll
Image   c:\windows\syswow64\imagehlp.dll
Image   c:\windows\syswow64\kernel32.dll
Image   c:\windows\syswow64\kernelbase.dll
Image   c:\windows\syswow64\lpk.dll
Image   c:\windows\syswow64\msasn1.dll
Image   c:\windows\syswow64\msctf.dll
Image   c:\windows\syswow64\msvcrt.dll
Image   c:\windows\syswow64\nsi.dll
Image   c:\windows\syswow64\ntdll.dll
Image   c:\windows\syswow64\ole32.dll
Image   c:\windows\syswow64\oleaut32.dll
Image   c:\windows\syswow64\psapi.dll
Image   c:\windows\syswow64\rpcrt4.dll
Image   

Re: [Zim-wiki] Zim building problems

[Loren Rosen]

(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