Luckily, I accidentally found the lines that caused this issue. If I disable them, everything works fine:
Index: process.py===================================================================--- process.py (revision 1415)+++ process.py (working copy)@@ -184,9 +184,9 @@ # Some required structures for the method call...
startupinfo = StartupInfo()
ctypes.memset(ctypes.addressof(startupinfo), 0, ctypes.sizeof(startupinfo))
- # Do not create a console window.- startupinfo.dwFlags = subprocess.STARTF_USESHOWWINDOW- startupinfo.wShowWindow = subprocess.SW_HIDE+# # Do not create a console window.+# startupinfo.dwFlags = subprocess.STARTF_USESHOWWINDOW+# startupinfo.wShowWindow = subprocess.SW_HIDE startupinfo.cb = ctypes.sizeof(startupinfo)
processinfo = ProcessInformation()
The lines in question are part of [r1318]. I played around with it a bit and it turned out that only the _get_creationflags function is needed to prevent a cmd window to show up for a short period of time when starting MComix. Note that this does not affect cmd windows created when "open with" bat files. (At least from my point of view, this is just another quirk of Windows). Therefore, I think we can simply remove the lines disabled by the patch above.
@Benoit Pierre: If there is anything else you know why we should still keep those lines, please let me know.
This was added to prevent console windows from appearing when using openwith (see [bugs:#85]). So if you remove it, then they'll be back...
_get_creationflags is only used by process.call and process.popen, not by Win32Popen, which itself is only used by openwith....
I have looked at how subprocess.Popen([...], creationflags=_get_creationflags()) is handled in CPython implementation, and I think we could patch the code like this.
Can you check if this work in your case?
In the long term, I'm thinking of reworking process to use a modified version of Win32Popen when on Windows: so we can pass Unicode arguments. Because right now, for example, if I create a PDF with a filename that does not consist of only ASCII characters, and try to open it with the Windows version, I get told by MComix that there are no images in the archive, but using an openwith command that calls MuPDF works fine. See WIP here. I would not mind some testing too. The testsuite passes, and the aforementioned example works fine too.
Thank you for searching for the related bug. I browsed the history myself earlier, too, but it seems that the title was not expressive enough for me to find it.
_get_creationflags is only used by process.call and process.popen, not by Win32Popen, which itself is only used by openwith....
I'm sorry for the confusion, I justed wanted to say the same thing you just said. (I still wonder, though, why changing Win32Popen affects 7z "extraction" cmd windows.)
Concerning your Win32Popen_fix: Well, it almost works: No windows when extracting (e.g. 7z) or calling a bat file, and windows for GUI programs (e.g. mspaint). However, with this patch, the cmd window never shows up, not even C:\Windows\System32\cmd.exe /K C:\Windows\System32\cmd.exe opens a window. (It creates two cmd.exe processes, though.) So I guess we will need a parameter to control whether subprocess.SW_HIDE should be enabled (for archive extraction) or not (for "open with").
Concerning the WIP: It sounds interesting but I don't have time for this right now. Therefore, I might have a closer look at it later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry for the confusion, I justed wanted to say the same thing you just said. (I still wonder, though, why changing Win32Popen affects 7z "extraction" cmd windows.)
It does not, but one of the example in the discussion of [bugs:#85] was using an external command that calls 7z, hence the change to Win32Popen.
Concerning your Win32Popen_fix: Well, it almost works: No windows when extracting (e.g. 7z) or calling a bat file, and windows for GUI programs (e.g. mspaint). However, with this patch, the cmd window never shows up, not even C:\Windows\System32\cmd.exe /K C:\Windows\System32\cmd.exe opens a window. (It creates two cmd.exe processes, though.) So I guess we will need a parameter to control whether subprocess.SW_HIDE should be enabled (for archive extraction) or not (for "open with").
But without the creation flag, do we always get a console window?
I justed tested all three versions again, just to make sure (based on [r1416], with _get_creationflags as defined in [r1416] as well):
Without any patch, mspaint does not show a GUI (bad), extraction works without GUI (good), "open with cmd" never shows a cmd window (bad).
With your patch, mspaint shows a GUI (good), extraction works without GUI (good), "open with cmd" never shows a cmd window (bad).
With my patch, mspaint shows a GUI (good), extraction works without GUI (good), "open with cmd" shows a cmd window (good).
It turns out that my patch works just the way it should. I might have messed up earlier, because for some more testing, I had also forced the _get_creationflags function to always return 0x0 but forgot about it. Therefore, I just tested it again, this time with _get_creationflags always returning 0x0:
Without any other patch, mspaint does not show a GUI (bad), extraction works only with GUI (bad), "open with cmd" never shows a cmd window (bad).
With your patch, mspaint shows a GUI (good), extraction works only with GUI (bad), "open with cmd" shows a cmd window (good).
With my patch, mspaint shows a GUI (good), extraction works only with GUI (bad), "open with cmd" shows a cmd window (good).
In other words, concerning the changes made in [r1318],
the parts related to _get_creationflags are just right,
but the part related to subprocess.SW_HIDE is too much.
Therefore, I would like to apply my patch as posted (at the beginning of this thread).
Luckily, I accidentally found the lines that caused this issue. If I disable them, everything works fine:
The lines in question are part of [r1318]. I played around with it a bit and it turned out that only the
_get_creationflagsfunction is needed to prevent a cmd window to show up for a short period of time when starting MComix. Note that this does not affect cmd windows created when "open with" bat files. (At least from my point of view, this is just another quirk of Windows). Therefore, I think we can simply remove the lines disabled by the patch above.@Benoit Pierre: If there is anything else you know why we should still keep those lines, please let me know.
Related
Commit: [r1318]
This was added to prevent console windows from appearing when using openwith (see [bugs:#85]). So if you remove it, then they'll be back...
_get_creationflagsis only used byprocess.callandprocess.popen, not byWin32Popen, which itself is only used byopenwith....I have looked at how
subprocess.Popen([...], creationflags=_get_creationflags())is handled in CPython implementation, and I think we could patch the code like this.Can you check if this work in your case?
In the long term, I'm thinking of reworking
processto use a modified version ofWin32Popenwhen on Windows: so we can pass Unicode arguments. Because right now, for example, if I create a PDF with a filename that does not consist of only ASCII characters, and try to open it with the Windows version, I get told by MComix that there are no images in the archive, but using an openwith command that calls MuPDF works fine. See WIP here. I would not mind some testing too. The testsuite passes, and the aforementioned example works fine too.Related
Bugs:
#85Last edit: Benoit Pierre 2015-12-07
Thank you for searching for the related bug. I browsed the history myself earlier, too, but it seems that the title was not expressive enough for me to find it.
I'm sorry for the confusion, I justed wanted to say the same thing you just said. (I still wonder, though, why changing
Win32Popenaffects 7z "extraction" cmd windows.)Concerning your Win32Popen_fix: Well, it almost works: No windows when extracting (e.g. 7z) or calling a bat file, and windows for GUI programs (e.g. mspaint). However, with this patch, the
cmdwindow never shows up, not evenC:\Windows\System32\cmd.exe /K C:\Windows\System32\cmd.exeopens a window. (It creates twocmd.exeprocesses, though.) So I guess we will need a parameter to control whethersubprocess.SW_HIDEshould be enabled (for archive extraction) or not (for "open with").Concerning the WIP: It sounds interesting but I don't have time for this right now. Therefore, I might have a closer look at it later.
It does not, but one of the example in the discussion of [bugs:#85] was using an external command that calls 7z, hence the change to Win32Popen.
But without the creation flag, do we always get a console window?
Related
Bugs:
#85I justed tested all three versions again, just to make sure (based on [r1416], with
_get_creationflagsas defined in [r1416] as well):It turns out that my patch works just the way it should. I might have messed up earlier, because for some more testing, I had also forced the
_get_creationflagsfunction to always return 0x0 but forgot about it. Therefore, I just tested it again, this time with_get_creationflagsalways returning 0x0:In other words, concerning the changes made in [r1318],
_get_creationflagsare just right,subprocess.SW_HIDEis too much.Therefore, I would like to apply my patch as posted (at the beginning of this thread).
Related
Commit: [r1318]
Commit: [r1416]
OK.