6.4.2-1-Q16-windows-x64-static doesn't work at all

[johnsfine]

As a new user, I can't be certain this is a bug, not misuse. But what I have tried seems pretty conclusive.

I am running Windows XP Professional x64 Edition Version 2003 Service Pack 2.

I downloaded and ran three different version of the ImageMagick installer (installing to three different directories):

ImageMagick-6.4.2-1-Q16-windows-x64-static.exe
ImageMagick-6.4.2-1-Q16-windows-static.exe
ImageMagick-6.4.2-1-Q8-windows-static.exe

Both 32 bit versions seem to be working (identify -version gives reasonable output, imdisplay can display logo.gif).

None of the .exe files in the 64 bit version does anything. No operation, no output, no error message. Each just exits immediately.

I tried the dependency walker on those exe files. The only problem identified is that DWMAPI.DLL isn't found. But the dependency walker reports that for almost all .exe files, including the 32bit ImageMagick .exe files, and it doesn't seem to do any harm.

Is there anything else I should test to find out what is missing or broken? Is that build of ImageMagicK working for other users of XP?

I did a bit more investigation running identify -version in a debugger on a different computer: It does recursive calls until the stack overflows. I used editbin to greatly increase the stack allocation and that just makes it recurse deeper before the stack overflows. The recursion sequence is:

14004DEC2 calls 140058AF0
140058CBD calls 140031020
140031048 calls 140030EA0
140030F2C calls 14004EE20
14004EE9E calls 14004E880
14004E95D calls 14004E6C0
14004E6EE calls 14004DE40
repeating

Eventually the stack overflows in:

14004DEC2 calls 140058AF0
140058AF9 calls 1403F6D90

If whoever built that exe kept a .map or other symbol info, it should be possible to get the function names for the above sequence of addresses.

I did more debugging of disassembly without symbols, comparing the sequence of calls against the source code and have deduced that 140058AF0 (which is the beginning of the infinite recursion) is GetConfigurePaths

The next step down the recursion is
ThrowMagickException(exception,GetMagickModule(),ConfigureError,"RegistryKeyLookupFailed","`%s'",registry_key);
I expect there should be some check to prevent the infinite recursion, but obviously things have already gone wrong when the registry lookup for "ConfigurePath" fails.

I don't really understand the 32-bit vs. 64-bit kludge in the XP64 registry. The installer does seem to create the right registry entry, but only the 32-bit versions of the program can find it. I'm trying to figure that out.

[johnsfine]

I think I figured out the bug!

The registry setting created by all three installers are in

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ImageMagick\6.4.2

I assume Windows (not any code in the installer) inserts that "Wow6432Node" part. I assume it does so when it sees a 32 bit installer making certain kinds of registry changes. So I assume the win64 build of Magick uses a 32bit installer rather than a 64bit installer.

I have no clue if there is a work around. Can a 32 bit installer install a 64 bit program in XP64. The simple choice is to use a 64 bit installer.

I exported, edited, and imported those registry setting to drop the "Wow6432Node" and now the problem is fixed.

[johnsfine]

There seem to be multiple bugs involved in this situation:

The documentation says:

Code: Select all

Under Windows, ImageMagick searches for these configuration files in the following order, and loads them if found:

  $MAGICK_CONFIGURE_PATH
  <windows registry>
  $PREFIX/config
  <client path>
  <current directory>

I tried setting MAGIC_CONFIGURE_PATH (before I understood the registry issue) and that didn't help. I haven't had time to debug to find out why. The code looks like it would check that before the registry. Maybe I misunderstand what should be in that environment variable.

In all my testing, both the current directory and the directory from which the .exe was run were the directory containing the configuration files. So the quoted documentation implies the lack of registry entries should not have been a problem. But looking at the source code, I can't see any way it could get past the failure to find the registry entries.

So the (at least) three different bugs are:

1) The installer for windows x64 creates registry entries for 32bit, not 64 bit.

2) There is no fall back after GetConfigurePaths fails to get the registry entry.

3) ThrowMagickException should have a recursion check and fall back behavior. As it is now, it depends on too much of the rest of the package working to be useful as an Exception system.

4 maybe) Something wrong with the lookup of MAGICK_CONFIGURE_PATH (I'm not sure that one wasn't user error).

[johnsfine]

Just want to add on that the same package is absolutely not working on Windows 2008 Server Datacenter x64.

Have you ever used Regedit? Once you understand the malfunction that occurs during install of ImageMagick, it is very easy to use Regedit and wordpad to export, edit and import those registry settings, so the 64 bit version will then run correctly.

I'm disappointed this thread got no reply from any Imagemagick developer or expert. But until the bug is resolved, the above work around isn't too bad.

So why run the 64 bit version?

In theory, the 64 bit version should run faster.

But here is a post in which someone found the 32 bit version runs significantly faster:
http://www.linuxquestions.org/questions ... ost3207755

I installed ImageMagick because of that post. I wanted to redo the comparison myself. But I haven't yet gotten to the point where I can. I don't have a dual boot (32 bit / 64 bit) Linux installed, so I can't try it that way.

I half understand how to install a 32 bit .deb package in a 64 bit debian system such that it works and it doesn't conflict with a 64 bit version of the same program. But the only way I know doesn't use the package manager. Checking the dependencies, downloading each .deb file, and installing are each tedious manual steps, so I don't have a working 32 bit version yet.

Meanwhile, on Windows, I now have a 32bit Q8, 32bit Q16 and 64bit Q16 all working and I tested all three converting a 1.6 MB jpg to png. In theory, Q16 should be slower than Q8 and 32 bit should be slower than 64 bit. But all three ran too fast for really meaningful comparison and the two Q16 versions ran at the same speed as each other and slightly faster than the Q8. I need to copy a much bigger jpg to that system for a more meaningful test.

On Linux, I tried a jpg with 16 times the size (in pixels) as the one I tested in Windows. This Linux computer has a slightly faster CPU than the Windows one and it has 8GB of ram (which should be far more than enough). I tested only 64 bit Q16 and it took over fifty times as long as the Windows computer took for a file only sixteen times the size. So that hints that I'm seeing the same performance problem in the 64 bit Q16 Linux build reported in the above mentioned thread (and that Windows 64bit Q16 doesn't have that problem). But not proven yet. It could just be an nonlinearity in the cache behavior as the problem scales.

Edit: I did those performance tests (see the other thread I mentioned) and in Windows, the 64bit ImageMagick was faster than the 32bit ImageMagick, (the serious performance problem with 64 bit ImageMagick is just in Linux, not in Windows).

[magick]

The developers say... We're Linux developers and we address Windows problems but they tend to take a bit longer than problems presented to us on the Linux platform. We have two issues under Windows right now that we're getting to-- 64-Windows (which seems to work if you first install the 32-bit ImageMagick distribution and then the 64-bit) and OpenMP support. ImageMagick is an open-source development platform and anyone can contribute so feel free to resolve these problems and post your findings here. If there are no volunteers, we will fix these problems but currently there is no ETA.

[johnsfine]

The developers say... We're Linux developers and we address Windows problems but they tend to take a bit longer

Understood and expected. I appreciate the reply. I certainly wasn't expecting an immediate correction, just a reply.

64-Windows (which seems to work if you first install the 32-bit ImageMagick distribution and then the 64-bit)

I don't think that fits my experience. I installed 64-bit and it didn't work, then I installed 32-bit and it did work, THEN I installed 64-bit AGAIN and it still didn't work. Later, I investigated and found the problems described above, and fixed the registry entries and at that point 64-bit worked.

ImageMagick is an open-source development platform and anyone can contribute so feel free to resolve these problems and post your findings here.

I did investigate the bugs and post my findings above. But I don't know enough about ImageMagick to provide a full correction. I'd be happy to do further testing (of the current version and/or any proposed correction) or give a more detailed explanation of what I understand about the bugs.

I am fairly confident of my understanding of the registry bug. The key to that problem is that the executable run during install to create the registry setting was built 32-bit, even though the programs being installed are built 64-bit. Windows (at least XP64) seems to have a problem with that.

Various registry and filesystem paths are redirected by the OS when accessed by a 32-bit program under a 64-bit OS. So the installer creates registry entries that are then visible only to the 32-bit build of the programs.

I think I installed the right source tree for ImageMagick, and I can see most of the source code. But I can't figure out where the Windows build procedure is, nor where the source code is for whatever runs during install time to create those registry entries.

[magick]

Grab the ImageMagick Windows source distribution from ftp://ftp.imagemagick.org/pub/ImageMagick/windows and unpack. You'll find the Windows installer in this folder: ImageMagick-6.4.2\VisualMagick\installer\ and install\inc. We use the Inno Setup Compiler to generate the Windows binaries. The Windows configure program is in this folder: ImageMagick-6.4.2\VisualMagick\configure.

[johnsfine]

Grab the ImageMagick Windows source distribution

I did, but I don't have the right version of visual studio and I'm generally lost looking through that source distribution.

You'll find the Windows installer in this folder: ImageMagick-6.4.2\VisualMagick\installer\ and install\inc.

But nothing there means anything to me. Because ...

We use the Inno Setup Compiler to generate the Windows binaries.

I never heard of it before now. Google helped, but I don't think I have time anytime soon to learn a new complicated tool.

I did look at the web site for mentions of 64bit and found (in new features as of 2007-02-17)

Code: Select all

Added two new [Run]/[UninstallRun] section flags: 32bit and 64bit. Similar to the [Files] section flags of the same name, these override the install mode and affect which System directory the {sys} constant maps to on 64-bit Windows.

That doesn't sound like it is exactly the right issue, but it might be. Elsewhere it says:

Code: Select all

See the 64-bit Installation Limitations topic in the help file for specifics.

which sounds more like it would address the Wow6432Node problem in the registry, but I can't really tell.

Obviously you don't have the option (as I suggested earlier) to just build the installer 64bit so Windows won't redirect your registry changes.

Personally, I've never been a big fan of the registry. For something like your programs, I wouldn't have used the registry at all. It is easy enough to get the directory from which the .exe was loaded. Assuming no override by an environment variable, I think you should get your xml from that directory, rather than need a registry entry.

Your documentation seemed to say that was there as a fallback. So that fallback failing is another bug (beyond the installer creating the registry entries wrong). If you left the installer wrong and just fixed the fallback (to find the xml files even when the registry key isn't found) that should cover the problem for almost all users. That coding change should be pretty simple.

The Windows configure program is in this folder: ImageMagick-6.4.2\VisualMagick\configure.

I tried that with my 1998 copy of visual studio. The configure program built, and it ran through its dialog, but it crashed on the finish step and I couldn't find any dsp or dsw files to build anything useful.

[magick]

Personally, I've never been a big fan of the registry.

The default ImageMagick build is the uninstalled version which does not use the Window registry. However, as you have seen, we only produce the installed version of the binary distribution which utilizes the Windows registry. We are unwilling to produce both versions (installed & uninstalled) because there is simply not enough time to support both given the demands on our time.

[magick]

Try ImageMagick-6.4.2-4-Q16-windows-x64-static.exe (available sometime tomorrow). We fixed a problem that should permit it to work properly under 64-bit Vista-- at least it works for us without complaint.

[johnsfine]

Try ImageMagick-6.4.2-4-Q16-windows-x64-static.exe (available sometime tomorrow). We fixed a problem that should permit it to work properly under 64-bit Vista-- at least it works for us without complaint.

You fixed the registry entries created by the installer for XP64 as well (not just Vista).

I deleted all the registry settings for all version of ImageMagick, then I ran that installer, then checked the registry. The registry entries were in the correct place (not in Wow6432Node as the 6.4.2-1 version had).

Then I tested and the programs work (I didn't test much, but at least they don't instantly fail as they would without the correct registry entries).