Sigil and calibre Open With

[DNSB]

I was noticing that with Sigil 2.6.2 compiled with Qt 6.9.2, Sigil no longer opens with either the Open With plugin or calibre's builtin Open With action. At this time, I tend to suspect that this is due to calibre still using Qt 6.8.2 but will do some more digging into this. The debug output command line works if I copy/paste it to a command prompt or into a batch file.

[theducks]

Originally Posted by DNSB

I was noticing that with Sigil 2.6.2 compiled with Qt 6.9.2, Sigil no longer opens with either the Open With plugin or calibre's builtin Open With action. At this time, I tend to suspect that this is due to calibre still using Qt 6.8.2 but will do some more digging into this. The debug output command line works if I copy/paste it to a command prompt or into a batch file.

Works for me W10 using Open With PI (my default for years).

[DNSB]

Originally Posted by theducks

Works for me W10 using Open With PI (my default for years).

Are you using Sigil 2.6.2 with Qt 6.8.2? It works for me if I compile Sigil using Qt 6.8.2. It's when I update Qt to 6.9.2 that either of calibre's Open With options fail. See the attached image.

[theducks]

I use the stock download with QT 6.8.2.

Sorry

[DiapDealer]

Did a little debugging of this on my own and discovered what's happening, but not exactly why. It's related to my previous thread about about certain versions of the VC++ redist runtime not being sufficient to run Sigil and its included Qt6.9.2 (https://www.mobileread.com/forums/sh...d.php?t=369925).

Calibre distributes MSVCP140.dll with its own installer and that is the version that Sigil is trying to use (and silently failing) when launched from Calibre with its inherent Open With feature. The same command line (provided by calibre-debug) uses the system MSVCP140.dll (which is newer than calibre's) and succeeds when run outside of Calibre. The fault can be seen in the Windows Event Viewer after trying to launch Sigil with Calibre's Open With (note the faulting module path):

Faulting application name: Sigil.exe, version: 2.6.2.0, time stamp: 0x68cac4a8
Faulting module name: MSVCP140.dll, version: 14.36.32532.0, time stamp: 0x04a30cf0
Exception code: 0xc0000005
Fault offset: 0x0000000000012f58
Faulting process id: 0x37b0
Faulting application start time: 0x01dc32d777d6ff52
Faulting application path: C:\Program Files\Sigil\Sigil.exe
Faulting module path: C:\Program Files\Calibre2\app\bin\MSVCP140.dll
Report Id: 897b5901-dac8-44bc-80fd-e48cad7fcf17
Faulting package full name: 
Faulting package-relative application ID:

This is probably only relevant to a Sigil that is built with very recent versions of Visual Studio's C++ compiler and toolchain (which would include my CI builds). My own Windows Sigil releases are still built with an older version of Visual Studio c++ compiler and toolchain, and probably will be until something forces me to update. I will confirm that my release builds of Sigil aren't going to be affected by this and report back.

Otherwise, this will probably be an issue until Calibre includes a newer MSVCP140.dll that is compatible with exe's built with newer versions of the Visual Studio C++ toolchain (or until Kovid discovers a way to sanitize the Open With process environment in such a way that its own bundled MSVCP140.dll is not used by external programs that Calibre launches). Not that I'm trying to make work for him! I'm just not convinced this will be an issue with official Sigil releases.

[DiapDealer]

Well apparently no. Even when built with my release environment (using version 14.39 of the VS vc++ compiler), the Qt6.9.2 version of Sigil will not launch from Calibre's Open With with its 14.36.32532 version of MSVCP140.dll. So much for that.

[DNSB]

For what it may be worth, I tried compiling calibre with the newer msvcp dlls. To speed things up, I took one of my existing Linux VMs and increased it's CPU count, disk size and memory sice. It wasn't as painful as I thought it would be but did take longer than I thought it would to create the Windows installer. I suspect this to have to do with creating new QEMU VMs inside a VMWare Workstation VM. The newly compiled and installed calibre with msvcp 1.44.35207 works with Open With. Since I'm not certain how many new bugs I have created with this, I've reverted to the stock calibre.

[DiapDealer]

I've recompiled Qt6.9.2 with an older version of the VC++ compiler (19.40) and hope to test with a version of Sigil built using it eventually. I fear backward compatibility has been broken somewhere in the Visual Studio tool chain. Even the version of VC++ used to compile Sigil's Qt6.8.2 is newer than the 14.36 version of msvcp140.dll included with Calibre, and it still worked with no problems.

[kovidgoyal]

This is because calibre uses SetDllDirectory so that exes it bundles load their implicitly linked dlls from the calibre dll directory. This is a process global setting and cant really be turned off when launching external programs because its not a thread safe API. Sigil can fix this (not easily) by using a stub launcher for its exe which calls setdlldirectory itself and then loads a dll using LoadLibrary() that contains the actual launcher code (this is what calibre on windows does (see bypy/windows/main.c for an example).

In calibre I could fix this by running a worker process for every launch that resets setdlldirectory and then does the actual launching to get around the thread safety issues, but this is both 1) likely to be fragile 2) add a lot of delay to running external programs as the worker will need to spin up both python and qt to use QDesktopServices.openUrl. Or I could use the existing cleanup on exit worker to do this, which fixes 2 since that worker is launched anyway. 1 remains though.

On the other hand I could just ignore the thread safety issues (calibre already resets env vars when launching which have similar thread safety issues).

[kovidgoyal]

There you go: https://github.com/kovidgoyal/calibr...8738af6b5ea566

EDIT: Never mind this isnt the codepath used on windows, I think I will try using ShellExecuteEx instead.

[DiapDealer]

I really appreciate the effort. But please don't make changes to Calibre you're not comfortable with just to accommodate this. I'm still determined to find out why the backward compatibility we've enjoyed for so long with VC++ compiler versions/runtimes seems to have been broken. Or maybe figure out what I've done wrong compiling Qt6.9.2 to make it seem so.

[kovidgoyal]

This should take care of it, a much simpler solution that delegates actually running the opened program to the windows shell so that should provide completely clean separation of the calibre environmet from that of the launched application.

https://github.com/kovidgoyal/calibr...1a065bfde4f6e0

[DNSB]

No joy. I reverted to the downloaded 8.12, updated the source and still gives the same nothing happens. Paint.net still opens but not Sigil. I am running from source so that might be why.

Open With with Sigil 2.6.2 with Qt 6.8.2 still works.

[3.28] main UI initialized...
[3.28] Hiding splash screen
[3.30] splash screen hidden
[3.30] Started up in 3.30 seconds with 2 books
Open:  C:\Program Files\Sigil\Sigil.exe (file):  C:\Users\<username>\Calibre\Intake\Courtenay Raia\The New Prometheans (950)\The New Prometheans - Courtenay Raia.epub  (args):  
cmd_line: "C:\Program Files\Sigil\Sigil.exe" "C:\Users\<username>\Calibre\Intake\Courtenay Raia\The New Prometheans (950)\The New Prometheans - Courtenay Raia.epub"
Running Open With commandline: '"C:\\Program Files\\Sigil\\Sigil.exe" "%1"'  |==>  C:\Program Files\Sigil\Sigil.exe "C:\Users\<username>\Calibre\Intake\Courtenay Raia\The New Prometheans (950)\The New Prometheans - Courtenay Raia.epub"
Running Open With commandline: '"C:\\Program Files\\paint.net\\paintdotnet.exe" "%1"'  |==>  C:\Program Files\paint.net\paintdotnet.exe "C:\Users\<username>\Calibre\Intake\Courtenay Raia\The New Prometheans (950)\cover.jpg"
[31.20] Shutdown starting...
[31.42] [Backup Configuration Folder]: starting backup process
[33.58] [Backup Configuration Folder]: wrote config backup to C:\Users\<username>\Desktop\Calibre Config Backups\backup-calibre\2025-10-04 at 19-53-49.zip. Size: 84,860,586 bytes.
[33.58] [Backup Configuration Folder]: finished
[35.61] Shutdown complete, quitting...

[kovidgoyal]

Hmm then it's likely to be something else as I dont see how setdlldirectory can persist across ShellExecuteEx

[DiapDealer]

I'm finding some evidence little by little that suggests that any app component built by Visual Studio 17.10 or newer (that uses mutex) will require a minimum of version 14.40.33810.0 of the. VC++ runtime to run without crashing.