Just in case anyone is curious: when a program hasn't told windows about any internal updates for a certain period of time, it thinks the process is stuck in some loop forever so it would be easier for the user to just kill it and open it again. Same goes for Android ANR (Application Not Responding) errors - the app might still be up and running but because it's not responding to the outside world, there is a good chance that it froze and won't be able to continue on its own. So technically, the fault isn't entirely on the Windows side - blame the developer who thinks it's a good idea not to provide any status output while performing performance-heavy tasks. Even displaying a percentage can already be enough for Windows to know whether or not the app is still up and running.
TLDR: If the app contains bad code so it doesn't signal "Hey, I am still here" every once in a while, Windows simply takes a good guess and tells you the app is probably stuck. When it's stuck, it's likely time to say goodbye (or, like I said, bad code which Windows can't know about hence passing you the trigger either way).
Man why did I even type this down, no one's gonna read it anyways.
EDIT2: 3 people came up with an idea asking me why Windows can't just "ask" the app if it's still alive. The problem here is that even if this became a standard, the app still wouldn't be able to reply to it - until it has finished its long operation. (too late then). This is because the app's thread which is communicating with Windows is busy doing its work. Best practice here is to either use another thread for the long operation or split it up in small pieces so the thread gets a chance to say "hi" to Windows. So basically, if you wrote good code, it would't be necessary, but with bad code (running on the main thread) it's not possible haha. I really wanted to keep the comment as simple as possible but with all the unexpected interest in how computers work I feel forced to elaborate. Man this comment is getting bloatet rn
EDIT1: Ok so apparently a few people have reddit now that it reached 560 points in 3hrs - this is probably the biggest reach a comment of mine will ever achieve along with the most hate I will ever get for a comment:
To all the people who tell me that my comment is inherently wrong because I didn't fit the curriculum of 5 years of computer science classes into a single reddit comment: If I directed the explanation towards CS majors, I wouldn't have posted it because you guys already know your shit. Using metaphors and simplifying things is the only way to teach non-CS people about how computers work. They don't want to know if the operations block the main queue, hence making the application so unable to post new UI updates that even UI events posted prior to the operation won't reach the OS. No one wants to know, except for the few people who have to avoid coding it this way.
kurtfan182 on June 4th, 2017 at 14:53 UTC »
Sadly in my case it's usually the user not windows wanting to immediately kill it.
skandr75 on June 4th, 2017 at 15:01 UTC »
"Windows is checking for a solution to the problem" could be a bit morbid in this context...
Reiszecke on June 4th, 2017 at 16:08 UTC »
Just in case anyone is curious: when a program hasn't told windows about any internal updates for a certain period of time, it thinks the process is stuck in some loop forever so it would be easier for the user to just kill it and open it again. Same goes for Android ANR (Application Not Responding) errors - the app might still be up and running but because it's not responding to the outside world, there is a good chance that it froze and won't be able to continue on its own. So technically, the fault isn't entirely on the Windows side - blame the developer who thinks it's a good idea not to provide any status output while performing performance-heavy tasks. Even displaying a percentage can already be enough for Windows to know whether or not the app is still up and running.
TLDR: If the app contains bad code so it doesn't signal "Hey, I am still here" every once in a while, Windows simply takes a good guess and tells you the app is probably stuck. When it's stuck, it's likely time to say goodbye (or, like I said, bad code which Windows can't know about hence passing you the trigger either way).
Man why did I even type this down, no one's gonna read it anyways.
EDIT2: 3 people came up with an idea asking me why Windows can't just "ask" the app if it's still alive. The problem here is that even if this became a standard, the app still wouldn't be able to reply to it - until it has finished its long operation. (too late then). This is because the app's thread which is communicating with Windows is busy doing its work. Best practice here is to either use another thread for the long operation or split it up in small pieces so the thread gets a chance to say "hi" to Windows. So basically, if you wrote good code, it would't be necessary, but with bad code (running on the main thread) it's not possible haha. I really wanted to keep the comment as simple as possible but with all the unexpected interest in how computers work I feel forced to elaborate. Man this comment is getting bloatet rn
EDIT1: Ok so apparently a few people have reddit now that it reached 560 points in 3hrs - this is probably the biggest reach a comment of mine will ever achieve along with the most hate I will ever get for a comment:
To all the people who tell me that my comment is inherently wrong because I didn't fit the curriculum of 5 years of computer science classes into a single reddit comment: If I directed the explanation towards CS majors, I wouldn't have posted it because you guys already know your shit. Using metaphors and simplifying things is the only way to teach non-CS people about how computers work. They don't want to know if the operations block the main queue, hence making the application so unable to post new UI updates that even UI events posted prior to the operation won't reach the OS. No one wants to know, except for the few people who have to avoid coding it this way.