サイトアイコン Embarcadero RAD Studio, Delphi, & C++Builder Blogs

Windowsの主役は再びネイティブ開発に

Embarcadero Japan Support
windows 11 widgets screen 1000x563

ここ数週間の間に、Windowsの開発に関して、Microsoftから過去の方向性を一部覆すような発表がいくつかありました。Microsoftは、UWP(Universal Windows Platform)モデルを（完全に非推奨ではないにしても）軽視する方向にあるようです。

以下、UWPに関連する英語のリンクをいくつかご紹介します。

UWPは、Windows 8がリリースされて以来、Microsoftがアプリケーション開発として注力してきたWinRT技術で、いずれWindowsの開発プラットフォームの主力である.NETアーキテクチャから置き換わると考えられていました。

しかしMicrosoftからUWPに関する推進が縮小されたことで、従来のネイティブ Windows開発モデルにフォーカスしてきた開発者（およびEmbarcaderoなどの開発ツールベンダー）の視点から見ると、非常に興味深い進化であり、20年ぶりにネイティブ開発がWindowsの主要な開発モデルとして復活したことになります。

ネイティブ開発は、Delphi/C++Builderが最も得意とする分野となりますので、私たちは長い時間を経て再びWindows開発の主役に返り咲いたのです。

ネイティブから.NET、そしてUWPへ

以下、簡単ですが、Microsoftが行なった迷走の歴史について触れたいと思います。

長年にわたり、従来のWindows APIを使用し、3つのコアとなるKernel/User/GDIライブラリとそのすべての拡張機能を活用したネイティブ開発モデルは、いずれ非推奨とされる古いスタイルのアプローチであると考えられてきました。このアプローチとはDelphiやC++Builder（VCLライブラリの使用)だけでなく、Visual C ++（MFCライブラリの使用）でも同様です。

Windowsの開発者は当初、.NETへの移行を推奨されていました（将来のプラットフォームAPIは.NETを必要とし、従来のアプリケーションはある時点でWindows上で動作しなくなると考えられていました）。その後、時間が経過しましたが、実際そのような状況にはなっていません。

.NETをフォーカスとした取り組みが一段落すると、Microsoftは次のアイデアとしてUniversal Windows Platformモデルにフォーカスしました。

これは主に2つのアイデアによって推進されています。1つは、デスクトップPCだけでなく、Windows Phone、ゲーム機、ハイパーバイザー技術でも同じアプリケーションを実行できること、もう1つは、基盤となるオペレーティングシステムへのアクセス制限で、より安全なプラットフォームを実現することでした。APIレベルでは、UWPをサポートするには、従来のWindows APIとは異なる互換性のないWinRTプラットフォームAPIを使用する必要がありました。

このためUWPへ移行するにはハードルが高く、Microsoftの目的とは裏腹に移行が進みません。DelphiやRAD Studioにはもともと選択肢がありませんでしたが、Visual C ++と.NETおよびC＃からUWPへの移行には、異なるランタイムライブラリや異なるUIコントロールを使用する必要があり、既存のアプリケーションを大幅に書き換える必要がありました。

Windows 8がリリースされた当初（まだ従来のAPIアプリケーションを許可していた頃）は、Microsoftも含め、利用可能なUWPアプリはほとんど存在せず、新しいプラットフォームの機能の中には、WinRT APIを経由しないと利用できないものがありました。

そのため、開発者やツール（RAD Studioを含む）は、従来のアプリケーション内からWinRT APIを呼び出すオプションを考案しました。例えば、RAD StudioのWindows通知のサポートは、このアプローチで実装されています。

Microsoftは引き続きUWPを推し進め、従来のアプリケーションが非推奨になることを開発者に向けて再三アナウンスしてきました。しかし開発者はそのことにあまり耳を傾けませんでした。

そこでMicrosoftは次なるステップとして、いわゆる「デスクトップブリッジ」の推進でした。つまり、ネイティブアプリケーションがより多くのWinRT APIを利用できるようにし、セキュリティを強化するために軽いコンテナに「「パッケージ化」する手段を促進することでした。

この最後の機能は、アプリケーションをAPPXや、その後のMSIXとしてパッケージ化することで実現されました。(RAD Studioでは、以前からIDEで直接このサポートを提供しています。)

Microsoftは当初、デスクトップブリッジは、推進しているUWPへのアプリケーションの移行を支援するためのものと説明していました。

しかしこのソリューションでは、比較的小さいプロジェクトならともかく、既存のコードベースが大規模な場合、コードを変換するためには、その規模に応じて工数が必要となるため、開発者にはあまり受け入れられず、従来のアプリケーションを選択しています。その結果、デスクトップブリッジに代わる新しいソリューション(APPXとMSIX)が登場し、従来のアプリケーション向けにMicrosoftStoreへの門が開かれました。

早いもので、ここ1年ほどのことです。Microsoftは、UWPアプリケーションがネイティブAPIを呼び出し、ネイティブアプリケーションが任意のUWP APIを呼び出すための完全な相互運用性を提供することを目的として、Project Reunion（現在はWindows App SDKとしてブランド名を変更）を発表しましたが、結局、ネイティブアプリケーションのサポートの方が優先され、UWPは取り残される結果となりました。

ネイティブ開発、再び・・

言い換えれば、Microsoftは15年以上もの間、Windowsのネイティブアプリケーションは脇役に徹し、影からWindows開発を支えてきましたが、現在では、その立場が完全に逆転したことになります。

ネイティブアプリケーション、つまり従来のAPIのアプリケーションはその威厳を取り戻し、モダナイゼーション、新しいAPIのサポート、Windows 11のサポートなどのコンテキストで優先的に扱われるようになりました。Microsoftは、UWPの機能とAPIをネイティブの世界に提供することを計画しています。

例えば、COMコンポーネントであるWebView 2コントロール（DelphiとC++BuilderがラップしてサポートするChromium Edge embedded）では、その傾向が強まっています。他の新しいAPIもCOMを使用していますが、他のAPIはネイティブであり、一部はWinRTに基づいていますが、ネイティブアプリケーションからアクセスできます。

もしお客様の既存アプリケーションにネイティブAPIモデルが残っている場合、これはDelphiとC++Builderにとって素晴らしいニュースです。ネイティブAPIモデルは、Embarcaderoが常に最優先してきたモデル（短いDelphi.NET時代を除いて）であるだけでなく、競合他社がライブラリで行ってきたことよりもはるかに多くの時間をかけて拡張、拡大してきたモデルでもあるのです。

MFCライブラリやWinFormsライブラリのような従来のAPIを使用する代替UIフレームワークを考慮すると、VCLライブラリは非常に優れています。

VCLライブラリは、UIコントロールの追加、WinRTやReunionコントロールの組み込み、高DPIのサポート、UIスタイリングなど、競合するネイティブライブラリよりもはるかに高い割合で拡張を続けています。

そのため、RAD Studioは、Windowsネイティブのクライアントアプリケーションを構築するための最良のソリューションとして位置づけられています。それだけでなく、10年前、20年前のコードベースを驚くほど簡単に移行することができ、他の製品とは比較になりません。

Microsoftは次期バージョンのWindowsでも、ネイティブのアプリケーションモデルは非推奨にされることは無く、むしろ表舞台に返り咲いたので、DelphiやC++Builderの開発者は、Windowsアプリケーションの開発における主役として活躍できることでしょう。

モバイルバージョンを終了