4 ms·
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
by 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 agoMost 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.