Folgendes bedeutet dies für das X-Windows-System.
X-Windows bietet auf der untersten Ebene eine Möglichkeit, Bildschirmbereiche zu manipulieren, die als „Fenster“ bezeichnet werden. Es bietet auch eine Möglichkeit, Ereignisse zu empfangen, die innerhalb von Windows passieren.
Aber X-Windows sagt nichts über Titelleisten, Menüs, Bildlaufleisten oder ähnliches aus. Es sagt auch nichts über die Regeln aus, nach denen eine bestimmte Anwendung ihr Fenster den ganzen Bildschirm einnehmen lassen kann, oder wann ein Fenster aus dem Bildschirm verschoben werden muss. Es bietet eine Möglichkeit für eine Anwendung, andere Anwendungen zu zwingen, sie um Erlaubnis zu fragen, bevor sie Dinge mit Fenstern der obersten Ebene tun, stellt jedoch keine solche Anwendung als Teil des Basisservers bereit.
Bei X-Windows dreht sich alles um Mechanismen, nicht um Richtlinien.
Die Richtlinie wird vom Widget-Toolkit, vom Fenstermanager und von anderen Dingen bereitgestellt, die dem System später hinzugefügt werden. Viele Widget-Toolkits verwenden beispielsweise einen Satz überlappender Unterfenster für Bildlaufleisten und fragen nach Mausereignissen für diese Unterfenster, damit sie Klick- und Ziehvorgänge erkennen und die Unterfenster entsprechend reagieren können.
Aus diesem Grund können beispielsweise GNOME und KDE auf dem gleichen Bildschirm miteinander auskommen und warum wirklich alte X-Windows-Programme, die nichts über Panels oder Desktops wissen, auf modernen Systemen immer noch einwandfrei funktionieren.
In Bezug auf *nix-Betriebssysteme ist die allgemeine Idee, dass das Sicherheitssystem vom Kernel und das Autorisierungssystem vom Userspace implementiert wird.
Die allmächtigen Root- und Suid-Binärdateien, die so viele Menschen (ob zu Recht oder aus anderen Gründen) verspotten, sind für effektive Trennungen notwendig. Es ist möglich, den Authentifizierungsmechanismus vollständig auszutauschen, während die Sicherheit intakt bleibt (ssh tut dies, weshalb es unter Windows undokumentierte APIs verwendet).