デスクトップアプリケーション強化への動きを強める
当初、マイクロソフトは、各種のブリッジソフトウェアを利用することで、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側は、サンドボックス内での実行という原則があり、なんでもかんでも可能にするわけにもいかない部分がある。たとえばファイルには、ユーザーから許可を得た場合のみ、必要なフォルダ以下のみアクセス可能といった制限がある。

この連載の記事
-
第520回
PC
WindowsターミナルのPreview版 v1.25では「操作」設定に専用エディタが導入 -
第519回
PC
「セキュアブート」に「TPM」に「カーネルDMA保護」、Windowsのセキュリティを整理 -
第518回
PC
WindowsにおけるUAC(ユーザーアカウント制御)とは何? 設定は変えない方がいい? -
第517回
PC
Windows 11の付箋アプリはWindowsだけでなく、スマホなどとも共有できる -
第516回
PC
今年のWindows 11には26H2以外に「26H1」がある!? 新種のCPUでのAI対応の可能性 -
第515回
PC
そもそも1キロバイトって何バイトなの? -
第514回
PC
Windows用のPowerToysのいくつかの機能がコマンドラインで制御できるようになった -
第513回
PC
Gmailで外部メール受信不可に! サポートが終わるPOPってそもそも何? -
第512回
PC
WindowsのPowerShellにおけるワイルドカード -
第511回
PC
TFS/ReFS/FAT/FAT32/exFAT/UDF、Windows 11で扱えるファイルシステムを整理する -
第510回
PC
PowerShellの「共通パラメーター」を理解する - この連載の一覧へ











