従来のWindowsアプリをWindows Storeで配れるようになる話――Project Centennial個人的まとめ

Microsoftの開発者カンファレンスBuild 2015初日の基調講演で、Windows Store AppではないアプリをUniversal Windows Platformに移植するためのツールキット群がアナウンスされた(Universal Windows Platform Bridges - Windows app development)。本記事はそのツールキット群のうち、旧来のWindowsアプリからの移植を可能にするProject Centennialについて個人的にまとめたもの。筆者による誤解が含まれるかもしれない。

Project Centennialについては、John Sheehan氏とAndrew Clinick氏のセッション動画が現時点で手に入るもっとも詳しいリソースかと思う。本記事でも内容の全ては拾いきれていない。英語が分かる人はこれらを見たほうが早い。本記事中のことは明示しない限り1番目の動画がソース。channel9.msdn.com
channel9.msdn.com
このほか、下に挙げるトークセッションでProject Centennialの話が登場する。channel9.msdn.com

概要

Windows 8から導入された、いわゆるWindows Store App(現Universal Windows App)は、旧来からのWin32や.NETとは全くことなるモデルのプラットフォームであり、既存のアプリを移植する方法が文字通り「書き直す」しかないというひどい有様だった。
Windows 10になってようやく、デスクトップアプリ (Classic Windows App) の救済に乗り出すようだ。

デスクトップアプリからUniversal Windows App (長いので以下UWA) への橋渡しとして現在開発されているものがProject Centennial (以下Project C) である。Project Cでは、.msiファイルをWindows Storeで配れるパッケージに変換するツールが提供される。デスクトップアプリをパッケージ化するためにソースコードを書き換える箇所は少なく済む。ただし、パッケージ化しただけでPhoneやIoTやHoloLensで動くとかいう旨い話ではないことに注意。

Project Cでパッケージ化したアプリは、OS XApp Storeで配布されているアプリのような特徴を持つ。
デスクトップでしか実行できず、デスクトップ向けのAPIが呼べ、起動から終了までのライフサイクルもデスクトップアプリと同じ。ただしよりアプリらしくなる。つまり、インストール・アンインストールは簡単になり、アップデートは自動化される。
また、特権昇格が禁止されるが、OS Xのものと違ってサンドボックスで動くわけではない (Full trust)。

もう一つ重要なこととして、パッケージ化されたアプリはデスクトップAPIに加えてUWA向けAPIが呼べるようになる。Microsoftとしては、デスクトップアプリ開発者たちにUWAとしての利点を活用してもらい、段階的にクロスプラットフォームで動くアプリに移行してほしいようだ。ただし、詳しい開発フローはまだアナウンスされていない。

プレビュープログラムもまだオープンではない。おそらく細かい仕様も固まっていない。

パッケージ&デプロイ

Project Cで提供されるツールは、MSIが行うレジストリファイルシステムへの書き込みを全て記録して一つのパッケージ (.appx) にまとめ上げる。作ったパッケージは、ストアで配信するか、サイドローディングで他のマシンにインストールすることができる。ちなみに、グループポリシーで制限されていなければ誰でもアプリをサイドローディングできるようになる模様。

このパッケージ化でうまくいかない例があって、その一つが基調講演で紹介されたAdobe Photoshop Elements。Photoshop Elementsは、違法コピーされていないか確認するため、システム情報を集めて暗号化したものを保存している。そのために、出来上がったパッケージが他のシステムでは使えなくなる。こういった場合にはソースの書き換えが必要とのことだ。裏を返せば、そのほかは普通に動く。

このあたりはLinuxディストリ向けのパッケージ作成を想起させる。だが、パッケージの展開のされ方はLinuxディストリ向けと大きく異なる。Linuxディストリ向けではパッケージの中のファイル群が生のファイルシステム上 (/optなり/usr/shareなり) に展開される。いっぽうProject Cのパッケージでは、アプリごとに隔離された仮想環境にファイルやレジストリが展開される。その上で、実行されているアプリにだけそのアプリとともにインストールされたファイルやレジストリのエントリーが見えるようなハックがシステムレベルでなされる。
ちなみに2番目の動画によると、アプリをリムーバブルメディアにインストールすることもできる。

もう一つ、よくあるパッケージシステムと異なるのは、依存関係の解決方法。よくあるパッケージシステムでは、各アプリで共通の依存関係があるとき、その共通部分をパッケージとして独立させてアプリのパッケージとの依存関係を決める。Project Cで作成されるパッケージでは、そのアプリで必要なあらゆるDLL類を同梱することになっているようだ。これは大きな無駄と思われるかもしれないが、同じDLLファイルを同梱している複数のパッケージをインストールしてもインストールされるそのDLLファイルはただ1つである。これはNTFSハードリンクで実現すると3番目の動画でSheehan氏が述べている。

デスクトップアプリがProject Cでパッケージ化されることはユーザにとって大きなメリットだ。アンインストールでアプリは確実にシステムから除去される。レジストリファイルシステムが汚される心配もいらない。アプリのアップデートでOSの再起動が要求されることも無くなる。

App-Vとは違う

Project Centennialの出発点はApp-Vで、共通の技術はあるが両者は別物とのこと。

App-Vはソースコードにアクセスできないエンプラ向けのソリューションであって、上に載せるソフトのバグで動かないときでもApp-V側を変更して対応していた。
Project Cはデベロッパー向けソリューション。よって多少ソースを書き換えることを前提にしている。

謎とか心配とか

  • ファイルopenにシステムが介入してOKなら256バイト問題解決できないだろうか?
  • ストアの審査基準
  • ストア外での野良パッケージの流通
  • しばらくWPFとUWAのキメラみたいなアプリが蔓延しそう
  • おそらくリリースはWindows 10と同時ではない