UWPアプリとしてのR2DBの今後

この記事について

ここでは、「Desktop Bridgeを使用したUWP環境」・「標準のインストール手順」という条件のもとに動作するmicrosoft-edgeスキームリダイレクトについて試行錯誤したログ。
※ここでのUWPはコンテナ版のみではなくDesktop Bridgeを含むappx/msixパッケージ化済みアプリを指す

想定していた方針

microsoft-edgeスキームの呼び出し元(例:Win+Rの際のexplorer.exe)の、CreateProcessをフックし、開く対象と引数を監視する。 一致した時に引数などを上書きする。 これにより、本来はmsedge.exeが開かれるべき部分で別のブラウザを指定したりURLの置換を行ったりできる。 概略図

なにがダメなのか

主に2つ

  • リアルタイムでのプロセスの起動の監視が困難
  • CreateProcessの呼ばれない場合の存在

1つめのプロセスの監視について、上の図で①として示した対象プロセスへの侵入であるが、プロセスの起動前に確実に行えるような手法はユーザー権限では存在しないようである。 そのため、現在はWMIのWin32_Processオブジェクトの作成をポーリング(割り込みではない)にて検知している。 よって1秒ごとや0.5秒ごとなどで確認をすることになる。 しかし、edgeを開くために別のプログラムを開いてそこから起動するようなプログラムの場合は侵入が間に合わない。 そのため、一回目の起動ではそのままedgeが開き、二回目以降は動くような挙動となる。 (explorerのヘルプボタンがこれに該当し、「helppane.exe」がボタン押下直後にedgeを起動する。)

2つめについて、ShellExecuteを含む基本的なプロセスの作成方法では最終的にCreateProcessが呼ばれる。 しかし、一部のプログラムにおいては呼ばれないようである。 (「SearchApp」(スタート横の検索)が該当し、「sihost.exe」が起動していることは判明しているがsihostではCreateProcess(A/W)は呼び出されないようだ。 また、「helppane.exe」や「sihost.exe」の起動に関しても検知できないが、これは「svchost.exe」が起動を代理していることが原因である。)

起動元にプログラムに働きかける方式はユーザ権限で動き、edgeの余計な起動を起こさない手法ということで実装していたが、権限的な限界というよりAPIや挙動的な問題が大きかった。

今後の方針

現状だと先発のMSEdgeRedirectにてIFEOとして説明されているImage File Execution Optionsを用いたで手法で検討中。 UWPを前提とした懸念点は下の3つ。

  • レジストリの編集
  • 要管理者権限(レジストリ・edgeのコピー)
  • コンピュータ単位(非ユーザ単位)でのインストール

一つ目の時点で無理そうなのでUWPは諦めた上で作成することになると見込まれる。 普通に要管理者なmsiベースのインストーラを準備して、普通にWebサイトで細々と公開、msiをStoreに投げるだけ投げて許可されれば非UWPアプリとしてWindows Storeに戻れるかもしれないという感じ。

IFEOの挙動について詳しくないし、代替アプリは多数あると思うのでのんびりと作成したい。

再読み込み