I've noticed that there is a glaring problem with 'automatically' starting a portable app. Whenever I shutdown my computer, or the power goes out, and I restart it (I could set it to automatically boot in BIOS), my portable apps throw an error that I did not close them properly, then instruct me to restart them manually. For me, the only portable app that I automatically start is WinSplit Revolution, and it restarts fine, because it is not built to portable apps standards.
Why is it such a big deal to force a user to restart the app manually? Why can't it throw a popup error, then automatically restart an app without intervention? Why does it need an error at all?
I already know of one software developer who does not use portable apps for this exact reason. I propose that portable apps automatically start (and restart themselves when necessary), even when they are not shutdown 'properly'.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
This has already been fully discussed in another topic which is now closed: https://portableapps.com/node/28953
From that topic: "Yes, we would like to be able to update the PortableApps.com Launcher (aka PAL) to be able to warn you of an unsafe close and be able to click OK and re-start automatically. Unfortunately, this will require a MAJOR rewrite of PAL to accomplish this. Our volunteer developers do not currently have time to do this."
Since that topic was closed, you can now use the PortableApps.com Platform to automatically close all your apps and alert you which ones can't be automatically closed without possibly losing data. Modern Windows will just kill apps if they don't respond within a few seconds, possibly causing data loss. That's generally not something you want to happen.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for the link.
There have been very many times when I have tried to turn off my Windows computer, when Windows has refused to shutdown. This is due to differing software that requires Windows to stay open until a pending save action is authorized by the user. This is such a great security risk that I always babysit my Windows computer until the shutdown is complete.
This is, however, an excellent way to fulfill the needs of the users.
It could potentially function like a program that is started every time the portable apps launcher is started. This supervisory program's purpose would be to use the Windows feature that denies shutdown. When all the other portable apps are closed, then the supervisory program would close by itself, and since it is only loaded into ram, it cannot leave anything on the host computer.
It would basically deny Windows from shutting down at all, and it doesn't have to be programmed with NSIS (the language PAL is coded in). It should then be possible to have NSIS respond correctly to the Windows shutdown message.
Oh, and if this requires a complete re-write of all the software to fulfill the needs of the users, then so be it. Put it on the roadmap. This would also be a good time to get rid of NSIS if it can not support the features PAL needs.
The GNU Blender project absolutely needed such a recode (Blender 2.49b to 2.5), as all projects eventually do, and afterward it was finally able to be used by professionals, and gained tremendous momentum.
Windows shutdown doesn't work that way. The modern API requires that EVERY SINGLE APP that shouldn't be crashed by Windows must tell it so, tell it why, and then stay in touch via the API and Windows messaging. The platform could prevent Windows from shutting down, but Windows will go ahead and kill off all the launchers at the same time.
Doing it properly would require every single app to be rewritten. I don't have that much time in my life to work for free (or negative money).
Sometimes, the impossible can become possible, if you're awesome!
By the way, is this part of the documentation that people see when they go to package a portable app? We can try to get those helpful individuals who package the portable apps to request this feature on the respective app's feature request system. Since the application developers are packaging their apps for Windows anyway, if we give them a nudge with enough information to fix it, we should be able to contribute to a reduction of the problem.