SOLVED

[MSIX] - Packaging GIMP

Copper Contributor

Hello,

 

I have created an MSIX from GIMP. When running the application I get approximately 100 error messages that various .dll files cannot be found.

 

What happens:

  1. VFS\ProgramFilesX64\GIMP 2\bin\gimp-2.10.exe is started.
  2. After a while the application VFS\ProgramFilesX64\GIMP 2\lib\gimp\2.0\plug-ins\web-page\web-page.exe is started.
  3. During the startup process, I get an error that the file libgimpui-2.0-0.dll cannot be found. That file is located in VFS\ProgramFilesX64\GIMP 2\bin

To workaround I created a PSF:

  • Modified AppxManifest.xml:
    <Application Id="GIMPTwoOneZero" Executable="PsfLauncher64.exe" EntryPoint="Windows.FullTrustApplication">
  • Created config.json:

    {

    "applications": [
    {
    "id": "GIMPTwoOneZero",
    "executable": "VFS\\ProgramFilesX64\\GIMP 2\\bin\\gimp-2.10.exe",
    "workingDirectory": "VFS\\ProgramFilesX64\\GIMP 2\\bin"
    }
    ],

    "processes": [
    {
    "executable": ".*",
    "fixups": [ { "dll": "PsfRuntime64.dll" } ]
    }
    ]

    }

I created a new MSIX package and signed it. When running the application the 'main' gimp-2.10.exe is started and is closed immediately.

 

My question is what I should do to get this package working.

 

Any feedback is appreciated and with kind regards,

Willem-Jan

15 Replies

Best solution is to remove Plugin folder from the VFS.

Issue is with loading bin folder DLL's.

 

 

@pandaysumitroy 

 

Hello,

 

Many thanks for your reply. Removing the plugins folder is an idea, but not a very good one. Then I will end up with a version without the plugins. And that is not what I want.

 

With kind regards,

Willem

@TheStingPilot For workaround you can follow below steps .

You can rename or delete plugin folder from VFS [VFS\UserProgramFiles\GIMP 2\lib\gimp\2.0\plug-ins].

GIMP will load successfully after disabling plug-ins folder.

On launch - go to EDIT -> Preference and specify the plugin folder.you can copy the plugin folder from working machine and it can be used to load GIMP plugin.

No idea why its unable to load plugin from VFS directory.

i am also stuck with the issue.

 

 

 

 

 

@TheStingPilotFound a workarround for this. If we check with procmon what is happening, after gimp is loaded, the plugins are searching for some DLLS in BIN. While the psf redirection works and the plugins then search in the correct directory, for whatever reason gimp.exe fails to start. When it calls to dlls it returns only buffer overflows.

 

However, if we look closely in procmon, we can see that each and every plugin is searching for the DLL files in 3 directories:

 

1. The BIN folder

2. The plugin directory (each plugin searches in its own directory)

3. System64 (C:\Windows\System32) - For 64bit plugins

4. System32 (C:\Windows\Syswow64) - For 32bit plugins

 

I have made a capture of Gimp with Advanced Installer, and, without any redirections, i copied all the DLLs from the BIN folder in System64. After the installation almost everything seems to work (99%), except twain.exe.

 

To fix twain.exe to throw an error, you must also copy all the DLL files from 32\BIN to System32.

 

After that everything works correctly and applications starts/loads plugins.

 

Hope this helps,

Kind regards.

@alexmarin89 Thank you for the workaround, above workaround resolves the startup error however "Plug-In Broswer" is not working.

You can access Plugin Browser from Help > Plugin Browser, it details list of plugin installed.

i doubt whether plugin are being loaded correctly.

PLUGIN BROWSERPLUGIN BROWSERERRORERROR

 

best response confirmed by TheStingPilot (Copper Contributor)
Solution

@pandaysumitroy  Indeed, just tried it now and it doesn't work. Apparently this only suppresses the load failure of the plugins.

Apparently the GIMP community is also struggling with these issues (also somebody else already tried to put the plugins in System32 and System64 with the same exact results).

 

However, i did notice something, which i am not sure why is happening like this for the moment. While you capture GIMP, if you install it in other folder than the default one (C:\Test or C:\Gimp or any other folder), when you install the MSIX you won't receive the plugin failures anymore (so no need to copy the dlls in System32 and System64).

 

From my opinion this has something to do with how GIMP gets the paths and the whole logic of finding/loading plugins.

 

Still searching for a work around to make it work, will let you know if i have any further progress with this.

@alexmarin89 

 

Hello,

 

I have installed GIMP in C:\APPS64\Gimp 2 but I still get the error messages that various .dll files cannot be found. (libgimp-2.0-0.dll for example).

 

I will do some troubleshooting. 

 

With kind regards,

Willem  

@TheStingPilotI tested 2.10.12 by creating the folder structure specified in their git board (C:\Output\Gimp) and installed it there (the path should be after installation C:\Output\Gimp\Gimp 2).

After that in the capture with Advanced Installer i specified the application folder to be GIMP 2, that solved for me the problem of copying the dlls to system32 and system64. But that doesn't work either.

 

However, i've done more tests and i was thinking maybe something has changed since the 2.10 release of GIMP...and indeed something has changed.

 

I made a capture for GIMP 2.8.22. When you try to build it the first time you will receive some errors that GIMP 2\32\lib\gimp\2.0\python\gimp.pyd.debug' is not a valid Portable Executable for 'Build_MSIX_APPX->x64' build and other 4 or 5 .debug files.

 

I've deleted the files, doesn't seem to affect how it works. But of course i ran into the issues with the dlls that are not loading.

 

So again i've copied the dlls in System32 and System64. I also changed the Application Folder to be in GIMP 2.

 

And after that, everything works! GIMP 2.8.22.0 works with MSIX!

 

I am now curious what are the differences, i will try to do some more digging to see if maybe it's something that can be solved for the latest 2.10 releases also.

 

I thought maybe it's some hardcoding in some files, the only thing i found it in pygimp.interp located in lib\gimp\2.0\interpreters:

 

python=C:\Output\Gimp\GIMP 2\bin\pythonw.exe
python2=C:\Output\Gimp\GIMP 2\bin\pythonw.exe
/usr/bin/python=C:\Output\Gimp\GIMP 2\bin\pythonw.exe
:Python:E::py::python:

 

However, trying to dehardcode that file doesn't solve much. And with a normal installation if you delete that file it doesn't seem to affect the functionality of GIMP, so that's a no go there also.

 

You can get the MSIX for 2.8.22.0 here.

 

2.8.jpg

Hi Alex, and how did you figure out which DLLs are 64 bit and which are 32 bit, or you did a try-and-error scenario? I.e. Is there any trick in procmon or logic that if the app first searches in System32 we are talking about 64bit plugins? Thanks for your feedback.

@WesleeJKN0487 There is a "simpler" way getting this done. You may want to add the following code to your manifest (under the package element):

 

  <Extensions>
      <uap6:Extension Category="windows.loaderSearchPathOverride">
        <uap6:LoaderSearchPathOverride>
          <uap6:LoaderSearchPathEntry FolderPath="bin"/>
        </uap6:LoaderSearchPathOverride>
      </uap6:Extension>
    </Extensions>

 

 This way GIMP is also checking the bin directory to load dlls and other binaries.

 

@alexmarin89 @At this point thank you for your great blog and the free Advanced Installer Express version... you guys may want to add the loaderSearchPartOverride to your feature list :)

@TheStingPilot 

  1. You need to include the FileRedirectionFixup for this application. 
  2. You do not need to include the reference to PsfRuntime as that is assumed (although it must be included in the package).
  3. The config for the FRF would need to include relevant VFS paths.  If you use PsfTooling to perform the injection, then you only need to ask for the FRF and keep all defaults.  This also fixes up the icon for you so you don't get a blue square for the icon.

@alexmarin89 

You don't need these anymore, you can use this

  <Extensions>
    <uap10:Extension Category="windows.installedLocationVirtualization">
      <uap10:InstalledLocationVirtualization>
        <uap10:UpdateActions AddedItems="keep" DeletedItems="reset" ModifiedItems="keep" />
      </uap10:InstalledLocationVirtualization>
    </uap10:Extension>
    <uap6:Extension Category="windows.loaderSearchPathOverride">
      <uap6:LoaderSearchPathOverride>
        <uap6:LoaderSearchPathEntry FolderPath="VFS\ProgramFilesX64\GIMP 2\bin" />
        <uap6:LoaderSearchPathEntry FolderPath="VFS\ProgramFilesX64\GIMP 2\lib" />
        <uap6:LoaderSearchPathEntry FolderPath="VFS\ProgramFilesX64\GIMP 2\32" />
        <uap6:LoaderSearchPathEntry FolderPath="VFS\ProgramFilesX64\GIMP 2\share" />
        <uap6:LoaderSearchPathEntry FolderPath="VFS\ProgramFilesX64\GIMP 2" />
      </uap6:LoaderSearchPathOverride>
    </uap6:Extension>
  </Extensions>

 

@alexmarin89 Further research has shown that Gimp is using a windows API out of ucrtbase to load DLLs, and this API bypasses any of the PSF fixups, essentially bypassing the PSF for those calls.  This is why copying the dlls to the SystemXXX folders helps on that loading.

 

Otherwise, Gimp developers have a habit of opening a file and then querying the handle to find that file's location, extract the directory, and use that to open different nearby file.  This behavior frustrates and confuses ILV when a redirection was done. So ILV shouldn't be used on this app.

 

This app remains on my "can't do" list with additional issues preventing launch. -Tim

@WesleeJKN0487  I have that build into TMEditX to automate the fixup, but there is a free cmdline utility you can google called PeInfo that will answer the question of bitness for a particular exe or dll.

@pandaysumitroy@alexmarin89 Oh, and I forgot that the free PsfTooling app also has a GUI program called Test_PeInfo that you can use to look at exes and dlls for this purpose.

1 best response

Accepted Solutions
best response confirmed by TheStingPilot (Copper Contributor)
Solution

@pandaysumitroy  Indeed, just tried it now and it doesn't work. Apparently this only suppresses the load failure of the plugins.

Apparently the GIMP community is also struggling with these issues (also somebody else already tried to put the plugins in System32 and System64 with the same exact results).

 

However, i did notice something, which i am not sure why is happening like this for the moment. While you capture GIMP, if you install it in other folder than the default one (C:\Test or C:\Gimp or any other folder), when you install the MSIX you won't receive the plugin failures anymore (so no need to copy the dlls in System32 and System64).

 

From my opinion this has something to do with how GIMP gets the paths and the whole logic of finding/loading plugins.

 

Still searching for a work around to make it work, will let you know if i have any further progress with this.

View solution in original post