デスクトップアプリケーション強化への動きを強める
当初、マイクロソフトは、各種のブリッジソフトウェアを利用することで、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側は、サンドボックス内での実行という原則があり、なんでもかんでも可能にするわけにもいかない部分がある。たとえばファイルには、ユーザーから許可を得た場合のみ、必要なフォルダ以下のみアクセス可能といった制限がある。
この連載の記事
-
第464回
PC
Windows 10のサポート切れまで1年を切った さてWindows 10マシンをどうする? -
第463回
PC
Windows Terminal Preview版でSixelグラフィックスを実際に表示させてみる -
第462回
PC
Windows Terminal Preview版でSixelグラフィックスを扱う -
第461回
PC
Copilot+ PCを買ってみたが、「今焦って買う必要はない」のかもしれない -
第460回
PC
Windowsでsftpを使う -
第459回
PC
WSL 2.4.4ではtar形式でのディストリビューションが配布でき、企業での利用が容易になってきた -
第458回
PC
Windows上でhostsファイルを活用する -
第457回
PC
IPv6アドレスは先頭を見ればどんな種類かわかる -
第456回
PC
あらためてIPv6基本のキ -
第455回
PC
Windowsで現在どのネットワークアダプタがインターネット接続に使われているかを調べる方法 -
第454回
PC
Windows 11 24H2では「デバイスの暗号化」の条件が変わり、より多くのPCでドライブが暗号化される - この連載の一覧へ