When starting the new GimpPortable2.2.12en_us I get the following popup window message:
Title: gimp-2.2.exe - Application Error
WindowMsg: The application failed to initialize properly (0xc0000142). Click on OK to terminate the application.
After clicking the OK button this message goes away and PortableGimp fails to start.
I think, based on other items in this forum, that this is most likely caused by a gtk conflict on my machine as Acer Arcade is known to use xmlparse.dll and xmltok.dll. These files were not located in the windows or system directory, nor were they stored anywhere within the path of this computer:
Windows XP SP2
I went ahead and uninstalled Acer Arcade anyway...
After uninstalling Acer Arcade and verifying that the other versions of xmlparse and xmltok were no longer stored anywhere on the computer I attempted to start PortableGimp again. Same error message, gimp failed to launch.
I thought perhaps there was continuing conflict with some version of gtk on my system regardless of the fact that nothing, aside from the actual operating system, is now installed on the computer. Yes, I realize that some files may not have been deleted with the uninstall of Acer Arcade.
I did a search of the hard drive for other copies/versions of the files in PortableGimp/gtk/bin.
I did find a different version of iconv.dll stored in the c:\windows directory. This version is 852kb in size, where the version in PortableGimp/gtk/bin is 619kb in size.
I renamed the larger version of the file to icon~.dl~ and attempted to run PortableGimp again. This time PortableGimp2.2.12 was able to launch, with no apparent problems.
I'm not sure exactly what the iconv.dll which was already on my computer was being used for, as it appears to be part of the some gnu library when I do a search for it on the net. I'm going to leave it renamed for now and check out the rest of the system. However I would very much like to be able to use this program on machines for which I do not have the user rights to edit/rename files in the c:\windows folder. I'm afraid I don't know enough about how applications use the dll's to do this myself though.
Does anyone out there know how a specific application gets usage out of these files? Does the program make some kind of call to windows and then trust windows to know whether or not it is indeed the file which the program is looking for? I know that dll's are typically used by many programs and that conflicts occasionally do occur. What I am wondering is why an application which calls for the dll could not make a more specific call, perhaps either for a specific version, or even perform some kind of size or hash check to make sure that the file being called is in fact the one that's going to be compatible.
It was my understanding that windows xp was capable of keeping several different versions of the same files in it's system specifically because of this problem. At least that's what I was led to believe by the MS guys at one of their XP PreRelease conferences.
Found some good information on just this here:
http://setiathome.berkeley.edu/forum_thread.php?id=29085&nowrap=true#268657
It would be useful if something like this could be done. I'm not sure the hardcoded paths mentioned in this thread are able to be relative or if they must be absolute, but it would be nice (this being a portable version of an open source program) if this could be done. This (on my system anyway) appears to be the only file that has this specific problem, and I'm not sure how the hardcoded paths (provided they can be relative) would affect the application. But it seems to me for a portable version of open source software this would be what one would want to do anyway.
Just my $.02 and I hope it helps anyone who is having a similar problem, or helps anyone who is looking to increase this application's portability.
Thanks
SpcHtr
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I also ran into the application error mentioned in the earlier post on my home computer which is a Windows XPSP2 with all updates. Tried at work, also XPSP2 and updated, and everything worked fine. Read the above post and the work computer didn't have any iconv.dll in the windows-folder but my home computer does and renaming it solves the problem.
Cheers
You may want to check for other files that exist in the gtk/bin or even the other directorys of the gtk folder. Any of the dll's could be at fault and may need to be renamed throughout the rest of the system, bare in mind though that this may 'break' some other application that needs whatever files you may have to rename. I thought about trying to write a batch script to do a search of the computer for these file names and have it rename them all, but I'm wasn't sure enough of my batch scripting abilities to want to attempt this myself.
Thanks for the details spchtr, your efforts in helping document this are much appreciated.
As for why this occurs, Windows looks for DLLs first in the system32 and windows directories... and then in the path. Since we're using a combination of the path and environment variables with portable apps, we're stuck with it breaking when some random program has contributed to "DLL Hell" by placing what should be a program-specific DLL into either system32 or windows. It's really the fault of the other misbehaving program for doing this... but we're stuck with the issue and trying to somehow work around it. I did workaround the xmltok.dll and xmlparse.dll issue by offering to rename them and restore them as part of the launcher. If iconv.dll is a common one that may crop up in the windows directory, I could enhance the launcher to do that as well.
As for manifest files, it would get complicated fast as it would need to handle dozens of DLLs in several different directories. And that fix would only work on XP. It wouldn't help use on Windows 98, Me or 2000 (all of which GIMP Portable runs on).
Sometimes, the impossible can become possible, if you're awesome!
Having to rename/delete files for a portable app would be, simply put, a deal breaker.
Now. The file name did initially sound familiar and after doing some hunting I'm about 99.9% sure it's a left over from an attempt at installing a WAMP-environment some years ago. I soon ditched the idea and found easyphp instead but since the PHP installation requires copying iconv.dll manually to the windows folder it most likely got left behind. I also found a php.ini and php4ts.dll with the same creation date. Aditionally I found iconv.dll in easyphp and xampplite but in both cases it resides in their respective program folders. Hope this might shed some light.
cheers
That's why it's optional. (it asks you first) It renames xmlparse.dll to xmlparse.dlldisabled. Same for xmltok.dll. Then it runs GIMP. When GIMP exits, it renames it back. Even if GIMP were to crash or you yank the drive, it would still rename it back, since the launcher is a seperate process. The only situation that would cause it to fail to restore the DLLs is if the PC crashed while GIMP Portable were running.
The incompatibility is relatively rare. And this issue would affect a local install as well. Essentially, GIMP - portable or not - is incompatible with the host PC in its current config. So, the launcher offers to temporarily remedy the situation.
Sometimes, the impossible can become possible, if you're awesome!
would it be possible to rename all the files that gimp uses for the gtk with something like gimpp_xmltok.dll so that it doesn't catch non program specific dlls?
Since we're storing extra copies of these files anyway would it be possible to rename them with unique names or at least with a convention which would probably exclude them from conflicting names? I understand the purpose of the cause of dll hell was to save space, but since I'm devoting space to the copies of the files in the program directory anyway it would seem a unique name for the files used by this application would be a possible solution. Though I'm not sure how much of the source would have to be changed for this to happen. But text search/replace should be fairly easy to achieve in the text files that the source is made up of.
Again, just an idea. I'm glad of all the effort that's gone into resolving these issues already, and so far this has been a simple fix. Also there's a couple of registry keys that change the search order for dll's within windows. I'm also wondering if something could be done to create/change the current key so that the search order changes, then at app-termination it could be changed back. Of course I'm also wondering why Microsoft doesn't have it in the alternate search order anyway. Seems to me an application would prefer to use the copy of the file that it keeps in it's own directory as opposed to some shared file elsewhere in the system. The only thing I can think of is MS is prefering files that they have already looked at the problem is that other 3rd party programs can add to the files that MS has in it's own system. Man I really need to learn how to compile stuff so I can fiddle with it. >:D