Packer thinks app is closed during splash screen of app / False repack

[assenizator]

Hi! When I try to open most of apps with launcher/splash screen when during launch splash screen closes an apps window opens, Appacker thinks that the app is closed and its time to repack. I had this issue earlier but fixed it with writing simple .exe daemon which opens app and closes itself when app is closed for more than 2 seconds. It solved. But its not good patch because entry point of app was daemon, not app itself, so you cant associate file type with packed .exe. Video related:

https://user-images.githubusercontent.com/76493798/103104104-6a44bc80-4636-11eb-84e7-47b49d718cee.mp4

This is a complexing issue: it is a bad idea to make timeout for packer when app is closed - it will take 1 second more to pack app back. But on the other hand there are no other ideas how to fix. I invented only timeout. THERE IS an idea: Create in "Advanced options" flag called "The app has splash screen/launcher, add timeout for packer" and maybe a field to control how much seconds should it wait

[SerGreen]

Unpacker/repacker tool simply waits for the app's process to exit using .NET's method Process.WaitForExit(), so it seems that splash screen is a separate process from the main application.
With current implementation there's no option to add this 1 second delay - once target process is gone, it's gone, there's nothing for repacker to wait for. So, i see two options:

1. It has to detect child processes that target process spawns and wait for them too.
2. The way it waits for the target process to finish has to be changed.

If i understand correctly, you tried to get around this bug by making a deamon-program that launches the splash-screen-app, you packed this daemon together with splash-screen-app and made this deamon the target exe in Appacker. How did you check in your daemon if the splash-screen-app is closed or not? Maybe i should make repacker use the same method.

[assenizator]

here is my daemon for game "osu!" (also splash screen issue). Written on Windows CMD(BAT). Compiled as "Windowded, with hidden console"

@echo off
start osu!.exe
ping 127.0.0.1 -n 10 > nul  _// here I wait for osu to launch_
:LOOP
tasklist|findstr osu!.exe > nul     _// find process of app_
if %errorlevel%==1 goto ENDLOOP  _// if not running, end loop and close daemon_
ping 127.0.0.1 -n 2 > nul   _//wait for 1 second_
goto LOOP
:ENDLOOP
taskkill /F /IM osu!.exe  _//optional. to make 100% sure I also coded force quit_
exit

And this daemon is the entry point of app. appacker sees when daemon is closed and repacks the app then. Daemon is like a launcher.

P.S. as you see, apps splash screen launcher and the app itself are the same processes and executables in both cases: audacity and osu. Just after splash screen app relaunches (it takes much less than one second) but .NETs methods think it`s closed.

[SerGreen]

Hm, so you're searching for a process with a given name to check if it's alive. However, if there's multiple instances of "osu!", for example, from starting packed app several times, it wouldn't be able to differentiate between them and each repacker would wait for all instances of "osu!" to close.
Not a perfect solution, but it would work. I'll try to make it detect child processes first and see if it will work. And if it won't, then i'll implement the way you used.

[SerGreen]

Wait, can you please name a few more examples of splash screen apps that have this issue? Preferably of a small size so they pack/unpack faster.

I tried to replicate this with Audacity and osu! and wasn't able to. For me repacker process doesn't close after osu's or Audacity's splash screen and waits for the main app to close. Only when i try to launch another instance of Audacity/osu! repacker exits after the splash screen, because both apps don't allow creation of multiple instances if they detect that one is already running.

[assenizator]

I wasn`t able to reproduce the bug too. Everything worked with both apps without daemons I remembered! I had this problem becase used portable apps I made with using ThinApp. When I made apps portable with thinapp I received the same problem. Sorry for false bug report

https://user-images.githubusercontent.com/76493798/103147273-eb9a6d00-4764-11eb-877c-76c61f74dce4.mp4

But I also had a script that should run in osu!`s folder. Can you please give an advice how to run batch script when app launches? Without daemons because if I set daemon as launcher, packed app cannot be set as default for file type :))) It would be also cool if you add such a feature as "Start parameters". Something like "-nocache" that we type in shortcut after app's path

[SerGreen]

Haha, i'm glad the issue resolved itself. :)

As for "start parameters" - great suggestion. Also i think not only exe files should be allowed to be the 'main executable' for the package. exe, bat, cmd, lnk and sh - all should be selectable as a target file. I'll implement it in the next update soon.

I shall close this issue then.

[assenizator]

Yes! That`s what I wanted also - ability to make bats as entry points. Also would be nice to have two entry points - main - main exe, secondary - some script or daemon etc (just an idea) Thank you!!!!

[SerGreen]

@assenizator, just a heads up: features you suggested in this thread are already implemented in update v1.3.8 that i published just now.