ASCII.jp UWPからデスクトップアプリに回帰すべく、MSが送り出した「Project REUNION」

じゃあ、そもそもなんで分離するような真似をしたんだ黒歴史になろうとしているWindows 8

話は、Windows 8にさかのぼる。いまやマイクロソフトの黒歴史として封印されつつあるWindows 8には、モダン環境とデスクトップ環境の2つのアプリケーション実行環境が作られた。

UWPとWin32の「分断」は、Windows 8で始まった。ストアアプリを重視したマイクロソフトだったが、Windows 8も人気がいまいち、ストアアプリもソフトウェアがしょぼい状態が続いた。Windows10では、これをUWPとし、スマートフォンアプリやウェブアプリを同時に開発できるとして開発者を呼び込もうとした

このモダン環境用に作られたAPIセットがWindows Runtimeだ。短縮してWinRTとも表記されることがあるが、Windows RTとは違うことだけはおさえておきたい。

WinRTは、AndroidやiOSのAPIを参考に、カジュアルなアプリケーションを作りやすいAPIとして策定された。それまで使われてきたWin32/64 APIは、WordやExcelのような巨大なアプリケーションを作ることも想定されているため、APIひとつひとつの機能は非常に細かい。Win32/64APIでは細かな機能を自分で組みあわせてどんなアプリにでも作ることができる。

これに対してWinRTは想定しているアプリケーションを作りやすいようになっているが、どんなアプリケーションにも向いているわけではない。たとえていえば、Win32/64APIは、レゴのようなもので、小さな部品を組みあわせてアプリを作るものだ。これに対して、WinRTはもう少し部品が大きく、ある程度の用途が想定されていて、プラモデルの部品のようなイメージだ。だから、あらかじめ想定したアプリは簡単に作れるが、そうでないものはかなり制限がキツい。量産型ザクのガンプラを買ってきて、シャア専用ザクにするぐらいなら簡単なのだが、ガンダムにするのは大変という感じである。

ただし、WinRTに関していえば、従来からのWin32/64APIの「置き換え」ではなく併用するものなので、これは、これで意味があった。問題だったのは、モダン環境とデスクトップ環境をほぼ完全に分離したことだ。最初の段階では、モダンアプリとデスクトップアプリでは、テキストのコピー＆ペースト程度が可能な程度で、たとえば、モダンアプリからデスクトップアプリを起動したり、その逆もできなかった。

つまり、従来のWindowsであるデスクトップ環境の中に完全独立したモダン環境を埋め込んだようなものだった。これは、ストアでアプリを有料販売するということから高いセキュリティを保つというのが理由だった。また、マイクロソフトは、ストアアプリをWindowsアプリケーションの本流と位置付け、その普及に力を入れた。WinRTを普及させ、Windowsのエコシステムをモダン環境側に移行させ、スッキリしたAPIセットの世界に移行することを夢見ていたようだ。

しかし現実には、ストアアプリは開発者には受けなかった。すでにAndroidやiOSのアプリストアがあり、ビジネスは十分そっちできたため、仕組みがまったく違うWindowsのストアアプリに新規参入する開発者は少なく、また既存の開発者は、Win32アプリを作り続けた。そして、もちろんWindows 8は評価が上がらず、黒歴史と化した。

これを挽回しようと導入されたのがUWPとUWPアプリだ。こんどは、UWPアプリに対して、スマートフォンやウェブアプリへの可能性を加えた。UWPで開発すれば、すぐにAndroidやiOSのソフトウェアにも簡単に変換できるとして、一石三鳥を主張した。このためにスマートフォンアプリ開発用のプラットフォームのXamalinを買収したり、AndroidやiOSのアプリを簡単にWindowsやWindows Mobileに移植できる「ブリッジ」プロジェクトを発表した。

また、Nokiaからスマートフォンビジネスを買収し、Windows Mobileのスマートフォンまで自ら提供した。これも夢に終わる。Windows Mobile自体がほとんど普及せず、自社でのスマートフォンプラットフォームは終了した。

多数のプラットフォームでの動作を目指したため、UWP側には、Windows固有の機能が削除された、“中途半端”なAPIだけが残った。そしてWin32側は、UWPと比べると見劣りするUIコンポーネントのまま、気がつけば、どっちも寂れたプラットフォームになりかかっていたわけだ。すでに台数ベースでは、スマートフォンに抜かれ、タブレット市場でもWindowsは劣勢だ。しかも、GoogleはChromebookでLinuxを動かし、Androidのソフトウェア開発も可能にしようとしている。

そういうわけで、今やらねばならないことは、まだ多くの開発者がいるWin32デスクトップ環境を「魅力的」なプラットフォームとして復活させることだ。このときマイクロソフトは、2つの分野を足がかりにしようとしている。1つは開発プラットフォームとしてのWindowsだ。

Windowsアプリはもちろん、組み込みやさまざまな言語など、Windowsを搭載したPCはいまや開発者の標準環境である。これをなんとしてでも守り、さらに拡大させることがWindowsの生き残りにつながる。そこで登場したが、一連の開発ツールとWSLである。VSCodeやWindows Terminalといったオープンソースのソフトウェアは、開発者をWindows上につなぎ止めるために用意されたものだ。今回のBuild WindowsでWSL2のロードマップが示されたのも、この方向を強化するという「メッセージ」だ。

もう1つは、従来のWindowsとそのユーザー向けのWindowsアプリケーション市場だ。寂れたとはいえ、企業では多数のWindows PCを使って日々仕事をしているはずだし、多くの一般家庭でも使っているだろう。こうしたWindowsユーザー向けのアプリケーション市場にはまだ一定以上の規模がある。Project REUNIONは、UWPアプリ向けの「リッチ」なUIコンポーネントやさまざまな技術をWin32アプリ側に導入し、Win32デスクトップ環境やWin32デスクトップアプリの地位を同等にするためのものだ。

Windowsの復活は、Win32デスクトップアプリ市場の復活にかかっているといってもいい。マイクロソフトのOfficeしか売れないような市場に「活気」があるとは言えず、新規の開発者の参入が望めなければ、市場としては衰退していくしかない。今年1年でどれだけ変わるか、場末のサンデープログラマーである筆者としてはとても気になるところだ。

前へ12次へ

ツイートする

カテゴリートップへ

ASCII倶楽部

ASCII倶楽部とは

表示形式: PC ⁄ スマホ