4 ms·

Providing an option to the average user that will immediately kill an application and lose all unsaved data seems like a terrible idea. Are apps so prone to fre

by r1ch 3y ago

Providing an option to the average user that will immediately kill an application and lose all unsaved data seems like a terrible idea. Are apps so prone to freezing that they require terminating on a daily basis? I can't even remember the last time I had to End Task a desktop application.

brundolf 3y ago
You're probably using a high-end machine, many people use sub-$500 Windows laptops
mannykannot 3y ago
If these events are as uncommon as you think they are - and I am certainly not dealing with them on anything close to a daily basis - then this option is not likely to be used often, and then usually only when unsaved data loss is already inevitable.
toyg 3y ago
Sadly, freezing remains a fairly common situation under Windows, even with apps built entirely with MS tech. - Your app is network-heavy and the internet goes down -> freezing - Your app accepts uploaded files and the user tries to load something bigger than the app would expect -> freezing - Your app is supposed to perform some sort of calculation with terrible code provided by user -> freezing - Your app interacts with some sort of device (printers, scanners...), and a cable is yanked or the firmware is dubious -> freezing - Your app runs smoothly on developers' desktops with 16GB of RAM and all the latest patches, but actual users deploy it on a 4GB laptop the company bought in 2010 (because "it does email and Word just fine") -> freezing Etc etc Tbf, over 25 years we've gone from "bad situation on Windows requires a hard reboot" to "bad situation on Windows requires forced killing", and it's more difficult for apps to step on each other's DLL-shaped toes. But yes, freezes and crashes continue to be an everyday situation for many - which is why the first thing Office applications do, when starting, is to check for possible leftovers of a crash.
- r1ch 3y ago
  Most freezing situations are blocking the UI thread, which should already be handled by the "Not Responding" dialog. I can't think of many cases where you'd want to terminate an application that isn't frozen instead of exiting it normally.
  - toyg 3y ago
    > should already be handled by the "Not Responding" dialog "Should" being the keyword there. That dialog comes up fairly rarely in my experience, and only after waiting a very, very long time.
vb6sp6 3y ago
[dead]
xnorswap 3y ago
As a Visual Studio user, I have to force-kill it all the time. I've come to loathe the VS experience; I used to love it but it really feels like it's been left behind to rot.
vitorgrs 3y ago
Windows development guideline states that the app should always be ready for that. That's because the close button on Modern Apps, unlike Win32 old apps, always did force quitting. That's why with Windows Modern apps, there isn't the popup for "Do you want to save the changes?". Because the guideline states that the app should always save changes automatically (Since 2013 there's proper APIs to store these data, and it even sync with your other PCs).

by r1ch 3y ago

brundolf 3y ago

You're probably using a high-end machine, many people use sub-$500 Windows laptops

mannykannot 3y ago

If these events are as uncommon as you think they are - and I am certainly not dealing with them on anything close to a daily basis - then this option is not likely to be used often, and then usually only when unsaved data loss is already inevitable.

toyg 3y ago

Sadly, freezing remains a fairly common situation under Windows, even with apps built entirely with MS tech. - Your app is network-heavy and the internet goes down -> freezing - Your app accepts uploaded files and the user tries to load something bigger than the app would expect -> freezing - Your app is supposed to perform some sort of calculation with terrible code provided by user -> freezing - Your app interacts with some sort of device (printers, scanners...), and a cable is yanked or the firmware is dubious -> freezing - Your app runs smoothly on developers' desktops with 16GB of RAM and all the latest patches, but actual users deploy it on a 4GB laptop the company bought in 2010 (because "it does email and Word just fine") -> freezing Etc etc Tbf, over 25 years we've gone from "bad situation on Windows requires a hard reboot" to "bad situation on Windows requires forced killing", and it's more difficult for apps to step on each other's DLL-shaped toes. But yes, freezes and crashes continue to be an everyday situation for many - which is why the first thing Office applications do, when starting, is to check for possible leftovers of a crash.

r1ch 3y ago
Most freezing situations are blocking the UI thread, which should already be handled by the "Not Responding" dialog. I can't think of many cases where you'd want to terminate an application that isn't frozen instead of exiting it normally.
- toyg 3y ago
  > should already be handled by the "Not Responding" dialog "Should" being the keyword there. That dialog comes up fairly rarely in my experience, and only after waiting a very, very long time.

vb6sp6 3y ago

[dead]

xnorswap 3y ago

As a Visual Studio user, I have to force-kill it all the time. I've come to loathe the VS experience; I used to love it but it really feels like it's been left behind to rot.

vitorgrs 3y ago

Windows development guideline states that the app should always be ready for that. That's because the close button on Modern Apps, unlike Win32 old apps, always did force quitting. That's why with Windows Modern apps, there isn't the popup for "Do you want to save the changes?". Because the guideline states that the app should always save changes automatically (Since 2013 there's proper APIs to store these data, and it even sync with your other PCs).