Closed stonebig closed 2 weeks ago
How is it "not working"?
Also, how does the subsystem.py
command "fail"?
Please provide full details of what you did and what went wrong, including a copy/paste of a console session demonstrating the problem, otherwise it's not possible to help you.
Hummm, my example is maybe not good.
Desire is:
Current less-bad method found (creating temporarly only a black window) is:
python mkshim.py -f my_ideal_IDLE.exe -c "Powershell.exe start-process -WindowStyle Hidden './scripts/winidle.bat'"
in current technical debt method, these launchers are created via NSIS (.nsi) , with something like: "wscript.exe Noshell.vbs winidle.bat"
That 'Noshell.vbs' trick doesn't want to work with actual mkshim.py script as in github.
Noshell.vbs was just there to hide the black Window opening, and passing the buck, a trick coming from http://superuser.com/questions/140047/how-to-run-a-batch-file-without-launching-a-command-window/390129
remark: If I double-click directly on the "winidle.bat" directly, there is the [ugly] black window, the standard windows experience.
The launcher mostly hide the black window, and pywin32 allows to decorate it with a nice icon, with very low code to carry-on.
The shim exe is a console mode executable. So yes, it will create a console window. Change the executable type to GUI and see if that fixes the issue (the subsystem.py
script here should do that, but as noted it's not supported and it's experimental anyway, so you should probably use a more reliable tool).
shimmy just fit: tiny, open, shippable, and hints on the final problem, even if subsystem.py doesn't seem to work yet.
... OK, thanks, I guess?
I'm not sure what you want to happen here. Is there abug you want fixing, or an action you think needs to be taken? I don't plan on making subsystem.py
an official way of setting the subsystem type of an executable. There are plenty of tools out there already to do that.
ok, so closing
I am still curious as to why you think subsystem.py
isn't working? Can you provide an example of what you did, and a report of what the subsystem type of the executable produced was? You'll need to use something like dumpbin
to find that information. "A console window popped up" isn't sufficient, as there could be many things that open a console window, not just the base executable.
In fact, wouldn't powershell.exe
pop up a console window, as that's not a GUI executable???!?
so:
preparing the example in base shimmy directory:
# python mkshim.py -f my_IDLE_python.exe -c "./python-3.13.0rc1.amd64/python.exe ./python-3.13.0rc1.amd64/Lib/idlelib/idle.pyw"
# python subsystem.py my_IDLE_python.exe my_IDLE_python_gui.exe gui
# python subsystem.py my_IDLE_python.exe my_IDLE_python_batch.exe batch
windidle.bat "iconised", the real case:
setup:
launched from the cmd.exe terminal, instead of double-click:
launched from the cmd.exe terminal, instead of double-click:
so that’s definitely because you are running a console command (python.exe
) from a gui process (my_IDLE_python_gui.exe
). Which confirms that subsystem.py
is working correctly. You need to use python.exe
instead.
I used python.exe , in the reproductible example:
./python-3.13.0rc1.amd64/python.exe
subsystem.py effect looks neutral.
Sorry, autocorrect. You need to use pythonw.exe
. You should really understand subsystems well if you want to use this project with GUI executables. I’d recommend reading the Microsoft documentation on them.
this creates a working test_python.exe :
python mkshim.py -f test_python.exe -c "C:\...\python-3.13.0rc1.amd64\python.exe"
but this fails to create a working test_pythonw.exe: python mkshim.py -f test_pythonw.exe -c "C:...\WPy64-31301rc1\python-3.13.0rc1.amd64\pythonw.exe"
As any one a solution to this ?
at first I thought this would do it.... fail
python subsystem "test_pythonw.exe" "test_pythonw_yes.exe" gui