[Fwd: Boa Constructor 0.6.1. beta?]

Mike_Driscoll1 · April 16, 2008, 1:54pm

Erik Vandamme wrote:

I finally managed a run with -T
C:\Program Files\Boa Constructor>boa.exe -T
Running in trace mode.
Starting Boa Constructor v0.6.1
importing wxPython
Traceback (most recent call last):
  File "Boa.py", line 241, in <module>
  File "zipextimporter.pyc", line 78, in load_module
  File "wx\__init__.pyc", line 45, in <module>
  File "zipextimporter.pyc", line 78, in load_module
  File "wx\_core.pyc", line 4, in <module>
  File "zipextimporter.pyc", line 91, in load_module
ImportError: MemoryLoadLibrary failed loading wx\_core_.pyd

Make sure you have gdiplus.dll, msvcp71.dll and maybe MSVCR71.dll on your system. The last time I saw this, it was the gdiplus one that was the culprit. But I had another user that had this error and it seemed to stem from not having MSVCR71.dll instead. Very frustrating! I now distribute them with my exe using Inno Setup.

Mike

AK11 · April 16, 2008, 2:44pm

Mike Driscoll wrote:

Erik Vandamme wrote:

I finally managed a run with -T
C:\Program Files\Boa Constructor>boa.exe -T
Running in trace mode.
Starting Boa Constructor v0.6.1
importing wxPython
Traceback (most recent call last):
  File "Boa.py", line 241, in <module>
  File "zipextimporter.pyc", line 78, in load_module
  File "wx\__init__.pyc", line 45, in <module>
  File "zipextimporter.pyc", line 78, in load_module
  File "wx\_core.pyc", line 4, in <module>
  File "zipextimporter.pyc", line 91, in load_module
ImportError: MemoryLoadLibrary failed loading wx\_core_.pyd

Make sure you have gdiplus.dll, msvcp71.dll and maybe MSVCR71.dll on your system. The last time I saw this, it was the gdiplus one that was the culprit. But I had another user that had this error and it seemed to stem from not having MSVCR71.dll instead. Very frustrating! I now distribute them with my exe using Inno Setup.

Mike
_______________________________________________

I've read some vague advice of not supplying gdiplus.dll unless it's a win2k
system, but it might have meant that you shouldn't replace the original
gdiplus, but it's ok to have the program use the old one? Not sure, so
I make a link for users to download gdiplus from microsoft if they have
win2ks. When would msvcr71.dll be needed? I thought it's supplied with
all windows releases?

···

--
ak
Tobu | http://tobu.lightbird.net/ | Freeform DB / Tagger / PIM
Python-by-Example | http://pbe.lightbird.net/ | Guide to LibRef

Paul_McNett · April 16, 2008, 7:49pm

Marc Tompkins wrote:

The specifics are: Windows is still mired in DLL hell.

Oh, come on. "DLL hell" is just another way of saying "dependencies."

Not really. DLL Hell as I understand it refers to at least two deficiencies in the design of Windows:

1) Inability to update a library when that library is in use (the 'why do I have to reboot my computer after updating Internet Explorer' problem).

2) Inability for different versions of the same library to coexist in the same directory. So if program A relies on version 1.5 but program B needs 1.4, there isn't a good way for program A's needs to not screw up program B, and vice-versa.

I'm not a fan of M$ by any means, but the fact that certain programs depend on certain other files didn't start with them and won't end with them. When a Python program on Ubuntu fails because a module is missing, do we call it Canonical Crap? Not with a straight face, we don't.

In this case, I think I used the DLL Hell label a bit inappropriately, as an application removing a system DLL isn't behaving properly, which isn't really the fault of Windows.

Good practice has always been to only add or remove DLLs from/to your own directory; Windows never enforced that until fairly recently, and it's always been easier to throw your files into \Windows or \Windows\System32 (and yet to regard them as your own property.) If Microsoft is responsible for "DLL hell", it's generally been through failing to enforce best practices on developers - although they have certainly had some screw-ups themselves.

The whole point of having a dynamic link library is so that multiple programs or multiple instances of the same program can share it. Putting a DLL that is specific to your application is appropriately installed in the app's program directory, certainly. But msvcr71.dll? Sorry, that belongs in the Windows system directory.

You brought up the package management system in Debian/Ubuntu, so let's compare:

In Ubuntu, when you go to install a program that has dependencies, those dependencies are installed. If you manually remove those dependencies in the future, the package management system helps you reinstate them. If you remove the program that originally installed the dependencies, and they aren't used by any other installed program, the package manager offers to remove them, but keeps them installed by default.

In Windows, it is every app for itself. Windows knows something about which installed programs depend on certain libraries, but it is up to the app to write the correct registry entries, and the app can still decide to remove a file for whatever reason, if it has the permissions.

In Ubuntu, package management it almost completely centralized and controlled by one chokepoint. In Windows, it is a wild frontier. And to top it off, Microsoft keeps changing the so called 'best practices'. I think DLL Hell is an adequate description, actually.

Paul

···

On Wed, Apr 16, 2008 at 11:24 AM, Paul McNett <p@ulmcnett.com > <mailto:p@ulmcnett.com>> wrote:

Erik_Vandamme · April 16, 2008, 11:16pm

Thanks AK and Mike,

That fixed it. I had msvcr71.dll in bo folder but mscvp71.dll only in
site packages, copied one to Boa folder and then downloaded gdiplus and
copied dll to Boa folder, works a treat!

AK wrote:

···

**
Erik Vandamme
54 Hilltop Road - WAMBERAL NSW 2260 Australia
Skype - erik_vandamme
02 43843613 - 0406 042750**

erik1vandamme@gmail.com

Mike
Driscoll wrote:
Erik Vandamme wrote:
  I finally managed a run with -T
C:\Program Files\Boa Constructor>boa.exe -T

Running in trace mode.

Starting Boa Constructor v0.6.1

importing wxPython

Traceback (most recent call last):

File “Boa.py”, line 241, in

File “zipextimporter.pyc”, line 78, in load_module

File “wx_init_.pyc”, line 45, in

File “zipextimporter.pyc”, line 78, in load_module

File “wx_core.pyc”, line 4, in

File “zipextimporter.pyc”, line 91, in load_module

ImportError: MemoryLoadLibrary failed loading wx_core_.pyd
Make sure you have gdiplus.dll, msvcp71.dll and maybe MSVCR71.dll on
your system. The last time I saw this, it was the gdiplus one that was
the culprit. But I had another user that had this error and it seemed
to stem from not having MSVCR71.dll instead. Very frustrating! I now
distribute them with my exe using Inno Setup.

Mike
I’ve read some vague advice of not supplying gdiplus.dll unless it’s a
win2k

system, but it might have meant that you shouldn’t replace the original

gdiplus, but it’s ok to have the program use the old one? Not sure, so

I make a link for users to download gdiplus from microsoft if they have

win2ks. When would msvcr71.dll be needed? I thought it’s supplied with

all windows releases?