GNOME Bugzilla – Bug 574018
Add a manifest to executables
Last modified: 2011-06-16 07:55:46 UTC
Please describe the problem: When making a new brush in gimp, the path get's messed up after it is saved. For example I save a new brush in C:\Program Files\GIMP-2.0\share\gimp\2.0\brushes Gimp will continue to believe that that is where the brush is if you open the brush in gimp, or ask it to give you the path to that brush. But if you go looking for that brush in the windows explorer, it will not appear in that file. (Also if you ask gimp to copy the path and then past it in, windows will say it doesn't exist). It will instead store the brush in C:\Users\[username]\AppData\Local\VirtualStore\Program Files\GIMP-2.0\share\gimp\2.0\brushes Now gimp doesn't recognize that the brush is stored here, it thinks it's stored in the first path. This is mainly a problem for people that might want to delete brushes because they still work, but can't be removed until they are actually found and deleted from the file. Steps to reproduce: 1. Make a new brush 2. save it in the gimp brush folder Actual results: The brush gets stored in one place, while gimp says it is stored somewhere else. Brush still works, but can't be deleted (or easily found) as it is not where it says it is. Expected results: I expect the brush to be saved in the folder I saved it in, not some obscure folder in a hidden file. Does this happen every time? Yes Other information:
Sounds like a Vista-specific problem to me, perhaps something that can be addressed in the installer?
This is intended behaviour in Vista - normally all programs run with limited privileges, and as such they aren't allowed to write to secure locations (which includes Program Files). To prevent breaking old applications, Vista silently redirects such writes to user-specific area. There are two ways to prevent this from happening: - run GIMP as Administrator - add a manifest to all GIMP's executables to prevent filesystem virtualization from happening (in this case, trying to save something to Program Files will instead result in access denied message) More info on manifests: http://msdn.microsoft.com/en-us/library/bb756929.aspx
Do comparable proprietary applications care about this in any way? Do they prevent virtualization, or show messages telling the user that when he thinks he has saved in one place he actually has saved in another place, or something like that?
Most programs ship with the manifest nowadays, and don't do anything special when user tries to write to protected locations - they simply display the error message. Writing to Program Files on Windows is the same as writing to /usr in Unix - normal users aren't allowed to. The Windows standard file open/save dialogs display a notification when something is available in VirtualStore though.
Since the global path is shown as non-writable in GIMP's preferences (at least that was the case for this user), "allowing to write" there actually should be considered a bug imho.
If we can finally disallow saving to the system folders on Windows, then we should do that. Please add such a manifest file. I wonder why the user tried to save the folder in that location in the first place...
(In reply to comment #6) > I wonder why the user tried to save the folder in that location in the first > place... Good question ,answer is simple : because the other location is for average windows users invisible. Both C:Users/username/.gimp-2.x (vista) or C:Documents and Settings/username/.gimp-2.x (for xp) are not invisible because hidden, but as a fact: is a places where (average )windows users will NEVER search without a tip, (a tip with screenshoots!... not just with the path) just because few know that "C:Users/username/gimp "exist More the "." in " /.gimp " indicate in win the same then in unix : a directory as default should be invisible Is far more easy from them search in Programs Files, anybody that add a plugin to any other Win programs know that has to "dump the thing" in "Program Files/Program-Name/plugin" so they just do the same for gimp. This because Program Files even if may be protected in VISTA is clearly visible, while the (top level of ) user directory is less protected but much better hidden from majority of users >If we can finally disallow saving to the system folders on Windows, then we >should do that. Please add such a manifest file. Then you will be flooded by help request and disappointed messages by windows users Only way to avoid will be a warning the first time Gimp load as "to install additional, plugin,script, brush use EDIT/Preferences/Folder" That pop out ...or a flood of complains and request of support
Here's what needs to be done to disable virtualisation: diff --git a/app/gimp.rc b/app/gimp.rc old mode 100644 new mode 100755 index 9843f27..4b00fdb --- a/app/gimp.rc +++ b/app/gimp.rc @@ -1,2 +1,4 @@ +#include "winuser.h" 1 ICON "wilber.ico" 2 ICON "fileicon.ico" +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "gimp.manifest" gimp.manifest should contain at least: <?xml version="1.0" encoding="utf-8"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <description>GIMP</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false" /> </requestedPrivileges> </security> </trustInfo> </assembly> However, this manifest must be included in all executables - not just gimp.exe.
Created attachment 159207 [details] Proper manifest for GIMP Here's a proper manifest for GIMP, which also declares compatibility with Windows 7 and high DPI settings (without declaring DPI compatibility, GIMP is rendered like this: http://eternallybored.org/misc/gimp/2.7.1-without_manifest.png with high DPI settings on Windows 7).
Created attachment 164325 [details] [review] 0001-Bug-574018-Add-a-manifest-to-executables.patch Like this?
Created attachment 164326 [details] [review] 0001-Bug-574018-Add-a-manifest-to-executables.patch Or rather, like this?
We have it for ./app now: commit ff1da59f3322ec286d50b4a65473413d0b63f212 Author: Martin Nordholts <martinn@src.gnome.org> Date: Tue Jun 22 19:35:16 2010 +0200 Bug 574018 - Add a manifest to executables Patch from Jernej Simončič. Now we need someone to apply it to all plug-ins too.
Would be elegant if libtool could take care of this somehow, but probably not worth it to wait for that to happen. Can anybody think of some nice automatic way to make all plug-ins also be linked with a (automatically generated?) plug-in-specific .rc file that would refer to a (common?) manifest file?
Well, for the plug-ins in plug-ins/common this is simple as that Makefile.am is auto-generated. For the other plug-in, I am afraid you will have to edit all Mafefile.am files. We already have windows specific linker flags in all those files, so just go ahead and add to that.
Review of attachment 164326 [details] [review]: Committed.
Not something that blocks any release, moving off milestone
The general idea was to have the windows-specific files for this (*.rc, *.ico, *.manifest) moved from app to a different directory and have a generic rule to create the plug-in-specific .rc file (although we can get away with just creating the specific .rc.o files, like it is already done for the gimp-x.y.exe and gimp-console-x.y.exe). I've done changes locally that: - move the resources to $(top_srcdir)/build/windows/ - use one pattern-rule to make the .rc.o for each binary With thse changes, it is sufficient to add e.g. file-foo.rc.o to the LDADD of plug-in foo to have the resources including version information, icons and manifest created and linked to file-foo.exe
commit 82dca2ecf4030adba8119b81f477d25e06b986fa Author: Michael Schumacher <schumaml@gmx.de> Date: Thu Aug 26 22:10:07 2010 +0200 Bug 574018 - Add a manifest to executables Eventually all executables will have the manifest and version resources linked. In this initial step, the current resources are moved from the app/ directory to a global build/windows directory.
commit 9781cf1523006aafb21c0a7f92a3c3b5faf41de7 Author: Michael Schumacher <schumaml@gmx.de> Date: Fri Aug 27 21:13:03 2010 +0200 Bug 574018 - Add a manifest to executables This step moves the %.rc.o pattern rule to a small include file in the build/windows/ directory. Michael Natterer suggested this approach in order to minimize the changes done to each executable's Makefile.am.
This is working fine in my builds for quite some time. I'm closing the bug as fixed. If anyone wants to change something in the build/windows/*.rule files, please verify that the build works on a Windows platform or at least a build environment that has a windres tool before committing anything.