デスクトップアプリケーション強化への動きを強める
当初、マイクロソフトは、各種のブリッジソフトウェアを利用することで、AndroidやiOSのアプリケーションを簡単にUWP化してWindows 10へ持ってこられるようにして、アプリケーションの充実を図る計画だった。
そのために、Project Astoria(Android Bridge for Windows)やProject Islandwood(Windows Bridge for iOS)の開発が発表されていたが、Android Bridge for Windowsは2016年に開発中止。Windows Bridge for iOSは、iOS側の開発環境が変わったこともあり、オープンソース化した。
一方で、デスクトップアプリをMicrosftストアで扱える形式に変換する「Windows Bridge for Classic Windows アプリ(Project Centennial)」は残った。しかも、もはやデスクトップアプリケーションを「Classic Windows アプリ」とは呼ばなくなり、「デスクトップブリッジ」「デスクトップAPPコンバーター」といった名称になっている。
デスクトップアプリケーションの配布には、マイクロソフトはほとんど関わってこなかった。このため、いわゆる「フリーソフト」「オンラインソフト」としてインターネットでファイルとして流通が行われ、有償のソフトウェアは自身で販売サイトを立ち上げたり、販売ではなく寄付を依頼するという形式も取られた。
これに対して、デスクトップアプリケーションをMicrosoftストアで扱うことができるAppX形式にパッケージすることが可能になる。これならばデスクトップアプリの流通・販売をMicrosoftストア経由ででき、アップデートなどもMicrosoftストアで可能になっている。
デスクトップブリッジがリリースされたのち、マイクロソフトは段階的にUWPとデスクトップアプリの連携を強化してきた。現在では、UWPアプリからデスクトップアプリを起動したり、相互に連携して動作することも可能になっている。こうした強化は、当初、デスクトップアプリケーションのUWP化を促進するために作られた。デスクトップアプリにUWP的な機能を搭載していくことで、段階的にUWPに移行させるというのが当初のシナリオだったわけだ。
そのシナリオとしては現在も残っているとは思われるが、現実にはUWPへの移行は、それほど進んでいるわけでもない。UWP化が進まない理由の1つは、UWPに課せられた制限やアプリケーションモデルにある。
従来のデスクトップアプリケーションは、ファイルに自由にアクセスし、Windowsの機能を最大限に利用するように作られた。このため、UWPが持つ制限と相容れない部分がある。逆にUWP側は、サンドボックス内での実行という原則があり、なんでもかんでも可能にするわけにもいかない部分がある。たとえばファイルには、ユーザーから許可を得た場合のみ、必要なフォルダ以下のみアクセス可能といった制限がある。

この連載の記事
-
第475回
PC
Windowsのコマンドラインの補完機能について解説 -
第474回
PC
Windowsでのコマンドラインのヒストリ機能 -
第473回
PC
Windowsは内部的にどうやってインターネットへの接続状態を確認している? -
第472回
PC
WindowsのエラーをMicrosoftに送信するテレメトリ機能を理解する -
第471回
PC
Windowsのコマンドラインでエイリアスを使う -
第470回
PC
Windows用のパッケージマネージャー「Winget」 プレビュー版で機能が充実してきた -
第469回
PC
Windows Updateの27年 悪役だった頃から改良が進んで、徐々に目立たない存在に -
第468回
PC
2025年のWindowsどうなる!? Windows Insider Programの状況をあらためて見る -
第467回
PC
Copilot+ PCのNPUでカメラを処理する「Windows Studio Effects」 その内容や効果は? -
第466回
PC
PowerToysの最近の新機能には、複数アプリを指定位置に起動する「ワークスペース」や新規作成のカスタマイズがある -
第465回
PC
WindowsのPowerShellからBluetoothデバイスを調べる - この連載の一覧へ