I guess it depends also how developers get forced upon them.
Windows NT family branch has had asynchronous and event based support since the early days, being heavily multi-threaded, yet not many cared to use it properly.
To the point that Microsoft pushed for an async only world with WinRT(UWP) and it got mixed up responses. Now with Project Reunion going forward it remains to be seen how async will faire.
However at least .NET, C++20, Rust and JS now have full asynchronous support, as the main Windows desktop stacks.
On Android, Google only had AsyncTask, with multiple caveats how to use it properly, then came the fashion with RxJava, Java executors, now it seems Kotlin co-routines are the future, assuming a #KotlinFirst world, with C++20 on the NDK.
On the Apple side we have GCD still as the main workhorse.
As for the other OSes, I guess they are pretty much still the same as they always have been, so that leaves language runtimes for better async and event-based programming.
Win32 UI libs however were heavily optimized asynchronous systems based on callbacks from the OS, where you avoided storing bitmaps up-front or anything like that, except as optional caching.
This is what enabled fast drawing despite very primitive drawing system (essentially GDI would get you a pointer to a window of VRAM, the origin of various fun graphical bugs people remember from windows, like dragging broken dialog boxes around that leave a "trace").
WinNT OTOH, has realized async support across the whole I/O stack, essentially finishing the never-finished concurrent QIO of Digital's VMS (VMS afaik to this day haven't got fully working concurrent QIO - the API is there, but if you actually enable concurrent operation too many applications die), and has a bunch of undocumented async mechanisms as well (including mostly free-form asynchronous calls from kernel to user - again a VMS invention - which are in many ways similar to POSIX signals except you aren't limited to a small table of events to attach handlers to, and they support concurrency by default)
Windows NT family branch has had asynchronous and event based support since the early days, being heavily multi-threaded, yet not many cared to use it properly.
To the point that Microsoft pushed for an async only world with WinRT(UWP) and it got mixed up responses. Now with Project Reunion going forward it remains to be seen how async will faire.
However at least .NET, C++20, Rust and JS now have full asynchronous support, as the main Windows desktop stacks.
On Android, Google only had AsyncTask, with multiple caveats how to use it properly, then came the fashion with RxJava, Java executors, now it seems Kotlin co-routines are the future, assuming a #KotlinFirst world, with C++20 on the NDK.
On the Apple side we have GCD still as the main workhorse.
As for the other OSes, I guess they are pretty much still the same as they always have been, so that leaves language runtimes for better async and event-based programming.