X ウィンドウ システム

X ウィンドウ システム

twm、デフォルトの X11ウィンドウ マネージャー
原作者	アテナプロジェクト
開発者	X.Org財団
初回リリース	1984年6月; 40年前 ( 1984-06 )
安定版リリース	X11R7.7 [1] [2]  / 2012年6月6日
オペレーティング·システム	Unix、Unix ライク、MVS OpenVMS、DOS
プラットフォーム	クロスプラットフォーム
前任者	W ウィンドウ システム
タイプ	ウィンドウシステム
ライセンス	MITライセンス
Webサイト	詳しくはこちら

Xウィンドウ システム( X11、または単にX、様式化された𝕏 ) は、 Unix 系オペレーティング システムで一般的なビットマップ表示用のウィンドウ システムです。

Xは1984年にマサチューセッツ工科大学（MIT）のプロジェクトAthenaの一環として誕生しました。 ^[3] Xプロトコルは1987年9月からバージョン11（したがって「X11」）となっています。X.Org FoundationがXプロジェクトを主導しており、現在のリファレンス実装であるX.Org Serverは、MITライセンスおよび同様の許容ライセンスの下で無料のオープンソースソフトウェアとして利用できます。

X は、アーキテクチャに依存しないリモート グラフィカル ユーザー インターフェイスと入力デバイス機能を備えたシステムです。ネットワークターミナルを使用する各ユーザーは、任意のタイプのユーザー入力デバイスを使用してディスプレイと対話することができます。

標準ディストリビューションでは、シンプルながらも完全なディスプレイおよびインターフェイス ソリューションが提供されており、ほとんどのUnix 系オペレーティング システムおよびOpenVMS上でグラフィカル ユーザー インターフェイスを構築するための標準ツールキットとプロトコル スタックが提供され、他の多くの現代の汎用オペレーティング システムに移植されています。

X は、このような GUI 環境を構築するための基本的なフレームワーク、つまりプリミティブを提供します。つまり、ディスプレイ上にウィンドウを描画および移動し、マウス、キーボード、またはタッチスクリーンと対話します。X はユーザー インターフェイスを必須としません。個々のクライアント プログラムがこれを処理します。プログラムは、ユーザー インターフェイスなしで X のグラフィカル機能を使用できます。そのため、X ベースの環境の視覚的なスタイルは大きく異なり、プログラムによってインターフェイスがまったく異なる場合があります。

以前のほとんどの表示プロトコルとは異なり、X は、一体型または接続されたディスプレイ デバイス上ではなく、ネットワーク接続を介して使用されるように特別に設計されました。X はネットワーク透過性を備えています。つまり、ネットワーク (インターネットなど) 上のどこかのコンピュータで実行されている X プログラムは、ネットワーク上の別のコンピュータで実行されている X サーバー上にそのユーザー インターフェイスを表示できます。X サーバーは通常、Xクライアントにグラフィック リソースとキーボード/マウス イベントを提供します。つまり、X サーバーは通常、人間のユーザーの目の前のコンピュータ上で実行され、X クライアント アプリケーションはネットワーク上の任意の場所で実行され、ユーザーのコンピュータと通信してグラフィック コンテンツのレンダリングを要求し、キーボードやマウスなどの入力デバイスからイベントを受け取ります。

ユーザーの目の前にあるソフトウェアに「サーバー」という用語が使われているという事実は、自分のプログラムがリモート コンピュータ上のサービスのクライアントであることに慣れているユーザーにとっては、しばしば驚きです。ここでは、リモート データベースがローカル アプリケーションのリソースになるのではなく、ユーザーのグラフィック ディスプレイと入力デバイスが、ローカル X サーバーによって、ユーザーと通信するためにユーザーのグラフィックと入力デバイスを共有する必要があるローカルおよびリモートでホストされている X クライアント プログラムの両方に提供されるリソースになります。

X のネットワーク プロトコルは、X コマンド プリミティブに基づいています。このアプローチにより、別のコンピュータで実行されている可能性のある X クライアント アプリケーションによる 2D 操作と (GLX などの拡張機能を介して) 3D 操作の両方が、X サーバーのディスプレイ上で完全に高速化されます。たとえば、従来の OpenGL (バージョン 3.0 より前) では、多数のオブジェクトを含むディスプレイ リストをリモート X クライアント プログラムによって作成して X サーバーに完全に保存し、ネットワーク経由で単一の glCallList(which) を送信することで各オブジェクトをレンダリングできました。

X はオーディオのネイティブ サポートを提供していません。このニッチを埋めるためのプロジェクトがいくつか存在し、その中には透過的なネットワークサポートも提供するものがあります。

Xはクライアント・サーバーモデルを採用しており、Xサーバーはさまざまなクライアントプログラムと通信します。^[4]サーバーはグラフィカル出力（ウィンドウ）の要求を受け付け、ユーザー入力（キーボード、マウス、タッチスクリーンから）を返します。サーバーは次のような機能を持ちます。

• 別の表示システムのウィンドウに表示するアプリケーション
• PCのビデオ出力を制御するシステムプログラム
• 専用のハードウェア

このクライアント/サーバー用語 (ユーザーの端末がサーバーで、アプリケーションがクライアント) は、用語が逆になっているように見えるため、新しい X ユーザーを混乱させることがよくあります。しかし、X はエンドユーザーの観点ではなく、アプリケーションの観点を取り入れています。X はアプリケーションに表示および I/O サービスを提供するため、サーバーであり、アプリケーションはこれらのサービスを使用するため、クライアントです。

サーバーとクライアント間の通信プロトコルは、ネットワークを透過的に動作します。つまり、クライアントとサーバーは、同じマシン上で実行することも、異なるアーキテクチャやオペレーティング システムを搭載した異なるマシン上で実行することもできます。クライアントとサーバーは、暗号化されたネットワーク セッションを介して接続をトンネリングすることにより、インターネット経由で安全に通信することもできます。

Xクライアント自体は、他のクライアントにディスプレイサービスを提供することでXサーバーをエミュレートすることができます。これは「Xネスティング」として知られています。XnestやXephyrなどのオープンソースクライアントは、このようなXネスティングをサポートしています。^[5]

リモート マシン上で X クライアント アプリケーションを実行するには、ユーザーは次の操作を実行できます。

• ローカルマシンでターミナルウィンドウを開きます
• コマンドを使用してssh -Xリモートマシンに接続する
• ローカル表示/入力サービスを要求する（例：X転送を有効にしたSSHを使用していない場合）export DISPLAY=[user's machine]:0

リモート X クライアント アプリケーションは、ユーザーのローカル X サーバーに接続し、ユーザーに表示と入力を提供します。

あるいは、ローカル マシンは、リモート マシンに接続してクライアント アプリケーションを起動する小さなプログラムを実行する場合もあります。

リモート クライアントの実際の例は次のとおりです。

• リモート マシンをグラフィカルに管理する (リモート デスクトップの使用に似ていますが、単一のウィンドウを使用します)
• クライアント アプリケーションを使用して、多数の他の端末ユーザーと共同作業グループに参加する
• リモートマシンで計算集約型のシミュレーションを実行し、その結果をローカルデスクトップマシンに表示する
• 1 つのディスプレイ、キーボード、マウスで制御し、複数のマシンで同時にグラフィカル ソフトウェアを実行する

Xは主にプロトコルとグラフィックスプリミティブを定義しており、ボタン、メニュー、ウィンドウのタイトルバーのスタイルなど、アプリケーションのユーザーインターフェイスのデザインに関する仕様は意図的に含まれていません。^[6]代わりに、ウィンドウマネージャー、GUIウィジェットツールキット、デスクトップ環境、またはアプリケーション固有のグラフィカルユーザーインターフェイスなどのアプリケーションソフトウェアが、そのような詳細を定義し、提供します。その結果、典型的なXインターフェイスは存在せず、いくつかの異なるデスクトップ環境がユーザーの間で人気を博しています。

ウィンドウ マネージャーは、アプリケーション ウィンドウの配置と外観を制御します。これにより、デスクトップ インターフェイスが Microsoft Windows や Apple Macintosh を彷彿とさせるものになる場合もあれば (例: GNOME 2、KDE ​​Plasma、Xfce)、まったく異なるコントロール ( wmii や Ratpoison などのタイル ウィンドウ マネージャーなど) になる場合もあります。SugarやChromeOSなどの一部のインターフェイスは、デスクトップ メタファーを完全に排除し、特殊なアプリケーション向けにインターフェイスを簡素化しています。ウィンドウ マネージャーの洗練度と複雑さは、必要最低限​​のもの (例: X に付属する基本的なウィンドウ マネージャー twm や、非常に軽量なウィンドウ マネージャー evilwm) から、Enlightenment などのより包括的なデスクトップ環境、さらには POS などの垂直市場向けのアプリケーション固有のウィンドウ マネージャーにまで及びます。

多くのユーザーは、ウィンドウ マネージャーとは別に、一貫したユーザー インターフェイスを使用するさまざまなアプリケーションを含むデスクトップ環境で X を使用します。一般的なデスクトップ環境には、GNOME、KDE ​​Plasma、Xfce などがあります。UNIX 98 の標準環境は、Common Desktop Environment (CDE) です。freedesktop.org の取り組みは、デスクトップと、競争力のある X デスクトップに必要なコンポーネント間の相互運用性に取り組んでいます。

X.Org 実装は、X の標準的な実装です。ライセンスが寛容なため、フリーでオープン ソースのものからプロプライエタリなものまで、さまざまなバリエーションが登場しています。商用 Unix ベンダーは、リファレンス実装を採用して自社のハードウェアに適応させる傾向があり、通常はカスタマイズしてプロプライエタリな拡張機能を追加しています。

2004 年まで、XFree86 はフリーの Unix 系システムで最も一般的な X バリアントを提供していました。XFree86 は 386 互換 PC への X の移植として始まり、1990 年代末までに X における最大の技術革新の源となり、 X 開発の事実上の標準となりました。しかし、2004 年以降は、XFree86 のフォークである X.Org Server が主流になりました。

X は Unix と関連付けられるのが一般的ですが、X サーバーは他のグラフィカル環境にもネイティブに存在します。VMS Software Inc. の OpenVMS オペレーティング システムには、標準デスクトップ環境として、DECwindows として知られる Common Desktop Environment (CDE) を備えた X のバージョンが含まれています。Apple は当初、X11.app の形式で X を macOS に移植しましたが、XQuartz実装に取って代わられました。1990 年代の Apple の古いオペレーティング システムである System 7、Mac OS 8、9 のサードパーティ サーバーには、Apple の MacX と White Pine Software の eXodus が含まれていました。

Microsoft Windows には X のサポートが付属していませんが、 Cygwin/Xなどの無料のオープンソース ソフトウェアや、 Exceed、MKS X/Server、Reflection X、X-Win32、 Xmingなどの独自製品として、サードパーティによる実装が多数存在します。

X サーバーの Java 実装もあります。WeirdX は Swing 1.1 をサポートするすべてのプラットフォームで実行でき、ほとんどのブラウザー内でアプレットとして実行されます。Android X サーバーは、Android デバイスで実行されるオープン ソースの Java 実装です。

ネイティブのウィンドウ システムを備えたオペレーティング システムが X をさらにホストする場合、X システムは別のホスト ウィンドウで独自の通常のデスクトップを使用することも、ルートレスで実行することもできます。ルートレスで実行する場合、X デスクトップは非表示になり、ホスト ウィンドウ環境がホスト画面内でホストされている X ウィンドウのジオメトリと外観を管理します。

X端末は、 X サーバーのみを実行するシン クライアントです。このアーキテクチャは、多数のユーザーが同時に同じ大型コンピュータ サーバーを使用して、各ユーザーの X 端末のクライアントとしてアプリケーション プログラムを実行できるように、安価な端末パークを構築するために人気を博しました。この使用法は、MIT プロジェクトの当初の意図と非常に一致しています。

X 端末は、 X ディスプレイ マネージャ制御プロトコルを使用してネットワーク (ローカルブロードキャスト ドメイン)を探索し、クライアントとして許可されている利用可能なホストのリストを生成します。クライアント ホストの 1 つでX ディスプレイ マネージャを実行する必要があります。

X 端末とほとんどのシン クライアントの制限は、キーボード、マウス、ディスプレイ以外の入力や出力ができないことです。関連するすべてのデータはリモート サーバー上にのみ存在すると想定されており、X 端末のユーザーにはローカル周辺機器からデータを保存したり読み込んだりする方法がありません。

専用の（ハードウェア）X 端末は使用されなくなりました。Xサーバーを搭載したPCまたは最新のシン クライアントは、通常、同じ機能を同じかそれより低いコストで提供します。

Unix-Haters Handbook (1994) では、X の問題について 1 章を割いています。 ^{[7] Gajewska、Manasse、McCormack による} Why X Is Not Our Ideal Window System (1990) では、プロトコルの問題点が詳しく説明され、改善のための推奨事項が示されています。

X に設計ガイドラインがないため、インターフェースが大きく異なるものが多く、アプリケーション同士がうまく連携しないという問題がありました。クライアントの相互運用性に関する仕様であるInter-Client Communication Conventions Manual (ICCCM) は、正しく実装するのが難しいという評判があります。MotifやCDEなどの標準化の取り組みによっても問題は改善されませんでした。このため、ユーザーやプログラマーは苛立ちを募らせてきました。^[8]現在、グラフィックス プログラマーは、特定のデスクトップ環境または特定のウィジェット ツールキットに合わせてコーディングすることで、アプリケーションの外観と操作性、および通信の一貫性を確保するのが一般的です。これにより、ICCCM を直接扱う必要もなくなります。

X には、 NeWSのような X サーバー上のユーザー定義ストアド プロシージャのネイティブ サポートもありません。つまり、チューリング完全なスクリプト機能 がありません。そのため、さまざまなデスクトップ環境が独自の (通常は相互に互換性のない) 機能を提供する場合があります。

X 上に構築されたシステムには、右クリック、ダブルクリック、中央クリック、マウスオーバー、フォーカスの盗難など、障害のあるユーザーにとってコンピュータの利用を困難にするアクセシビリティの問題がある場合があります。一部の X11 クライアントは他のクライアントよりもアクセシビリティの問題にうまく対処しているため、アクセシビリティの問題を抱えるユーザーが X11 を使用できなくなることはありません。ただし、X11 にはアクセシビリティ標準やアクセシビリティ ガイドラインはありません。X11 標準化プロセスにはアクセシビリティに関するワーキング グループはありませんが、X 上でこれらの機能を提供するためのソフトウェア プロジェクトによってアクセシビリティのニーズが取り組まれています。

Orcaプロジェクトは、X Window Systemにアクセシビリティサポートを追加し、API（AT-SPI ^[9]）を実装します。これはGNOMEのATKと連携して、GNOME/GTK APIを使用してXプログラムにアクセシビリティ機能を実装できるようにします。^[10] KDEは、テキスト読み上げコンバータや画面拡大鏡を含む、別のアクセシビリティソフトウェアセットを提供します。^[11]他の主要なデスクトップ（LXDE、Xfce、Enlightenment）は、ATKとの互換性を実現しようとしています。

Xクライアントは、コードで明示的に指定されていない限り、通常、あるサーバーから切り離して別のサーバーに再接続することはできません（Emacsは、この機能を備えた数少ない一般的なプログラムの1つです）。そのため、セッション全体をXサーバー間で移動することは通常できません。ただし、Virtual Network Computing（VNC）、NX、Xpraなどのアプローチでは、異なるXサーバーから仮想セッションに到達できます（端末に関するGNU Screenと同様の方法）。また、他のアプリケーションやツールキットでは、関連する機能を提供しています。 ^[12] x11vnc（VNC :0ビューア）、Xpraのシャドウモード、NXのnxagentシャドウモードなどの回避策も存在し、現在のXサーバーの画面を利用できます。この機能により、実行中のアプリケーションのユーザーインターフェイス（マウス、キーボード、モニター）を、アプリケーションを停止して再起動することなく、ある場所から別の場所に切り替えることができます。

X サーバーとリモート X クライアント間のネットワーク トラフィックは、デフォルトでは暗号化されません。パケット スニファーを持つ攻撃者はこれを傍受し、ユーザーの画面に表示される内容や画面から送信される内容をすべて閲覧できるようになります。X トラフィックを暗号化する最も一般的な方法は、通信用にSecure Shell (SSH) トンネルを確立することです。

すべてのシンクライアントと同様に、ネットワーク経由で X を使用する場合、帯域幅の制限により、3D アニメーションや写真編集など、低遅延で画面の大部分を高速に更新する必要があるビットマップ集約型アプリケーションの使用が妨げられる可能性があります。比較的小さな非圧縮の640×480×24 ビット 30 fps ビデオ ストリーム (約 211 Mbit/s) でも、単一クライアントの 100 Mbit/s ネットワークの帯域幅を簡単に超えてしまいます。対照的に、X の最新バージョンには、通常、Mesaなどの拡張機能があり、ローカル プログラムのグラフィックスのローカル表示を最適化して、ネットワーク モデルをバイパスし、ビデオ カードを直接制御して、フルスクリーン ビデオ、レンダリングされた 3D アプリケーション、およびその他の同様のアプリケーションを使用できます。

Xの設計では、クライアントとサーバーが別々に動作する必要があり、デバイスの独立性とクライアントとサーバーの分離によってオーバーヘッドが発生します。オーバーヘッドのほとんどは、プロトコル自体ではなく、クライアントとサーバー間のネットワーク往復遅延時間（レイテンシ）によって発生します。パフォーマンスの問題に対する最善の解決策は、効率的なアプリケーション設計に依存します。 ^[13] Xに対する一般的な批判は、そのネットワーク機能がローカルでのみ使用される場合、過度に複雑になり、パフォーマンスが低下するというものです。

現代のX実装では、同一ホスト上での効率的な接続のためにUnixドメインソケットを使用しています。さらに、共有メモリ（MIT-SHM拡張経由）を使用して、クライアントとサーバーの通信を高速化することもできます。 ^[14]ただし、プログラマーは共有メモリ拡張を明示的にアクティブ化して使用する必要があります。また、古い実装との互換性を維持し、ローカル以外のXサーバーと通信するために、フォールバックパスを提供する必要があります。

X の代替や置き換えを書こうとした人もいます。 これまでの代替としては、SunのNeWSやNeXTのDisplay PostScript などがあります。どちらもPostScriptベースのシステムで、X にはなかったユーザー定義可能なディスプレイ側プロシージャをサポートしています。 現在の代替としては、次のものがあります。

• macOS（およびそのモバイル版であるiOS ）は、 Quartzと呼ばれるウィンドウシステムを実装しています。Apple ComputerがNeXTを買収し、NeXTSTEPを使用してMac OS Xを構築したとき、Display PostScriptをQuartzに置き換えました。Quartzの作者の1人であるMike Paquetteは、AppleがX11に含めたい機能をすべてサポートした場合、X11との類似性はほとんどなく、他のサーバーとの互換性もなくなるだろうと説明しました。^[15]
• Waylandは、Xの将来の代替として、複数のX.Org開発者によって開発されています。DRIを介してGPUハードウェアと直接連携します。Waylandは、ルートレスにできるWaylandコンポジターとしてXサーバーを実行できます。^{[16]このプロジェクトは2012年にバージョン1.0に到達しました。Androidと同様に、Waylandは}EGLベースです。
• MirはCanonical Ltd.のプロジェクトで、Waylandと同様の目標を持っていました。^[17] MirはARMチップセット（Androidデバイスドライバーとの互換性が目標とされていました）を使用するモバイルデバイスとx86デスクトップで動作するように設計されていました。Androidと同様に、Mir/UnityNextはEGLベースでした。Xクライアントアプリケーションとの下位互換性はXmirによって実現されました。このプロジェクトはその後、代替ディスプレイサーバーではなくWaylandコンポジターへと移行しました。^[18]
• 他の選択肢としては、ハードウェアを直接操作することでXのオーバーヘッドを回避しようとするものがあります。そのようなプロジェクトにはDirectFBがあります。^[19] Direct Rendering Infrastructure (DRI)は、フレームバッファへのカーネルレベルのインターフェイスを提供します。

グラフィカル サービスのネットワーク伝送を介して、X の「ネットワーク透過性」機能の機能形式を実現する追加の方法には、次のものがあります。

• 仮想ネットワークコンピューティング（VNC）は、圧縮されたビットマップをネットワーク経由で送信する非常に低レベルのシステムです。Unix実装にはXサーバーが含まれています。
• リモート デスクトップ プロトコル(RDP)。目的は VNC に似ていますが、Microsoft Windows で開発され、その後 Unix 系システム( NXなど) に移植されました。
• Citrix XenApp は、Microsoft Windows 用の X ライクなプロトコルおよびアプリケーション スタックです。
• Tarantellaは、Web ブラウザで使用するための Java ベースのリモート GUI クライアントを提供します。

X より前には、いくつかのビットマップ表示システムがありました。Xerox からはAlto ( 1973) とStar (1981)が登場しました。Apollo ComputerからはDisplay Manager (1981)が登場しました。AppleからはLisa (1983) とMacintosh (1984) が登場しました。Unixの世界では、 Andrew Project (1982) とRob PikeのBlit端末 (1982) がありました。

カーネギーメロン大学は、Xerox Alto 上に重なり合うウィンドウを表示し、リモートホスト (通常は Unix を実行する DEC VAX システム) にウィンドウ表示イベントの処理と、必要に応じてウィンドウの内容を更新する役割を担わせる、Alto Terminal と呼ばれるリモートアクセスアプリケーションを開発しました。

X は、1983 年以前のウィンドウ システムであるW (英語のアルファベットで X の前の文字)の後継としてその名前が付けられました。W はV オペレーティング システムで実行されました。W は、ターミナルとグラフィック ウィンドウをサポートするネットワーク プロトコルを使用し、サーバーがディスプレイ リストを維持していました。

X の元々のアイデアは、1984 年にJim Gettys ( Project Athena ) とBob Scheifler ( MIT コンピュータサイエンス研究所) の共同作業として MIT で生まれました。Scheifler は、Argus システムのデバッグに使用できる表示環境を必要としていました。Project Athena (すべての学生がコンピューティング リソースに簡単にアクセスできるようにするためのDEC、MIT およびIBMの共同プロジェクト) では、異機種混在の複数ベンダー システムをリンクするために、プラットフォームに依存しないグラフィック システムが必要でした。当時カーネギーメロン大学のAndrew プロジェクトで開発中だったウィンドウ システムはライセンスが提供されておらず、代替手段もありませんでした。

このプロジェクトでは、ローカル アプリケーションの実行とリモート リソースの呼び出しの両方が可能なプロトコルを作成することでこの問題を解決しました。1983 年半ば、WのUnix への最初の移植版は、V での 5 分の 1 の速度で実行されました。1984 年 5 月、Scheifler はW の同期 プロトコルを非同期プロトコルに、表示リストを即時モード グラフィックスに置き換えて、X バージョン 1 を作成しました。X は、真のハードウェア独立性とベンダー独立性を提供する最初のウィンドウ システム環境となりました。

Scheifler、Gettys、Ron Newman が作業に取り掛かり、X は急速に進歩しました。彼らは 1985 年 1 月にバージョン 6 をリリースしました。当時、最初のUltrixワークステーションのリリースを準備していた DEC は、X が間に合うように利用できる唯一のウィンドウ システムであると判断しました。DEC のエンジニアは、X6 をMicroVAX上の DEC の QVSS ディスプレイに移植しました。

1985 年の第 2 四半期に、X はDEC VAXstation -II/GPX で機能するためのカラーサポートを獲得し、バージョン 9 になりました。

ブラウン大学のグループがバージョン9をIBM RT PCに移植したが、RT上でアラインされていないデータを読み取る際に問題が発生したため、互換性のないプロトコル変更を余儀なくされ、1985年後半にバージョン10になった。X10R1は1985年にリリースされた。^[21] 1986年までには、外部の組織がXを求めるようになった。X10R2は1986年1月に、X10R3は1986年2月にリリースされた。MITはX6を一部の外部グループに有料でライセンスしていたが、この時点で、X10R3および将来のバージョンをMITライセンスとして知られるライセンスの下でライセンスすることを決定した。これは、Xをさらに普及させ、見返りとして、より多くのアプリケーションが利用可能になることを期待したためである。X10R3は広く普及した最初のバージョンとなり、DECとヒューレット・パッカードの両社がそれに基づく製品をリリースした。他のグループはX10をApollo、Sunワークステーション、さらにはIBM PC/ATに移植した。当時の Autofact トレード ショーでは、X の最初の商用アプリケーション (VAX 上で動作し、Jim Fulton と Jan Hardenbergh が移植した X サーバーが動作する PC にリモート表示される Cognition Inc. の機械的なコンピュータ支援エンジニアリング システム) のデモが行われました。X10 の最後のバージョンである X10R4 は、1986 年 12 月に登場しました。後に仮想ネットワーク コンピューティング(VNC) によってデスクトップの共有が可能になったのと同じように、X サーバーをリアルタイムのコラボレーション デバイスとして有効にする試みがなされました。そのような初期の取り組みの 1 つが、Philip J. Gust のSharedXツールでした。

X10 は興味深く強力な機能を提供したが、X プロトコルが広く普及する前に、ハードウェアに依存しない再設計が必要であることは明らかだった。しかし、MIT だけではそのような完全な再設計を行うためのリソースがなかった。たまたま、DEC の Western Software Laboratory は、経験豊富なチームとのプロジェクトが途切れていた。DEC WSL の Smokey Wallace と Jim Gettys は、DEC WSL が X11 を構築し、X9 および X10 と同じ条件で無料で利用できるようにすることを提案した。このプロセスは 1986 年 5 月に開始され、プロトコルは 8 月に完成した。ソフトウェアのアルファ テストは 1987 年 2 月に開始され、ベータ テストは 5 月に開始され、X11 は 1987 年 9 月 15 日にようやくリリースされた。^[22]

Scheifler が主導した X11 プロトコル設計は、USENET ニュースグループにブリッジされた初期のインターネット上の公開メーリング リストで広く議論されました。Gettys は、Phil Karlton と Susan Angebrandt が X11 サンプル サーバーの設計と実装を主導していた DEC の Systems Research Center からカリフォルニアに移り、WSL での X11 開発作業を主導しました。したがって、X は最初の非常に大規模な分散型フリー オープン ソース ソフトウェアプロジェクトの 1 つとなっています。

1980年代後半には、Xは「Athenaのこれまでで最も重要な成果」だったと、シムソン・ガーフィンケルは1989年に書いている。DECは、Xの開発だけでもMITへの寄付に見合う価値があると確信していたと伝えられている。ゲティスはVAXstation 2000の設計チームに加わり、DECがDECwindowsと呼んだXがVAXstation 2000上で動作することを保証し、同社は1,200人の従業員をXをUltrixとVMSの両方に移植するよう割り当てた。^{[23] [24]} 1987年、X11の成功が明らかになったため、MITはXの管理を手放したいと考えたが、1987年6月に9つのベンダーとの会議で、ベンダーはMITに、Xが市場で分裂しないようにするには中立的な立場が必要だと伝えた。 1988 年 1 月、MIT X コンソーシアムが非営利ベンダー グループとして結成され、Scheifler がディレクターを務め、商業的および教育的利益を含む中立的な雰囲気の中で X の将来の開発を指揮しました。

1988 年 1 月に Jim Fulton が、 1988 年 3 月にKeith Packard がシニア開発者として参加し、Jim はXlib、フォント、ウィンドウ マネージャ、ユーティリティに注力し、Keith はサーバーの再実装を担当しました。Donna Converse、Chris D. Peterson、Stephen Gildea は同年後半に参加し、MIT Project Athena の Ralph Swick と緊密に連携しながら、ツールキットとウィジェット セットに注力しました。MIT X コンソーシアムは X11 にいくつかの重要な改訂版をリリースし、最初の改訂版 (リリース 2 - X11R2) は 1988 年 2 月にリリースされました。Jay Hersh は 1991 年 1 月にスタッフに参加し、PEXと X113D の機能に取り組みました。その後すぐに Ralph Mor (PEX にも取り組んだ) と Dave Sternlicht が続きました。 1993年、MIT XコンソーシアムがMITから離脱する準備をしていたとき、R・ゲイリー・カットビル、カレブ・キースリー、デイビッド・ウィギンズがスタッフに加わった。^[25]

1993年、MIT Xコンソーシアムの後継としてXコンソーシアム社（非営利法人）が設立された。1994年5月16日にX11R6をリリース。1995年にはMotifツールキットとUnixシステム向け共通デスクトップ環境の開発を引き継いだ。Xコンソーシアムは1996年末に解散し、最終版のX11R6.3が発表され、開発における商業的影響力が高まった。^{[26] [27]}

1997 年 1 月、X コンソーシアムは、X の管理を、1996 年初頭にOpen Software FoundationとX/Openが合併して結成されたベンダー グループであるThe Open Groupに引き渡しました。

オープングループは1998年初めにX11R6.4をリリースした。議論を呼んだのは、オープングループがXの開発資金を確保しようとし、特にXFree86がXに大きく貢献していないと指摘したため、X11R6.4は従来の自由なライセンス条件から逸脱したためである。 ^{[28]新しい条件では、Xはもはや}フリーソフトウェアではなくなる。非商用利用の場合は無料だが、それ以外は有料となる。XFree86が分裂する準備が整ったように見えた後、^[29]オープングループは1998年9月にX11R6.4を従来のライセンスで再ライセンスした。 ^[30]オープングループの最後のリリースはX11R6.4パッチ3であった。

XFree86は、1991年にX11R5に同梱されていたIBM PC互換機用のX386サーバから1992年に誕生しました。このサーバはThomas RoellとMark W. Snitilyによって開発され、Snitily Graphics Consulting Services (SGCS)によってMIT Xコンソーシアムに寄贈されました。XFree86は、Xの1つの移植版から、X開発のデファクトスタンダードとして最も普及した実装へと進化しました。 ^[31]

1999 年 5 月、The Open Group は X.Org を設立しました。X.Org はバージョン X11R6.5.1 以降のリリースを監督しました。この時点で X の開発は停滞しており、^[32] X コンソーシアムが解散して以来、ほとんどの技術革新は XFree86 プロジェクトで行われました。^[33] 1999 年、XFree86 チームは、Linuxで XFree86 を使用することに関心があり、最も人気のある X バージョンであるというステータスに興味を持っていたさまざまなハードウェア企業^{[35] [検証に失敗]の奨励を受けて、X.Org に名誉会員 (無償)}として参加しました。[34]

2003年までにLinuxの人気が高まり（そしてXのインストールベースも増加）、X.Orgは活動を停止したままだった^[36]。活発な開発は主にXFree86内で行われた。しかし、XFree86内では相当な反対意見が生まれた。XFree86プロジェクトは、あまりにも大聖堂のような開発モデルという認識に苦しめられ、開発者はCVSコミットアクセスを得ることができず^{[37] [38] 、ベンダーは膨大な}パッチセットを維持する必要があった。^[39] 2003年3月、XFree86組織は、MIT Xコンソーシアムの終焉後にXFree86に参加したキース・パッカード氏を、かなりの悪感情を抱きながら追放した^{[40] [41] [42] 。}

X.OrgとXFree86は、Xの開発を適切に育成するための再編について議論を始めました。^{[43] [44] [45]}ジム・ゲティスは、少なくとも2000年以来、オープン開発モデルを強く推進してきました。^[46]ゲティス、パッカード、その他数名は、オープン開発によるXの効果的なガバナンスの要件について詳細に議論し始めました。

最後に、X11R6.4 のライセンス論争の反響として、XFree86 は 2004 年 2 月にバージョン 4.4 をリリースしましたが、これは X に依存する多くのプロジェクトが受け入れがたい、より制限の厳しいライセンスでした。^[47]ライセンスに追加された条項は、オリジナルのBSD ライセンスの宣伝条項に基づいており、Free Software FoundationとDebianはこれをGNU General Public Licenseと互換性がないと考えていました。^[48]他のグループは、これをオリジナルの X の精神に反するものと見なしました。たとえば、OpenBSDのTheo de Raadt は、ライセンス上の懸念を理由に XFree86 をフォークすると脅しました。^[49]ライセンスの問題と変更を加えることの難しさが相まって、多くの人がフォークの機が熟したと感じました。^[50]

2004 年初頭、X.Org および freedesktop.org のさまざまな人々がX.Org Foundationを結成し、Open Group はx.org ドメイン名の管理をこの財団に委ねました。これは X のガバナンスにおける根本的な変化でした。1988 年以来 (以前の X.Org を含む) X の管理はベンダー組織でしたが、財団はソフトウェア開発者によって主導され、外部の関与に依存するバザールモデル^[要出典]に基づくコミュニティ開発を採用しました。メンバーシップは個人に開放されており、企業メンバーシップはスポンサーシップの形で提供されます。現在、Hewlett-Packardなどの大手企業が^{[時期は? ]} X.Org Foundation をサポートしています。

Foundation は X の開発を監督する役割を担っており、コミュニティ メンバーの間で大まかな合意を得ることで、そのメリットに基づいて技術的な決定が下される。技術的な決定は取締役会によって行われるわけではない。この意味で、Foundation は技術的に非介入主義のGNOME Foundation を強くモデルにしている。Foundation は開発者を雇用していない。Foundation は 2004 年 4 月に X11R6.6 の変更をマージした XFree86 4.4RC2 をベースにした X11R6.7 (X.Org Server)をリリースした。Gettys と Packard は旧ライセンスの XFree86 の最終バージョンを採用し、オープン開発モデルを重視して GPL との互換性を維持することで、多くの旧 XFree86 開発者を参加させた。^[48]

X11 は 1990 年代に OpenGL サポートなどの拡張機能を導入しましたが、そのアーキテクチャは 10 年間基本的に変更されていませんでした。しかし、2000 年代初頭に、フォントアーキテクチャの「欠陥」、2D グラフィック システムの「常に拡張および/または置き換えが意図されていた」、遅延の問題など、長年にわたって表面化していたいくつかの問題を解決するために全面的に見直されました。^{[51] X11R6.8 は 2004 年 9 月にリリースされました。半透明ウィンドウやその他の高度な視覚効果、画面拡大鏡やサムネイル表示器の予備サポート、Sun の}Project Looking GlassやCroquet プロジェクト などの 3D 没入型表示システムとの統合機能など、重要な新機能が追加されました。合成ウィンドウ マネージャーと呼ばれる外部アプリケーションは、視覚的な外観のポリシーを提供します。

2005年12月21日、^[52] X.Orgはレガシーユーザー向けのモノリシックソースツリーであるX11R6.9と、同じソースコードを独立したモジュールに分割し、それぞれを別々のプロジェクトで保守できるX11R7.0をリリースした。^[53] Foundationは7.0から約4か月後の2006年5月22日に、大幅な機能改善を加えたX11R7.1をリリースした。^[54]

XFree86の開発はさらに数年間続けられ、2008年12月15日に4.8.0がリリースされました。^[55]

システムの正式名称はマニュアルページにはX、Xウィンドウシステム、Xバージョン11、Xウィンドウシステムバージョン11、またはX11と記載されています。^[56]

「X-Windows」という用語は（後にリリースされた「Microsoft Windows」のような）公式には承認されていない。Xコンソーシアムのリリースマネージャであるマット・ランドーは1993年に「業界紙が何度も形式を誤用しているにもかかわらず、「X Windows」や「X Window」というものは存在しない」と述べている^[57]。 しかし、Xの歴史の初期から非公式にはよく使われており^[58]、たとえばUnix-Haters Handbookでは挑発的な効果を狙って意図的に使用されてきた。^[7]

X ウィンドウ システムでは、一般的な用法と比較して、いくつかの用語、特に「ディスプレイ」と「画面」が微妙に異なります。便宜上、そのサブセットを次に示します。

デバイス

コンピュータのグラフィック カードやコンピュータのマザーボードの統合グラフィック チップセットなどのグラフィック デバイス。

モニター

CRTやフラット スクリーン コンピュータ ディスプレイなどの物理デバイス。

画面

グラフィックスをレンダリングできる領域。VNCのようにソフトウェアのみでシステム メモリにレンダリングするか、グラフィックス デバイス内にレンダリングします。グラフィックス デバイスの中には、複数の画面に同時にレンダリングできるものもあり、同時に表示することも、交換して表示することもできます。交換可能な画面は、多くの場合、概念的に互いに左右になるように設定され、マウス ポインターがモニターの端に達すると、画面が切り替わります。

仮想スクリーン

この用語には 2 つの異なる意味が関連付けられています。

• モニターが現在表示している解像度よりも高い解像度で実行されている画面上でモニターをパンできるようにする技術。
• ウィンドウの位置情報を画面よりも大きな座標系で維持し、ユーザーに応じてウィンドウを移動するだけでパンできるようにすることで、ウィンドウ マネージャーによってシミュレートされる効果。

画面

画面の集合。多くの場合、複数のモニターを含み、一般的にマウスでポインターを画面内の任意の位置に移動できるように構成されています。Linuxベースのワークステーションは通常、複数のディスプレイを持つことができ、ユーザーは Ctrl + Alt +ファンクション キーなどの特殊なキーボードの組み合わせを使用して、すべてのモニターを同時に切り替えて、1 つのディスプレイの画面から別のディスプレイの画面に表示することができます。

「ディスプレイ」という用語は、より専門的な用語である「 Zaphod ディスプレイ」と混同しないでください。後者は、1 台のコンピューターを使用する複数のユーザーが、それぞれ独立したディスプレイ、マウス、およびキーボードのセットを使用できる珍しい構成で、まるで別々のコンピューターを使用しているかのように使用できますが、1 台あたりのコストは低くなります。

将来のバージョンの見通しについては、X.orgのウェブサイトで次のように述べられています。^[76]

X.Org は、X Window System ソフトウェア コンポーネントの開発とリリースを継続します。

これらは、X Window System 全体の「katamari」リリース スケジュールを待たずに、各コンポーネントの準備が整うと個別にリリースされます。ダウンロードについては、個々の X.Org リリース ディレクトリを参照してください。含まれる変更の詳細については、xorg-announce アーカイブまたは git リポジトリを参照してください。

X11R7.8 ロールアップ katamari リリースのリリース計画は提案されていません。

• ビットストリーム スピードフォント
• カイロ（グラフィック）
• DESQview/X
• ダイレクトFB
• 一般的なグラフィックインターフェース
• グラフィカルユーザーインターフェースの歴史
• Unixコマンドのリスト
• マイクロウィンドウ（Nano-X）
• rio – Plan 9のウィンドウ システム
• SVGAライブラリ
• バーチャルGL
• エックス/ジェム
• X11 の色名
• Xgl
• Xマーク

ウィキメディア・コモンズには、 X Window Systemに関連するメディアがあります。

Wikibooks には、 「X11 ガイド」というトピックに関する書籍があります。

• 公式サイト