これについては少々がっかりする人がいるかもしれませんが、現状のＷｉｎｕｘではウインドウシステムをサポートしないことにしています。 実際論として、ＷｉｎｄｏｗｓとＬｉｎｕｘの大きな違いはウインドウシステムであり、この相違を吸収するライブラリを作成すれば、その付加価値は大きいと思われます。 ただ、よく考えてください。両方で動作するからには、片方のみに存在する機能は使えないという事です。 操作性を重視する為のウインドウシステムにこの様な制約を加えるということは、その存在価値を著しく失墜させると私は考えます。 また、Ｗｉｎｄｏｗｓにおいては変化が激しく、２年から３年でフルチェンジが行われ、その変化に対応するだけで大量の工数が必要になります。 それよりも、ハード／ソフトの変化が激しくても誰かが勝手に変更してくれるブラウザに着目し、これに対応させる方が利口ではないでしょうか？
インターネットが普及後、最もポピュラーなソフトといえばブラウザでしょう。 Ｗｉｎｄｏｗｓ系の人はインターネットエクスプローラでしょうし、ＭａｃやＵＮＩＸ系の人はネットエスケープナビゲータの操作に精通しているはずです。 また、両者の操作性の違いはごくわずかで、青下線の文字列をクリックすればリンクされたページに飛ぶことや、 気に入ったページのアドレスを記憶したりする操作はあえて説明の必要はありません。 実際、ＯＳがなくてもブラウザとメールクライアントさえあればよいというパソコンユーザも数多いと思います。
Ｗｉｎｕｘではウインドウシステムに対応する代わりにブラウザの通信プロトコルであるＨＴＴＰプロトコルに対応しています。 つまり、Ｗｉｎｕｘで作成されたソフトウェアは１つ以上のＷｅｂサーバを持ち、同一のパソコン内でループバック通信して、ＧＵＩを１００％ブラウザに任せる方式をとっています。 通信機構を同一コンピュータ内で使用するのは、もったいない使い方のようですが、ブラウザという世界共通，プラットホーム共通のソフトを利用することにより、 ユーザは直感的に操作が出来て、プログラマーにとってもウインドウ対応に工数を費やすことなく、アルゴリズム創作に集中できるという大きなメリットがあります。
ＧＵＩにブラウザを使用する方法は最近のＬｉｎｕｘ設定ツールであるＷｅｂｍｉｎも採用しており、今後最も有望な方法です。 ブラウザはどんなプラットホームにも勝手に対応してくれます。 またネットワークを接続すれば、実行しているパソコン以外からも操作できますし、 それがＷｉｎｄｏｗｓであろうがＬｉｎｕｘ，ＰＤＡ，携帯電話であろうが、ブラウザを実行できる機器であればよいのです。
余談ですが、私はＧＵＩをブラウザに統一したＯＳの構想を練っています。 すべての操作がブラウザ上で行えれば、ウインドウシステム自体が必要ないと考えます（ＣＡＤなどの分野はムリですが）。 電源ＯＮですぐにブラウザが立ち上がる様な感覚が実現できれば、マイクロ※フトに勝てるかも？
既に説明したとおりＷｉｎｄｏｗｓではＰＥ，ＬｉｎｕｘではＥＬＦという実行形式がありますが、 どちらもファイルの先頭の数バイトを特定のコードで規定している為、両用で使用できるファイルは作成できません。 従って両者のバイナリ互換を実現するには、
１）Ｌｉｎｕｘのカーネルを改造し、ＰＥフォーマットを実行できるようにする。
２）両者のフォーマットのみを変換するプログラムを作り、変換して実行する。
という２通りの方法がありますが、Ｗｉｎｕｘでは２）の方法を採用します。 実行環境の違いを気にしなくてよいのがメリットであるバイナリ互換がカーネル改造という超特殊な環境を必要とするのはおかしいと考えるからです。 また、フォーマット変換は一瞬で終了しますし、Ｗｉｎｕｘで作成された実行形式ファイルは非常に小さく、ＰＥとＥＬＦの両方をインストールしてもディスク容量的には全然問題がありません。
要約すると、まずＷｉｎｄｏｗｓ環境にてコンパイルし、ＥＸＥ（ＰＥ）ファイルを作成する。 ＥＸＥ作成と同時に変換プログラムによりＥＸＥをＥＬＦに変換する。 ということです。なお、変換プログラム自身をＥＬＦに変換することにより、Ｌｉｎｕｘ上で実行時に変換するということもできます。
私としてはどちらの環境で開発してももかまわないのですが、一般的にはＷｉｎｄｏｗｓのＶｉｓｕａｌＣ＋＋環境が使いやすいとされています。 私は一発コンパイル，一発動作を当然と考えていますが、そうでない人にとっては、デバッグ性が優れているＷｉｎｄｏｗｓ環境の方がいいみたいです。 ＷｉｎｕｘではＶｉｓｕａｌＣ＋＋環境を標準としました。 ＶｉｓｕａｌＣ＋＋は優れたコンパイラですが、やっかいな点もあります。例えば「例外処理を有効にする」というオプションはデフォルトでＯＮですが、 これによって、関数の前処理と後処理の部分にリアルモード（１６ビットモード）命令が挿入され、これをＬｉｎｕｘで実行すれば当然ながら停止させられます。
ＶｉｓｕａｌＣ＋＋の環境は費用がかかり、いやだという人もいるかもしれません。 ただＷｉｎｕｘの場合は、Ｃ＋＋言語がコンパイルでき、Ｗｉｎ３２のＥＸＥが作成できればよいので、高機能なものは必要ないですし、最新である必要もありません。 一番安いＶｉｓｕａｌＣ＋＋．ＮＥＴスタンダード（１万円強）とかＶｉｓｕａｌＣ＋＋の古いバージョンをアウトレットで購入すればよいのです。 とはいっても開発環境１台きりの出費なので、それによって開発時間が短くなれば元はとれるでしょう。 なお、ＶｉｓｕａｌＣ＋＋．ＮＥＴスタンダードはうたい文句が学習用となっていますが、十分強力なツールで、ブラウザやＨＴＭＬエディタの機能も入っています。 また、テキストエディタがかなり改善されているので、私は外部エディタを使わなくなってしまいました。 パッケージにはＣＤ−ＲＯＭが４枚あり、インストールには２ＧＢ位のハードディスク容量が必要ですが、機能が豊富でこれが１万円強なのかという驚きがありました。文句なしにお勧めです。
気をつけて欲しいのが、コンパイラに含まれている再頒配布可能コードの存在です。 これを自由にコピーしてよいのは、あくまでＷｉｎｄｏｗｓ上だけで動くソフトを作成する場合です。 Ｌｉｎｕｘで動かす事ができる本システムでは使ってはなりません。
これについては作り初めてから発見したことですが、文字コードというものは表示部と入力部だけの問題であり、 これらをすべてブラウザに任せれば（大抵のブラウザは得意とするところです）、複数の文字コードを扱う必要がないということです。 開発環境はＷｉｎｄｏｗｓ環境を利用することから、シフトＪＩＳに統一します。 したがって、プログラミングする際に文字コードには全然気にする必要はありませんし、通常の日本語処理関数を使用できます。 またＬｉｎｕｘ環境にシフトＪＩＳコードの入ったファイルがあっても問題はありませんし、高機能なエディタなら編集も可能です。
malloc() の様なメモリの動的取得に関してですが、Ｌｉｎｕｘではライブラリがほとんどの処理を行っている関係上、自作する必要があります。 Ｗｉｎｕｘはサーバ的なプログラムになるので、 メモリの動的取得／開放を繰り返してゴミができ、どんどんメモリ消費が増えていくような方法では長期間の常時起動に問題が生じます。 また、あまり細かくメモリを管理し過ぎるのも、取得／開放時にＣＰＵパワーを消費する事になります。 これはギガ単位のメモリが当たり前の時代には合わないアルゴリズムだと思います。 某マイクロ※フトは未だにこのような考え方を捨てきれてません（ハードディスクを整列化するデフラグがよい例です）。
Ｗｉｎｕｘでは取得するメモリサイズを等比的な２４種類(32,64,128,256,512......)に固定します。 つまり、３３バイトの取得の場合でも実際には６４バイトを取得します。 １２９バイトの取得の場合は実際には２５６バイトを取得します。 開放時にはそのブロックをサイズ別のリストに登録する方法をとり、６４バイトのブロックであれば６４バイトの再利用リストに登録されます。 当然次に６４バイトブロックの要求があれば再利用リストからブロックを取得します。 これにより、ブロックの１００％再利用が可能となり、メモリ消費量はある一定値以上に増えにくくなりますし、 リスト構造をたどっていくというものに比べて遥かに高速処理できます。 デメリットは、メモリ容量が１．５倍ほどいることだけです。（ギガ単位のメモリを積んでいるマシンでも実際には２００メガくらいしかつかっていないのでは．．）
拡張ボードなどを使用するとき、専用のデバイスドライバがＬｉｎｕｘに対応していない事が多いのですが、 アクセス方法が分かっている場合は、ドライバを自作する方法をとるでしょう。 ＷｉｎｄｏｗｓとＬｉｎｕｘのバイナリ互換を目指すならば、そのドライバの仕様は同じものにしなくてはなりません。 結局は両方のドライバを作成するはめにもなりかねません。
Ｗｉｎｕｘでは汎用のドライバを１つ用意することで解決しています。 そのドライバを組み込んでおけば、ＰＣＩバスの検索から、Ｉ／Ｏ，メモリ読み書きまでドライバを意識せずに通常のＡＰＩ関数の感覚でアクセスできます。 拡張ボードを何枚も使用する場合でもＷｉｎｕｘ専用ドライバ１つあれば事足り、同一のプログラムで動作することは言うまでもありません。
ソフトウェアの価値という問題について考えると、案外無視されているのがコンパクト化ではないでしょうか。 ソフトの容量が大きくなるということは工数や人数が必要ということです。 例えば、ソースファイルの容量が２倍あるとすれば、コーディング，コンパイル，デバッグ，取説作成，クレーム対処のすべての工数が２倍になります。 すべて１人でやればよいのですが、２人以上の作業になるとさらに工数が１．５倍くらい必要となります。 人数が増えるということは、開発方針や思想がぼやけてくるデメリットもあります。
ある会社の失敗談で文書をすべてコンピュータデータ化しろという方針を徹底したところ、 複数の人間が全く同じ内容の文書をそれぞれデータ化したため、莫大な工数だけを消費し、データ化が進まなかった事例があります。 ソフト技術者は仕事自体が利己的な為、これと同様な事態に陥りやすいと言えます。 誰しもある程度簡単である程度勉強になり、成果が自慢になるような作業をしたがります。 ただそれではいいもの（高付加価値で利益が上がり、短期で完成する）は出来ないのです。 自尊心を捨て、「あるものはすべて利用する」という精神を持つ事が必要です。ただ、あるものを選ぶセンスも必要ですが．．．
ＷｉｎｕｘではＧＵＩをブラウザに任せています。これによりＯＳやハードウェアの違いを吸収しています。 外部とのデータインターフェースをＨＴＴＰプロトコルに統一することで、ファイヤウオールやルータ、ＤＮＳ，プロキシサーバなど、 既にあり、誰かが勝手に更新してくれるものをそのまま利用することができます。 これは大幅な工数低減になることはいうまでもありません。