Re: Réécrire l'histoire

C'est exactement pareil avec Win32, Windows Forms, WPF...

Exemple avec WPF :

 internal class Startup
 {
 [STAThread]
 public static void Main(string[] args)
 {
 var application = new App();
 application.InitializeComponent();
 application.Run();
 }
 }

Et là on a déjà :
- Un thread de rendu WPF (interne)
- Un thread principale pour l'application, dans lequel s'exécute la boucle des messages.

Win32 et Windows Forms, c'est exactement pareil, au moins sur le fond.
(et idem, application.Run() ne rend pas la main avant la fin du programme)

Un traitement long, si l'application est bien faite, se fera dans un thread dédié avec à la fin un appel (asynchrone ou non) au dispatcher WPF pour mettre à jour les éléments graphiques (qui exécute le code qu'on lui donne sur le thread principale).

Si l'application met du temps à s'afficher, on peut lui mettre un SplashScreen en deux clics (ça arrive si la machine est vielle ou sur un cold-boot de l'application, surtout).

Mais c'est pas l'OS qui va forcer une application à être bien écrite.

Depuis Windows Vista et DWM, une application qui ne répond pas reçoit :
- Forcément un contour de la fenêtre principale qui permet de la fermer (en fait, ça existait déjà sous XP - au moins)
- Pouvoir choisir à partir de la fenêtre si on veut la fermer tout de suite ou attendre
- Un titre de fenêtre auquel on rajoute "(Ne répond pas)" (depuis XP, en fait)
- Un effet graphique qui blanchi à 50% la zone cliente de la fenêtre.

Mais c'est tout.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)