>And let me know if that helped or not.
The version 6.9.8-Q8 ImageMagick program does allow icomancer to start on XP, but after creating an account, and downloading the two icon libraries, icomancer wants to restart, but when it does, it has an error:

System.Runtime.InteropServices.COMException (0x80041771): convert: 425: Wrong JPEF library version: library is 80, caller expects 62 'C:]Program Files\icomancer\Mona Lisa.jpg' @error/jpeg.c/JPEGErrorHandler /322:
convert: 410: no such image 'transparent' @error/modgrify.c/MogrifyImageList/8770:
convert: 410: no images defined 'C:\DOCUMENT~1\RSS\LOCALS~1\Temp\~lswim.8533900.im.0.2626918.png' @ error/convert.c/ConvertImages/3258:

at ImageMagickObject.IMagickImage.Convert(Object[]& pArrayVar)
at Icomancer.clsIconImageComposer.CreateTempFile(TempFileCoordSystem CoordSystem, XElement& xStyleNode, String source ImageFileToEmbed, Size targetDimensions, Boolean ignoreAspectRatioPreservation) in H:\Icomancer\Icomancer\clsIconImageComposer.vb:line 513

I did the same: download, install, register account and after restarting icomancer, download the oxygen and ten folder templates... then restarted icomancer again and it worked fine.

Checking the exception you pasted: I can see that it says "Wrong JPEF library version: library is 80, caller expects 62".

I wonder if the other ImageMagick version was properly removed, because seems like a collission between files in the environment's path.

Could you please open a command line window, then type the path command and press enter, then send me the output? it should look something like this:

As you can see, my ImageMagick version is located at

C:\Archivos de programa\ImageMagick-6.9.8-Q8

I guess on your machine it should be at

C:\Program Files\ImageMagick-6.9.8-Q8

If there's more than one ImageMagick entry in the path, then that's where the conflict is

>Checking the exception you pasted: I can see that it says "Wrong JPEF library version: library is 80, caller expects 62".
[quote]I wonder if the other ImageMagick version was properly removed, because seems like a collission between files in the environment's path.[/quote]

The PATH is not the issue because I had already changed it, and I was confident that all of the old version of ImageMagick had been removed; only the new version of ImageMagick was in the PATH.

I used a tracking Install and Uninstall program to ensure all traces of the old version of ImageMagick were removed. Uninstall programs commonly seem to fail cleaning up the PATH when their program is un-installed. Likewise, the Uninstall monitors also fail to monitor the PATH after an uninstall. Before installing the 6.9.8-3 version, I checked the environment variable for the PATH. The old version of ImageMagick was still in the PATH, so I knew that I should and would remove it, but I decided to leave it there until I installed the new version of ImageMagick.

Next, I installed ImageMagick version 6.9.8-3, and again checked the PATH. The new version had been added to the PATH at the very start as expected, and the old version was second in the PATH. I removed the second directory since the program files were no longer on the disk at that location, but even if I had left it in, the directory no longer exists. Any program accessing the PATH environment variable to find ImageMagick would use the first one in the path, and the program should verify that the program actually exists where the PATH says it does.

Even if the old ImageMagick version directory were still in the PATH, it would be second in the list, and since the old version of ImageMagick is not on the disk, no program can access any of that version's features (or have a conflict if the program is no longer there). Therefore, the problem has to be the program that utilizes the ImageMagick library features is not aware of the ImageMagick change. Icomancer is expecting the old version because at this point, it is not aware of the new PATH data and new version of ImageMagick.

It is not uncommon to have the PATH environment variable contain directories that no longer exist, but since they do not exist, any program that blindly uses invalid PATH data can't blame it on the PATH. The big issue with the PATH is that the length of the PATH is not unlimited. Back in the days of DOS and short file names, the PATH did not generally get very large. Today, too many programs add long directory strings to the start of the PATH, making older entries fall off at the end, and they do it without warning or informing the user; that is a bad practice. I have to monitor my PATH constantly to ensure new installs do not mess things up for me.

These days, programs should not depend on the PATH data to interact, start, or utilize other programs. The data in the PATH they expect could be the one that has fallen off the end after other programs have been installed. When that happens, how will icomancer handle that?

Anyway, the icomancer program was now able to start after installing ImageMagick 6.9.8-3. I was able to create an account, and I was able to download the oxygen and ten folder templates. To incorporate those libraries, icomancer needs to restart itself, and then starts working on processing the libraries using ImageMagick. There is when the library conflict showed up. When I noticed the library conflict statement (80 vs. 62), I knew that icomancer was not aware of the ImageMagick change for some reason. That problem existed even though the PATH had the correct data. Apparently, icomancer does not re-acquire the PATH data when it restarts itself.

Even though I had changed the PATH environment variable correctly, it does not mean that all programs will be aware of that change, icomancer being one of them. The way icomancer works now, for icomancer to re-acquire the new PATH data, the computer needs to be restarted. Normally, that is part of the initial install process. If you start an XP Virtual Machine, then essentially, you are closer to doing a re-boot of the OS than I was. I expect that is why yours worked. After rebooting my computer, icomancer also works.

>If there's more than one ImageMagick entry in the path, then that's where the conflict is
It is not whether there are multiple ImageMagick directories in the PATH, it is whether icomancer knows and uses the first one in the list. To further back that up, I re-edited my PATH variable, and put it back like it was when having both directories of ImageMagick. After a reboot, I started icomancer. If your statement is true that when both entries are in the PATH, it will be where the conflict is, icomancer should have the same problem, but it does not because icomancer used the first one in the path. It does not matter that an incorrect directory is also in the PATH. What matters is whether icomancer re-acquires the PATH data when it restarts itself. Try adding the other ImageMagick directory back into your PATH, and you will see that icomancer will still work.

Granted, it is a rare case and few will encounter this same problem, but if you make icomancer re-acquire the PATH data when it restarts itself, this problem will not happen for other users that need to change ImageMagick.

Now that I finally got icomancer started, my greatest disappointment is that it can only change one folder at a time. I have several folder icon changers that already do that on XP and on the Windows 7 and 10 OSes. I wanted a program that can change all of the subfolders to the same icon on the XP OS. Several competing folder icon changer programs do this already. I even have one that runs under the XP OS, but the problem with it is that it does not complete the job. Somewhere along the way, it stops, leaving a lot of subfolders not changed. It is a real hassle to have to go through every subfolder to see what remains to be done. I was hoping for a better solution.

There are quite a few Open Source folder icon programs that can change one folder. I hope you will consider adding subfolder changes to iconmancer. Without it, there is too many alternative programs that do the same.

My PATH:

but it also works with both directories in the PATH:

I didn't set any ImageMagick version checking at all.

I double checked the reference to the library in the IDE and it was properly updated after updating my local version. That's the IM COM object's prerrogative...

I tested on the dev environment without issues, and in my test VMs didn't find any trouble.

There's another thing to have in mind: a prefetch solution for XP. I have a PC with XP at home for running old hardware and I use eBoostr on it. eBoostr is like ReadyBoost on Vista and Seven, and it caches most frequently used files on a USB memory stick for fast access. I noticed that after updating something, this software updates the cache and serves the newest files from the disk instead of the older files from the buffer until the buffer is rebuilt. So if you have something like this and is not as clever as eBoostr, then there you could have the version mismatch of IM DLLs.

Your case is really really weird. I have no idea of what is the specific thing that is making IM fail with icomancer for you, but I'm kinda sure that it is something in that specific PC you're using. Still, I'm compelled to find a solution.

Now... it seems that IM has a portable version. I'm thinking on migrating icomancer and stop using the COM object and make the calls over the command line on the portable version. That, if it works, will help icomancer get rid of the COM object dependency. But I wont be able to try that until after the 15th of the next month.

Now, changing one folder at a time: use the imbuer.

You use the crafter to make an icon you haven't already made, and then assign it to a folder. Once you have an icon already made, you can use the imuber to set the icon to several folders at once:

And you can add folders from different locations, not only subfolders.

I didn't add a feature like that (propagation to subfolders) because nobody asked for it before. Let me get out of my current tasks and I'll add it to the crafter before the end of April, luckily, with the change to IM portable.