WM_SAVE_YOURSELF
Le premier essai d'ICCCM en matière de gestion de session : le gestionnaire de fenêtres demande à un programme de noter comment le relancer, et le programme répond en réécrivant WM_COMMAND — un protocole déclaré obsolète en 1994 qui n'est jamais tout à fait mort.
ICCCM 1.0, livré avec X11R4 en 1989, n'avait aucun gestionnaire de session sur lequel s'appuyer ; toute la gestion de session devait donc tenir dans un seul message. Un programme listait WM_SAVE_YOURSELF dans WM_PROTOCOLS ; au moment de la déconnexion ou d'un point de contrôle, le gestionnaire de fenêtres envoyait un ClientMessage portant cet atome, et le programme devait répondre en réécrivant WM_COMMAND avec une ligne de commande recréant son état courant — ou la même qu'avant s'il n'avait rien à sauvegarder, ou une ligne vide s'il ne voulait pas être relancé. L'écriture valait accusé de réception : le gestionnaire de fenêtres attendait un PropertyNotify sur WM_COMMAND et, passé un délai, considérait que quiconque n'avait pas répondu était bloqué. Pendant ce temps, le programme n'avait pas le droit de parler à l'utilisateur ; une question sur des modifications non enregistrées était expressément interdite.
Les défauts sont vite apparus. Le programme ne pouvait pas distinguer un point de contrôle de la fin de la session, ne pouvait pas refuser, et la réponse vivait sur une fenêtre, ce qui donnait une commande par fenêtre plutôt que par programme. ICCCM 2.0 a déplacé toute la procédure vers une annexe de conventions obsolètes en 1994 et renvoyé à XSMP. Elle n'a pourtant pas disparu : smproxy l'envoie toujours aux programmes sans XSMP, ksmserver de KDE intègre le même procédé sous le nom de legacy session management, Tk l'expose sous la forme wm protocol . WM_SAVE_YOURSELF, et Emacs y répond avec XSetCommand — mais seulement quand il ne parle pas déjà à un gestionnaire de session, car un programme qui gère les deux serait sinon démarré deux fois à la connexion suivante.