2016年9月18日日曜日

Desktop App Converter で多くみられる誤解について


Desktop App Converter、動作可能なPreviewが出て数ヶ月経ちましたが、未だに残念な誤解と共に語られる事が多いように思います。また、そのせいで本来の利点が見えにくくなっているように思われます。

  1. これで変換したアプリは、Windows スマホでもすぐに使えるようになる！
  2. これで変換したアプリは、Desktop専用のUWP Appと大体同じ！
  3. 変換はMSIから行います！

全て誤解です。個人的には…「Desktop App Converter」という名前自体がミスリードを企図した、筋の悪い名前であると思っています。また最近はMSも「UWPに変換」とは言わなくなってきています（代わりに新語「Universal Windows Package」を使ったり、ステージングを行ってUWPに「自分で」移行しましょう、という話をするようになってきました）。正確を期して名で体を表すならば、「AppX Packager for Win32 Apps」あたりではないかと思います。


最近MSさんが使っている説明図 「Universal Windows Package」（新語）の中で、
Desktop App を順にUWP App に移行するイメージです
Desktop App Converterを通した直後が左上「Convert」に当たります
後は自分で移植して右下を目指そうぜ、という話



誤解1 「変換すればWindows スマホで使える」について



Desktop App Converter では、旧来のWin32 Desktop AppをAppX にパッケージングします。AppX であるので、Windows Store 経由でのユーザーへの配布が可能になります。
が、上のMSさんの図にもあるように、アプリケーションそのものはWin32 Appのままです。Win32 App 自体に何か変換が行われてUWP Appになる、というものでは無いです。

ユーザーのWin32 Appが動くOSは、Windows 10 Family の中では

  • Desktop ... PC, Notebook, Tablet

のみです。このため、それ以外…
  • Mobile ... Smartphone
  • Console ... Xbox One
  • Holographic ... HoloLens
  • Team ... Surface Hub(80インチくらいの巨大Surface）
  • IoT
上では動作しません。

上に貼ったMSさんの説明画像にもあるように、これら Desktop 以外のWindows 10 Family でアプリを動かすには、既存のWin32 App から Universal Windows Platform App、つまりWinRT ベースの新しいコードに「自分で」移植する必要があります。

Desktop App Converter は、この「移植」作業を行ってくれるわけではありません。UWP App への移植の最初の一歩、パッケージングを手伝ってくれるだけです。
また、

  • 変換時、何かコンパイル的な事が行われる
  • 動作時に何か動的にエミュレーション的な事が行われる
類のものでもありません。


誤解2 「変換すればUWP App」について


1で説明したように、Deployの終わったAppはWin32 Appのままです。このため、WinRT を基盤とする UWP Appと「大体同じ」とはとても言えないのですが…

ここでは、Win32 App と UWP Appは「何が」違うのか、実行時権限から考えてみます。
近年のWindows OSでは、プロセスの実行時権限は全て「IL」…Integrity Level、で分類されます。

  • ユーザーがインストールするDesktop アプリケーションはIL Medium
  • Webブラウザ等は既定ではIL Low

（Integrity Level 、良い文書が少ないのですが…下のは比較的判りやすいです。後、Win8 が出たころのメディア記事にもAppContainer絡みの説明記事が拾えます）
Desiging Applications to Run at a Low Integrity Level
https://msdn.microsoft.com/en-us/library/bb625960.aspx

IL Mediumは、所謂普通のWin32アプリです。ACLの許す範囲で、ユーザーがそうするのと同じようにシステム上のファイルにアクセスすることが可能です。

IL Lowはぐっと権限が制限されており、例えばファイルについてもアクセスできる範囲が狭くなっています。近年のブラウザは既定では大体はIL Lowで動くため、昔のように…Webを見てたらファイルを弄られた！スタートアップで女の悲鳴が！！！みたいな話はそうそう起こらなくなっています。

Windows 8の「StoreApp」では、このILに「App Container」という新しい分類が追加になりました。これは中々面白い定義で、「既定はIL Lowより低いが、インストール時に宣言することで追加の権限を有効にする」ことが可能です。この「宣言」とは、StoreApp / UWP App 開発者ならお馴染みの、Package.AppxManifest で定義するCapabilityの宣言です。UWP Appもこの点は共通です。


Process Explorer で各プロセスのIntegrity Levelを表示している様子
StoreApp / UWP App は「AppContainer」になります
画像では拙作のF10 imagebbs browser, PICT8 がAppContainerで動作しています


◇◇◇

一般に、StoreApp / UWP Appは安全であると言われています。不自由だがセキュアであると。これはMSが自分で言っていることですが…開発者側としてもここはあまり文句は無く、同意できるところだと思っています。

何故か？それは、上で説明したAppContainer により、StoreApp / UWP Appは制限されたSandboxの外に出られない仕組みになっているからです。
例えば、StoreApp / UWP App は、PC上のファイルを自由に触ることは実はできません。触れるのは、アプリインストールと同時に作成されるアプリ専用フォルダ「のみ」です。これはAppContainerによって権利が制限されているからで、ここを破るのは大変に困難です。（※１）

このため、実行時にこっそりとユーザーのHDDから大事なファイルを探して送信する、というような動作は本質的に不可能になっています。
こういった意味で、StoreApp / UWP Appは「安全」です。Storeからある程度適当にホイホイインストールしても、危ない目に合う事は少ないです。開発者が変な事をしづらい仕組みがApp Containerにより担保されているからです。


◇◇◇

では今回追加になった「Desktop App Converterで変換されたWin32 App」はどのILに属するのかというと… これはIL Medium で動作します。つまり、StoreApp / UWP Appを縛っていたAppContainerのSandbox制限が全く掛かりません。今迄のWin32 Appと同じ権限で動作します。（※２）

Desktop App Converterを使用しているアプリ「Evernote Touch」
Integrity Levelが通常のWin32App同様「Medium」になっているのが判ります。



従って、Anniversary Update では「権利を制限されたStoreApp / UWP App」と「これまでのWin32と同じ権限で動くConverted App」が同じストアに並ぶ事になります。
今迄培ってきた「ストアから入れるアプリは大体安全」という評判をこれからも維持できるのか、個人的には危惧している所です。（※３）



※１ ドキュメント・ピクチャライブラリ等は、事前に「Capability」として宣言することで、AppContainerの権限が拡張され、アクセス可能になります。また、それ以外のフォルダ・ファイルについては、「ユーザーがファイルダイアログで指定したら」以降はアクセス可能になります。重要なのは、ユーザーの許可・または操作が無い限りはアクセスできない、という点です。

※２ レジストリアクセスは仮想化され、DLL等のロードはApp-V型のIsolatedなFolderから行われますが、プロセスからのファイルアクセス自体は通常のIL Midで行われます。また、Desktop App Converterで作成されたPackageはWin32と同時にUWP Appも含むことが可能で、こちらはもちろんApp Container で動作します。

※３ 匿名でのアプリ配布が行いにくく、また何時でもMSにより配布を止められるストア経由の配布である、という担保はあります。


誤解3 「MSIから変換」について


Desktop App Converter では、概ね以下のようにAppXパッケージを作ります。
  1. まず、素の仮想OSイメージがあります。OSインストール直後のまっさら環境です。
  2. この環境に対して、既存のインストーラでWin32 Appをインストールします。この作業は仮想環境上で行われます。
  3. インストーラが終了コード0を吐く等して終了します。それを受け、Desktop App Converter はインストーラが終わったな、判断して記録が終わります。インストール前後での変更差分がAppXとしてパッケージングされます。
ここで重要なのは、2と3において「インストーラの形式」は全く気にされていない所です。インストーラ自体はMSIだろうがWIXだろうがInstall Shield 6.3系だろうがNull Softだろうがバッチファイルだろうがどうでもよく、最後に終了コードを吐いてインストール終了が判ればそれでよい、です。
また、この仕組み…仮想のOSイメージに対して展開したアプリ、を差分としてパッケージングして配布…により、普通のインストーラとはまた違った注意が必要になります。

例えば…インストーラの中で、MSIならCustom Action、Install ShieldならScript…等により「システムの状態」…空き容量、ファイル、あるDLLがインストールされているか、レジストリフラグが立っているか…を見てインストールの動作を変える、インストールするパッケージを変更する、という仕組みを使っている場合は多いかと思います。

 ですが、このDesktop App Converter では、この「インストーラの独自ロジック」が走るのはユーザーのシステム上ではなく、あくまで変換時の「素の仮想OSイメージ」に対してのみです。このため、「インストール先の状態を見て何かするロジック」は成立しないと考えるべきです。

◇◇◇

…長い。読んでくれる人おられるのだろうか。Centennialは面白いのでつい話が長くなります。Desktop App Converterの利点、長所についてはまた機会がありましたら。

投稿者 時刻:
ラベル:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)