thumb|KDE 4.x thumb|Xfce 4.6
X Window System（エックスウィンドウシステム、別称：「X11」・「X」など→名称については後述）とは、ビットマップディスプレイ上でウィンドウシステムを提供する表示プロトコルである。リファレンス実装として X.Org Server があり、標準ツールキットとプロトコルを提供し、Unix系オペレーティングシステム (OS) やOpenVMSなどでのグラフィカルユーザインタフェース (GUI) を構築するのに使われる。他の多くの汎用OSにも移植されている。
概要 Xは1984年、マサチューセッツ工科大学が開発した。現在のバージョンであるX11は1987年9月に登場した。現在はX.Org FoundationがXプロジェクトを主導している。リファレンス実装であるversion 11 release 7.3（2007年9月6日）は自由ソフトウェアとしてMITライセンスおよび類似のライセンスで提供している。
Xは、GUI環境構築のための基本フレームワークやプリミティブを提供する。ウィンドウを画面上に描画したり、移動させたり、マウスやキーボードを使ってやり取りする。Xはユーザインタフェースを規定しない。それは、個々のクライアントプログラムの管理下にある。そのため、Xに基づいた環境の見た目は様々である。プログラムごとにインタフェースは異なる。XはOSの中核 (kernel) には含まれない。アプリケーション層構築の基盤となっている。
それ以前の表示プロトコルとは異なり、Xは表示機器に付属した（あるいは統合された）システムではない。ネットワークコネクションを通して使うことを意図して設計している。X の特徴は、Xプロトコルという、画面表示や入出力時に利用するプロトコルがネットワーク透過だということである。そのため、手元のマシンの表示と遠隔のマシンとの表示で表示方法に差がない。このことは、ネットワークを利用したUNIXワークステーション群でGUI表示を行うのに便利であり、UNIXマシンの普及と共にXも普及していった。
アーキテクチャ
Xはクライアントサーバモデルに基づき、Xサーバが各種「クライアント」プログラムと通信する。サーバはグラフィカルな出力要求を受け付け、（マウス、キーボード、タッチパネルなどからの）ユーザー入力をクライアントに送信する。Xプロトコル自身はハードウェア環境に依存しない。そのため、X Window Systemが動作するマシンはUNIXマシンだけとは限らない。Windows上でXサーバを動作させる、通称PC Xサーバというソフトウェアや、ハードウェア（ファームウエア）でXプロトコルを処理する、通称X端末も存在する。特にX端末は、UNIXマシンが非常に高価な時代に、GUIだけを安価に表示、処理できる機器として良く利用された。
このクライアントサーバという用語（ユーザーの端末、サーバ、クライアントであるアプリケーション）は、しばしば新規のXユーザーを混乱させる。なぜなら用語が逆に使われているように見えるからである。しかしXはエンドユーザーではなく、むしろアプリケーションからみた考え方をしている。XはディスプレイやI/Oサービスをアプリケーションに提供している。そのためサーバである。アプリケーションはこれらのサービスを利用している。そのためアプリケーションはクライアントである。
thumb|この例では、Xサーバがキーボードとマウスの入力を受け取り、画面に表示する。ウェブブラウザと端末エミュレータがローカルに動作しており、system updaterがリモートのサーバ上で動作しているが、それを制御しているのはローカルのマシンである。リモート・アプリケーションはローカルに動作するのと何ら変わりなく動作することに注意されたい。
サーバとクライアント間の通信プロトコルは、ネットワーク透過性を備える。クライアントとサーバは同じマシン上でも動作するし、別々のマシン上でも動作する。双方のアーキテクチャやOSが違っていても構わない。クライアントとサーバ間の通信は、インターネット上でもトンネリングによって安全に行うことができる。
Xクライアント自体がXサーバを内包し、複数のクライアントに対してサーバとして動作する構成も可能である。これを「Xネスティング」と呼ぶ。XnestやXephyrは、Xネスティングをサポートしたオープンソースのクライアントである。
リモートのクライアントプログラムをローカルなサーバで表示するには、端末エミュレータのウィンドウを開き、telnetあるいはsshでリモートのクライアントアプリケーション（あるいはシェル）を起動し、入出力先をローカルに指定してクライアントを起動する（すなわち、[ユーザーのマシン] をリモートのマシン上で設定する）。クライアントアプリケーションはローカルサーバと接続され、ローカルマシンのディスプレイと入力機器を使って動作する。またローカルマシンは、リモートマシンに接続しクライアントアプリケーションを起動する小さなプログラムを実行することもできる。
リモートクライアントの実用的な利用例として、次のようなものがある。 リモートマシンの管理をグラフィカルに行う。 リモートマシンで計算量の多いシミュレーションを実行し、ローカルなデスクトップマシンでその結果を表示する。 複数のマシンでグラフィカルなソフトウェアを同時に実行し、その表示を1つのマシンで行い、1人のユーザーが全体を操作する。
設計思想 1984年、Bob ScheiflerとJim GettysはXの基本原則を以下のように定めたRobert W. Scheifler and James Gettys: X Window System: Core and extension protocols: X version 11, releases 6 and 6.1, Digital Press 1996, 。 実際のアプリケーションでどうしても必要という場合以外は、新機能を追加するな。 機構が何でないのかを定義することは、何であるのかを定義するのと同じように重要である。あらゆる要求に答える必要はない。むしろ、互換性を維持した状態で拡張可能にしておけ。 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシである。 問題が完全に把握できないときは、解決策も提供しないのが最善の方法である。 10%の作業で望みの90%の効果が得られるときには、その解法を使え。 複雑さは可能な限り分離せよ。 方針よりも機構を提供せよ。特にユーザインタフェースについての方針はクライアント側に任せておけ。
先頭の原則は、X11の設計時に「具体的アプリケーションがそれを必要としていることを知っている場合に限って、新たな機能を追加せよ」に修正された。
Xはだいたいにおいてこれらの原則に従ってきた。参考実装は拡張性と改良を視野に入れて開発されており、1987年当時のプロトコルとほぼ完全な互換性を維持している。
ユーザインタフェース Xは意図的にアプリケーションのユーザインタフェースの仕様を含まないようにしている。ボタン、メニュー、ウィンドウのタイトルバーなどである。代わりに、ウィンドウマネージャ、GUIウィジェット・ツールキット、デスクトップ環境、アプリケーション固有のグラフィカルユーザインタフェースなどがそのような詳細を定義し提供している。そのため、典型的なXのインタフェースを示すことは不可能である。
ウィンドウマネージャは、アプリケーションのウィンドウの位置と見た目を制御する。そのインタフェースはWindowsやMacintoshと似ているものもあるし（GNOMEのMetacity、KDEのKWin、XfceのXfwmなど）、全く異なるものもある。実用本位のウィンドウマネージャもあれば（twmなど）、デスクトップ環境に近い機能を持つものもある（Enlightenmentなど）。
多くのユーザーはデスクトップ環境を通してXを利用している。デスクトップ環境にはウィンドウマネージャ、各種アプリケーションなどが一貫したインタフェースで含まれている。GNOME、KDE、Xfceなどが主なデスクトップ環境である。freedesktop.orgはデスクトップ環境間の相互運用性を高めることを目的としている。
Xサーバは、グラフィカルなデスクトップでのキーボードとマウス操作を管理している。そのため、一部のショートカットキーはXサーバと結び付けられている。Control-Alt-Backspaceは通常、現在動作しているXセッションを終了させる。Control-Altとファンクションキーの組合せは、一般に仮想コンソールに連携している。ただし、これは個々のXサーバの実装の詳細であり、常に同じとは限らない。例えば、WindowsやMacintoshで動作するXサーバでは、そのようなショートカットキーは提供されない。
実装 X.Org Serverは、リファレンス実装としてX Window Systemの正式な実装として扱われる。自由ソフトウェア、プロプライエタリソフトウェアの実装が複数存在する。商用UNIXベンダーはリファレンス実装を採用し、それを自身のハードウェアに合わせて修正し、独自の拡張を様々に凝らすことが多い。
2004年まで、XFree86がフリーなUnix系システムでのX実装の事実上の標準だった。XFree86はXを80386搭載のパーソナルコンピュータ (PC) 上に移植することから始まり、1990年代末ごろにはXのデファクトスタンダードの地位を得ていたAnnouncement: Modification to the base XFree86(TM) license. 02 Feb 2004。しかし、2004年にX.Org ServerがXFree86のライセンスの変更を期にして派生し、こちらが主流となっていった。
XとUNIXの組合せはよく知られているが、Xサーバは他のグラフィカル環境用にも存在している。
WindowsやmacOSなどの他のウィンドウシステム上でXサーバを動作させる場合、統合のさせ方がソフトウェアによって色々あり、X.Org ServerではWindowsとmacOSでは以下の方式の最初の3つをサポートしている。Unix系ではフルスクリーンだが、それ以外はXnestによりサポートしている。 シングルウィンドウ - X11のルートウィンドウをOSのトップレベルウィンドウにマッピングする。 マルチウィンドウ - X11のトップレベルウィンドウをOSのトップレベルウィンドウにマッピングする。 ルートレス (rootless) - 本来のウィンドウシステムが背景と基本メニューを提供し、Xのウィンドウの位置を管理する。すなわち、Xのクライアントが表示するウィンドウが、手元のウィンドウシステムで表示されるアプリケーションが出すウィンドウと同じように表示される。X11のウィンドウマネージャが利用される。 フルスクリーン
OpenVMS HPEおよびVSIのOpenVMSにはXとCDE (DECwindows) が標準のデスクトップ環境として含まれている。
OS-9 OS-9にもかつてメーカー純正のXサーバがあった。マイクロウェア・システムズ(株)がX Window Version 11 Release 4をOS-9に移植し、X開発ライブラリとXクライアント制御管理プログラム、Xクライアントプログラム、OS-9/UNIX互換関数ライブラリから成る "Client Development Pak" を40万円で発売した。
macOS X.Org ServerはmacOSでの動作をサポートしており、XQuartz (X11.app) として公開されている。Mac OS X v10.5~v10.7では標準搭載されていた。
Mac OS X v10.3では、XFree86 4.3とX11R6.6に基づいたXQuartzがMac OS Xに統合されていた。10.5以降はXFree86ではなく、X.Org Serverになった。古いMac OS 7などにもサードパーティー製のXサーバがある。
Windows X.Org ServerはCygwin併用の形でWindowsでの動作をサポートしており、Cygwin/X (Xwin) として公開されている。
それ以外にも、他のグループによる各種実装が存在する。X.Org Serverから派生した物もあれば、1から実装されている物もある。自由ソフトウェアとしては、WeirdMind、WeirdX などがある。プロプライエタリソフトウェアとしては、ASTEC-X、Exceed、ReflectionX、WiredX、Xmanager、X-Deep/32、Xming、X-Win32、XVision Eclipse などがある。かつては、Xoftware/32（ネットマネージ製）、DynaWinX、PC-Xware（NCD製、数社が取り扱い）、Super-X（Frontier Technologies製、コンテック扱い）、eXodus for Windows（White Pine Software製、DIT扱い）という商品もあった。これらは通常、リモートのXクライアントを表示・制御するのに使われる。
スマートフォン・タブレット MeeGo、Maemo、Tizen、Ubuntu Touchなど各種Linuxスマートフォン・タブレットでもX Window System (X.Org Server) が使われている。
X端末 thumb|right|Network Computing Devices製のNCD-88k X端末
X端末は、Xサーバを実行するシンクライアントである。これはUNIXワークステーションが高価だったころ、大きめのサーバを複数人で共有し、各人がグラフィカルな環境を使えるようにする安価の手段として人気となった。また、これはMITのプロジェクトが本来想定していた方向性でもある。
X端末は、ネットワーク上で X Display Manager Control Protocol (XDMCP) を使って利用可能なホスト（クライアントを実行できるマシン）を探す。まず最初のホストでXディスプレイマネージャを起動する必要がある。
専用ハードウェアとしてのX端末はその後少なくなり、より安価なXサーバ用端末としてPCや新たなシンクライアントが使われるようになっている。
Xの限界と非難 UNIX-HATERS Handbook（1994年）は、1つの章を割いてXの問題を論じている"The X-Windows Disaster"。Why X Is Not Our Ideal Window System（1990年、Gajewska, Manasse, McCormack）は、Xプロトコルの問題を詳細に論じ、改善の方法を示唆している。
ユーザインタフェース機能 Xはユーザインタフェースの仕様やアプリケーション間通信の仕様を意図的に含まないようにしている。このためそれぞれ全く異なったインタフェースが生まれ、アプリケーション間の連携を阻む原因ともなっている。ICCCMはクライアントの相互運用に関する仕様だが、正しく実装するのが困難なことで有名である。MotifとCDEも標準化の試みだったが、解決策とはならなかった。この問題は、プログラマやユーザーを長い間悩ませてきたRe: X is painful 15 Nov 1996。2007年現在、アプリケーションのルック・アンド・フィールとアプリケーション間通信の一貫性を保つためには、特定のデスクトップ環境あるいは特定のウィジェット・ツールキットを採用してプログラムを作成するのが一般的である。
Xプロトコルは音声を全く扱わない。そのため、サウンドカードの制御も含めた部分はOSやOSSやALSAなどのオーディオシステムが分担している。多くのプログラマはOS固有のサウンドAPIを使っている。クライアントサーバ型のサウンドシステムとしては、古くはrplayやNetwork Audio Systemがあった。その後、EsounD (GNOME)、aRts (KDE) などが開発された。2001年、X.Orgはこの問題に対処するためMedia Application Server (MAS) の開発を発表した。しかし、これらはいずれも根本的な解決策とはなっていない。
ネットワーク right|250px|thumb|SSH上でX11アプリケーションをトンネリングしている例 XクライアントをあるXサーバからデタッチし、別のXサーバに再アタッチすることはできない。しかしXとは別の遠隔操作方法であるVirtual Network Computing (VNC) ではそれが可能であり、一部のアプリケーションやツールキットではそのような機能を提供しているSNAP Computing and the X Window System 2005。
XサーバとリモートのXクライアントの間の通信トラフィックは、デフォルトでは暗号化されていない。そのため悪意ある者がLANアナライザを使えば、それを覗き見ることができるので注意が必要である。
クライアント/サーバの分離 Xの設計では、クライアントとサーバはそれぞれ独立して動作する。ハードウェアからの独立性やクライアントとサーバの分離などのオーバーヘッドは、OS内にグラフィックス機能が統合されているシステム（WindowsやMac OS）にはないものである。Xが適切な性能を発揮するには、4MBから8MBのRAMを必要とすると言われている。これは1990年代中ごろまではWindowsやMac OSに比較すると大きかった。
Windows Vista/Windows Server 2008以降のWindowsに搭載されているWDDMやOS XのQuartzはXのようなクライアントとサーバの分離を行えるようになっている。オーバーヘッドの大半は、ネットワーク上のラウンドトリップタイムによるものである（つまりプロトコル自体の問題ではなく、レイテンシである）。性能問題を解決するにはそのレイテンシを考慮したアプリケーション設計をする必要があるAn LBX Postmortem 2001-1-24。Xのネットワーク機能が過度に複雑であるために、ローカルで使っても性能に悪影響があるという誤解を持つ人が多いが、現在のXの実装ではローカルな接続では単にソケットと共有メモリを使うので、X固有のオーバーヘッドはほとんどない。
ディスプレイドライバのクラッシュ時に発生する問題 ディスプレイサーバー本体やディスプレイドライバの実装は安定しているが、Windows系システムとは異なり、ディスプレイドライバがクラッシュした場合、直前までの表示内容は失われ、Xサーバー本体とXクライアントアプリケーションを手動で再起動しなければならない。 そのため、監視システムやインフラ制御システムなどのミッションクリティカルなGUIアプリケーションの利用には注意を要する。
Xと競合するシステム 長年にわたり、Unix系システムではグラフィックス表示にはXが使われるのが一般的だったが、2020年代現在、GNOMEやKDEなど各デスクトップ環境でXからWaylandへの移行が進みつつある。
Wayland以外にも数々のXの代替となるシステムが開発されてきた。1980年代には、サン・マイクロシステムズのNeWS（市場では成功しなかった）、NeXTのDisplay PostScript（AppleがQuartzに置換した）、日本製のGMWなどが開発された。Quartz開発者の1人であるMike Paquetteは、アップルがDisplay PostScriptからXに移行せずに独自のウィンドウサーバを開発した理由として、アップルが必要とする全ての機能をX11に追加してみたら、X11とは似ても似つかないものになり、他のXサーバとの互換性も失ってしまったと説明したWhy Apple didn't use X for the window system August 19, 2007。Xとの互換性を重視したMirは、一時期はWaylandの対抗馬と目されたが、XやWaylandを置き換えるほどの勢いはない。WaylandやMirではX互換レイヤーによりXアプリケーションを実行できる環境が用意されている。
ハードウェアを直接操作することでXのオーバーヘッドに対処しようとした競合システムもある（例えば、DirectFBやFrameBuffer UI）。ダイレクト・レンダリング・インフラストラクチャ (DRI) は、ほぼ同等の機能をX内でモジュール化したものと言え、それら競合システムの努力が無駄になる可能性もある。しかし、（RTAIなどを使った）組み込みシステム用LinuxではDRIのリアルタイム性は思わしくなく、そのような応用にXは今のところ不向きと言える。
グラフィックス関連のサービスでネットワーク透過性を達成するその他の手段には、以下のものがある。 SVG Terminal - Scalable Vector Graphics (SVG) 形式のコンテンツをほぼリアルタイムでブラウザとやりとりして更新するプロトコル。 Virtual Network Computing (VNC) - ネットワーク上で圧縮したビットマップを送る。 Citrix Presentation Server - Windows向けのXのような製品。 タランテラは、ウェブブラウザを使うJavaクライアントを提供している。 RAWT (Remote AWT) - IBMのJavaによるクライアントサーバシステム
歴史 先駆的開発 X以前にも、ビットマップディスプレイを使ったシステムは存在していた。ゼロックスはAlto（1973年）とStar（1981年）を開発している。AppleはLisa（1983年）と Macintosh（1984年）を開発した。UNIX関連ではAndrew Project（1982年）とロブ・パイクのBlit端末（1984年）がある。
Xの名称は、それ以前のW Window Systemの後継であることから名づけられた。W Window SystemはVというOS上で動作した。Wはネットワークプロトコルを使って端末やグラフィックウィンドウをサポートし、サーバ側でディスプレイリストを管理する。
thumb|left|250px|1990年代初期のX Window Systemによるデスクトップ。twm、xterm、xbiff、xload、グラフィカルなmanページブラウザなど、MIT X Consortiumのディストリビューションにあったアプリケーションが動作している。
起源と初期の開発 Xの考え方がMITで生まれたのは1984年、Jim Gettys（Project Athena）とBob Scheifler（MITコンピュータ科学研究所）によるものであった。ScheiflerはArgusというシステムのデバッグ用の表示環境を必要としていた。Project Athena（DEC、MIT、IBM によるコンピュータのユーザインタフェースを改善するプロジェクト）ではプラットフォームに依存せず、マルチベンダーシステムで利用できるグラフィックスシステムを必要としていた。当時、カーネギーメロン大学のAndrew Projectでウィンドウシステムが開発中だったが、ライセンス提供を受けることができず、他に代案もなかった。
解決策として、ローカルなアプリケーションも動作させることができ、リモートでも動作させることができるプロトコルの開発という考えが生まれた。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をDECのQVSSディスプレイ付きMicroVAXに移植した。
1985年第二四半期、Xはカラーをサポートし、DEC VAXstation-II/GPXで動作した。これがバージョン 9となる。MITはX6を外部グループに料金を徴収してライセンスしていたが、X9リリース時点からMITライセンスを適用することとした。X9は 1985年9月にリリースされた。
ブラウン大学のグループがIBM RT-PCにX9を移植したが、整列されていないデータの読み込みで問題が発生し、プロトコルに非互換となる変更が必要となった。このため、1985年末にバージョン 10となった。1986年には外部からXについての問合せが増えてきた。X10R2は1986年1月、X10R3は1986年2月にリリース。X10R3では広く製品に採用されるようになった。DECとヒューレット・パッカードはX10R3ベースの製品をリリースし、他のグループが アポロコンピュータのマシンやサン・マイクロシステムズのワークステーションへの移植を行い、IBM PC/ATへの移植も行われた。このころ、Autofactという見本市でXを使った商用アプリケーションが初めてデモンストレーションされた（Cognition Inc.の機械系CAEシステム）。X10の最後のバージョンはX10R4で、1986年12月にリリースされた。
Virtual Network Computing (VNC) がデスクトップの共有を可能にしているように、Xサーバをそのように拡張する試みはこのころから既に行われていた。例えば、Philip J. GustのSharedXツールがある。
X10は強力な機能を持っていたが、Xプロトコルはさらに広く使われるようになる前に、もっとハードウェア中立となるよう再設計する必要があることがわかってきた。しかし、MIT だけではそのような全面的な再設計をするだけのリソースがなかった。そこでDECのWestern Software Laboratory (WSL) がこのプロジェクトに参加を申し出た。DEC WSLのSmokey WallaceとJim Gettysは、DEC WSLがX11を開発し、それをX9やX10と同じ条件でフリーにリリースすることを提案した。設計は1986年5月に開始され、8月にはプロトコルが完成した。アルファテストは1987年2月に開始され、ベータテストは1987年5月に開始された。X11のリリースは、1987年9月15日に行われた。
Scheiflerが中心となって行われたX11プロトコルの設計は、USENETのニュースグループとオープンなメーリングリスト上で盛んに議論しながら進められた。したがって、Xは最初の大規模自由ソフトウェアプロジェクトと言われることもある。
MIT X ConsortiumとX Consortium, Inc.