Wine(Windowsアプリのエミュレータ)には正直肩透かしを食らったね

Microsoftが企業として本当にやばい状況と言う危機感から別OSへの移行を本格的に否が応でもしなければならない心境になり、今月から手始めに自分の作ったWindowsアプリケーションがどの程度動くか少し試したが、正直、機先を削がれたと言うか肩透かしを食らってしまったね。これがそこそこ動くのならモチベーションも上がるのだが、一気に気分が重くなってしまった。

数か月程度で筆者が作った時計アプリ(「透過時計」と言う名称)があるのだが、それがWindowsの比較的最近にできたグラフィックスライブラリであるDirectXを使っている。これは元々は高速描画が必要なゲームのために考えられたライブラリだ。最初はGameSDKと言っていたと記憶している。
　そして最近の報道によればWine
(Windows Is Not Emulatorの略で、エミュレータでないと言いながら事実上のエミュレータ、つまり別OS上でWindowsアプリを実行させるソフトウェア)
は、DirectXの対応に注力しており、ゲーム用プラットフォームであるSteamもこのソフトをベースにしたエミュレータに巨額投資し、Windows上で動く有名タイトルのゲームがLinux上でも多数動くと報道されている。

…だから筆者の作った数か月程度で作ったDirectXを使ったソフトも動くのではないのかと淡い期待をしていたのだが、見事にその期待は裏切られた。表示もせず一気にクラッシュ。

技術的な観点からの不具合原因を推測すると、多分Wineは画面にDirectXを描画するウインドウが１つだけしか想定してないと思われる。加えてそのウインドウは全画面という前提だと思われる。何故ならゲームの画面は画面いっぱいに表示されるのが当然であり、筆者の作ったソフト(透過時計)は複数のDirectXのウィンドウが画面に幾つもあり、そのサイズはユーザーが自由に変えられるからだ。

加えて透過時計はその名の通り、描画した文字が透過し、文字以外の背景色は全く何もない。
　通常、Windowsのアプリの外形は必ず背景色があるのだが、それを無くしているのだ。ゲームなら基本全画面で、そのゲーム内の描画以外の後ろに隠れているウィンドウの描画など全く考慮する訳がないし、する必要もない。
　PCの周辺機器を買ったときについているユーティリティソフトには時々凝った作りのウィンドウがあり、ウィンドウの外形が四角でないものがある。それも基本の背景色を消しているのだが、透過時計は比較的最近のバージョンのWindows上でしか動作しない別のやり方でそれを実現している。Windowsは複数の方法でそのような特殊なウィンドウを作成できるのだが、Wineはそれらに対応していないのだろう。

（追記：「追記12/29」でこの件でGemini3に質問したものを最後に追加した）

一方、最初に作ってから20年以上経過しているX Button Makerは、基本Windowsの古いAPIしか使っていないソフトなのだが、残念ながらこれもWineを間にかましても別OS上では動かない。このソフトのエミュレーションで必須の機能がフック関数（端的に言うと、Windowsの各種メッセージを横取りしてその内容を書き換える事が出来てしまう機能）の実装なのだが、これがGUIが分離しているLinuxの各ディストリビューションでは実装がまちまちであり、かつWindowsのフック関数を代替するものが1つも存在しない。だからフック関数をWineでエミュレートする場合は、各GUI(X Window Systemや最近出たWayland)そのものの機能を拡張しそれぞれ実装する必要が出てくる。

要するに、開発から既に何十年も経っているWineというエミュレータは、完全にWindowsソフトを別OSに移行させるにはいまだ不十分だと言う事だ。標準的なダイアログボックスやウィンドウは表示できる程度で、WindowsソフトをLinux上に移行するには、やはり一からソースコードレベルで作り直しが必須だということだ。ちょっとでも凝った機能があるソフトはほとんどエミュレートできないか、一から作り直そうとしてもそもそもそれを実現させるAPIが初めからないので代替策を講じなければならない。

でもWineをベースとしたMacOS用の商用版は秀丸も動くと言うから全く無能なソフトではないのだろうが、自分の作るソフトはそのような標準的なソフトではなく、ハッキング要素のあるソフトだから特に動かないのだろう。何故なら筆者がソフトを作る動機はWindowsには無い機能の実現が主なのでそうならざるを得ないのだ。

このような悩みは、最初に書いたがMicrosoftと言う企業がとうとう無視できないほどやばくなっているからであり、つまりWindowsの信頼性が地に落ち、その理由が技術音痴で無能な経営陣の致命的に間違った経営判断が真の原因だ。

Microsoftは他社の成功を利用した商売が上手で過去ソフトの互換性の高さからPC上のOSを独占してきたが、新技術への対応は何度も失敗し、また自ら世の中を変える革新的新技術を発表し主導していく能力は全くない。基本的に他社の後追いだ。
…つまり、道標となるリーディング企業が存在しないか、その企業が行き詰まっていると当然Microsoftも行き詰まっていくのだ。
Microsoftの道標となるのは言うまでもなくAppleであり、Appleは現在事実上スマホだけの企業であり、スマホはもうすでに急激な成長は見込まれない。だから現在は新たなる儲けの柱として腕時計や眼鏡型デバイスも作っているが基本スマホ前提かスマホの別形態の商品にすぎない。しかもMicrosoftはスマホ関連の開発では完全に失敗した。

最近ではMicrosoftはクラウドサービスの売り上げが高いと言われているが、それがMicrosoftが実質的にWindowsを軽視している原因なのだろう。既にMicrosoftは真の稼ぎ頭であろうMS-Officeを従来のようなPCにインストールするタイプではなく、クラウド版を推しており、これはWindowsじゃなくても実行できるものだ。

そのクラウドもセキュリティリスクなどから一般ユーザーは敬遠され始め、企業ユーザも地政学的問題を考慮してクラウド全面依存にはならないと筆者は思っている。加えて最近はやりの人工知能は強力なサーバーが必要であり、その立地で環境破壊するサーバー環境やセキュリティリスクという副作用が出ている。
つまり自ら先陣を切る事が出来ないMicrosoftは行き詰まるのは当然の成り行きだ。

最近ではWindowsの開発言語をC/C++からRustに書き換えると技術幹部の一人が言い、話題になったそうだ。それもAIにすでに動いているコードをRustに書き換えさせるとか言っている。どこまでミーハーな連中なのか。これも全部他社の後追いであり、何の熟慮も感じられない。世の中の潮流がスマホに移っているからと言う理由だけでPCの画面をスマホ画面に変えたWindows8並みのアホらしさだ。

脱線するが、筆者は錆を意味するRustという名称にものすごい拒否反応がある。筆者は言霊があると思っている人間の一人であり、縁起でもない言葉をプログラミング言語の名称にしないでほしいと思っている。最低でも名称変更しないとこの言語でプログラミングする気にはなれない。

筆者としては過去バージョンのWindowsのソースコードを公開すべきだと思っている。
全世界的な社会的コスト低減のためにはMicrosoftがWindows8程度までのソースコードを無料化して公開すべきだ。何十年も経ってMS-DOS Version4.1という当時散々な評価のOSを公開するのではなく比較的最近のOSを無償公開して社会貢献すべきだ。強欲な大株主を利することをしたら逆にこの世は暗くなる。最近のビルゲイツの悪行を見ればそれは明らかだ。

でも、この筆者の願いは決して実現する事は無いだろう。それが仮にあるとしたらMS-DOS同様Windowsが全く使われなくなって数十年経過した未来だ。そしてMicrosoftはカネ儲けだけ見ていてジリ貧になり消えていく。信頼性が無くなり不安定なWindowsにしがみついていた各企業はその時慌てふためくに違いない。

　だからもう各企業はOSそのものを作るぐらいの気概を持つしかないと思っているし、大企業ならそれができると思っている。筆者一人でもGUI部分ぐらいなら自作できるんじゃないかなと思っているぐらいだし。また国家が主導してもいい。それこそデジタル庁の出番だ。LinuxというかGNUの思想であるソースコード公開が嫌なら、FreeBSDをベースに自社OSを作りそれを自社のネットワークや個別商品の基幹OSにすればいい。
　一応日本には別の代替手段でもあるTRONもあるが、筆者が見た限りではあまりにもとっつきにくくこのOSをモノにするにはかなり険しい道が待ち構えていると思っているが…

　西暦2000年前後もLinuxのブームがあり筆者も検討したが結局Windowsに戻った。しかし今回はMicrosoftの根本的な危機であり、かつ米国企業を支える米国経済や世界経済の根本的な破滅が予期されている時代だから、Windows離脱は否が応でも検討せざるを得ないのだ。

---------------------------------
追記12/29
筆者の質問：

WineはDirectX対応に注力していると最近の報道で見られますが、私の作ったアプリでは全く動作しませんでした。
ちなみに私のアプリは、複数のDirectXのウィンドウを同時に作成し、かつそれらはDirectXを利用した透明なウィンドウで、文字だけ半透明で表示されます。これはWindowsの描画の一般的なものとは異なり、WM_PAINTメッセージが来たら描画するのではなく、アプリ側が明示的に描画する必要がある物です。このようなアプリケーションはまだ対応していないと言う事ですか？
大分対応が進んでいるDirectX使用ゲームの場合は、1画面の全面表示だけを考慮するだけでいいので、複数ウィンドウは対応が進んでいないように感じています。

--------------
Gemini3の回答:

その通りです。鋭いご指摘ですね。

現在、報道などで「WineのDirectX対応が進んだ」と言われているのは、主に**「1枚の巨大な3D描画用ウィンドウ（スワップチェーン）を占有して高速に描画する」という、いわゆるフルスクリーンやボーダーレスフルスクリーンのゲーム**をターゲットにしたものです。

質問者様が開発されているような、「複数のウィンドウ」かつ「半透明」かつ「DirectXによる直接制御」というアプリケーションは、Wine（およびその中核技術であるDXVK/vkd3d）が最も苦手とする領域の一つです。

動かない主な理由は、以下の3つの技術的ボトルネックに集約されます。
1. 「Layered Windows (WS_EX_LAYERED)」とDirectXの不整合

Windowsネイティブでは、UpdateLayeredWindow や DXGI_SWAP_CHAIN_FLAG_GDI_COMPATIBLE を使って、DirectXの描画内容とデスクトップの透過処理を統合します。

Wineの現状: WineはLinuxのウィンドウマネージャ（X11やWayland）の上で動いています。Windowsの「透明なレイヤーウィンドウ」をLinux側の「透明なウィンドウ」にマッピングする処理と、そこにDirectX（Vulkan/OpenGLへの変換）を流し込む処理の同期が完全ではありません。

特に**「明示的にアプリ側が描画を制御する（WM_PAINTを待たない）」**スタイルは、Wineの再描画ループとタイミングが合わず、何も表示されない（透明なまま）か、真っ黒になる原因になります。

2. Composition Swapchain (DComp) の未実装

モダンなWindowsアプリ（半透明やアニメーションを多用するもの）は、DirectComposition (DComp) というAPIを使って、複数のDirectXコンテンツを合成します。

Wineの現状: 2024年〜2025年現在、Wine/DXVKにおいて CreateSwapChainForComposition などのAPIは**「Not Implemented（未実装）」**または「スタブ（形だけ存在して何もしない）」であることが多いです。これが実装されていないと、複数のDirectXウィンドウを透過的に重ねるアプリは正常に表示されません。

3. マルチウィンドウにおけるリソース管理

ゲームは通常「1デバイス・1スワップチェーン」ですが、複数ウィンドウのアプリは「1デバイス・複数のスワップチェーン」または「ウィンドウごとのデバイス」を持ちます。

Wineの現状: Wineの描画を高速化している「DXVK」というツールは、マルチウィンドウ環境での挙動が不安定になる（フリッカーが起きる、または描画が止まる）という報告が以前からあります。

結論として、対応していないのか？

**「一般的な意味でのDirectXには対応しているが、Windowsデスクトップ特有の高度な描画（透過合成・マルチウィンドウ）にはまだ追いついていない」**というのが正確な状況です。
解決策・回避策の提案

もし、どうしてもLinuxで開発を完結させたい（かつWineでの動作を死守したい）場合は、以下の方向性を検討してみてください。

描画方式をGDI+（またはソフトウェア描画）に一旦落とす: DirectXでの直接描画ではなく、一度メモリ上のビットマップに描き、それを UpdateLayeredWindow で流し込む方式であれば、Wineでも比較的安定して透過表示されます（ただし、速度は落ちます）。

DXVKを無効にしてみる: 最新の高速化技術（DXVK）が逆にマルチウィンドウの邪魔をしている場合があります。環境変数 WINED3D を使う（古いOpenGLベースの変換に戻す）ことで、表示だけはされるようになる可能性があります。

クロスプラットフォームなGUIフレームワークへの移行: 「Wineで動かす」ことが目的であれば、最初から Qt (C++) や Avalonia (C#) のような、Linux/Windows両方の透過ウィンドウにネイティブ対応しているライブラリを使う方が、PCの往復は不要になります。

もしよろしければ、開発に使っている言語（C++, C#, Rustなど）や、DirectXのバージョン（9, 11, 12）を教えていただけますか？ それにより、特定のパッチや代替案を提示できるかもしれません。
--------------