
ポータブルアプリケーション(ポータブルアプリ)は、スタンドアロンソフトウェアとも呼ばれ、他のファイルを変更したり、他のソフトウェアをインストールしたりすることなく動作するように設計されたコンピュータプログラムです。そのため、互換性のあるコンピュータであれば、セットアップや副作用なしに簡単に追加、実行、削除できます。[ 1 ]
実用的には、ポータブルアプリケーションは、ユーザーが作成したデータや設定を、アプリケーション本体と同じディレクトリに保存することがよくあります。これにより、ユーザーの設定やデータを含むプログラムを、異なるコンピュータ間で簡単に転送できるようになります。設定オプションを持たないプログラムも、ポータブルアプリケーションになり得ます。[ 1 ]
ポータブルアプリケーションは、内蔵大容量記憶装置、ファイル共有、クラウドストレージ、 USBドライブ、ペンドライブ[ 2 ] 、フロッピーディスクなどの外部記憶装置など、あらゆるデータ記憶装置に保存できます。プログラムファイル、設定情報、データは、記憶媒体にのみ保存されます。設定情報が不要な場合は、CD-ROMやDVD -ROMなどの読み取り専用記憶装置から実行できます。一部のアプリケーションは、インストール版とポータブル版の両方で提供されています。
デフォルトでは移植可能ではないアプリケーションの中には、他のメカニズム(最も一般的なものはコマンドライン引数)を通じてオプションの移植性をサポートしているものもあります。例えば、/portableプログラムに移植可能なプログラムとして動作するように指示したり、--cfg=/path/inifile設定ファイルの場所を指定したりすることが挙げられます。
他のアプリケーションと同様に、ポータブル アプリケーションは、コンピュータ システムのハードウェアおよびオペレーティング システムと互換性がある必要があります。
移植性の実装はオペレーティング システムによって多少複雑になりますが、AmigaOSなどのオペレーティング システムでは、すべてのアプリケーションは定義上移植可能です。
ほとんどのポータブルアプリケーションは、ホストコンピュータにファイルや設定を残さず、既存のシステムやその構成も変更しません。アプリケーションは、Windows レジストリ[ 3 ]に書き込んだり、構成ファイル ( INI ファイルなど) をユーザのプロファイルに保存したりしませんが、今日では多くのポータブルアプリケーションがこれを行います。ただし、多くのアプリケーションは依然として構成ファイルをポータブルディレクトリに保存しています。別の可能性としては、ドライブ文字の割り当ての違いによりコンピュータを変更するとファイルパスが異なることが多いため、ポータブルアプリケーションがそれらを相対形式で保存することがあります。一部のアプリケーションにはこの動作をサポートするオプションがありますが、多くのプログラムはこれを行うように設計されていません。このようなプログラムでよく使用される手法は、ランチャープログラムを使用して、アプリケーションの起動時に必要な設定とファイルをホストコンピュータにコピーし、終了時にそれらをアプリケーションのディレクトリに戻すことです。
Windows 内でアプリケーションの移植性を実現する代替戦略として、アプリケーションのソースコードを変更することなく、アプリケーション仮想化があります。アプリケーションはランタイム層に対して「シーケンス化」または「パッケージ化」され、ランタイム層はファイルシステムとレジストリの呼び出しを透過的にインターセプトし、アプリケーションが認識することなく、それらを他の永続ストレージにリダイレクトします。このアプローチでは、アプリケーション自体は変更されませんが、移植性は確保されます。
アプリケーション全体だけでなく、ランタイムライブラリ、COMコンポーネント、ActiveXといった個々のアプリケーションコンポーネントにも同様のアプローチが用いられます。 [ 4 ]その結果、個々のコンポーネントをこのように移植することで、オリジナルの移植可能なアプリケーションに統合したり、同じオペレーティングシステム(OS)上で異なる構成/設定で繰り返しインスタンス化(仮想インストール)したりすることができ、相互に競合することはありません。移植されたコンポーネントはOSによって保護された関連エンティティ(レジストリやファイル)に影響を与えないため、インストールや管理に管理者権限は必要ありません。
マイクロソフトは、Windowsオペレーティングシステムにアプリケーション固有のレジストリが必要であることを2005年という早い時期から認識していました。[ 5 ]最終的に、この技術の一部を、前述の技術を用いたアプリケーション互換性データベース[ 6 ]とDetours [ 7 ]コードライブラリを通じてWindows XPに組み込みました。ただし、この技術はシステムAPI経由では提供されませんでした。
Unixライクなベースを念頭に書かれたプログラムは、多くの場合、何の前提も置きません。多くのWindowsプログラムは、ユーザーが管理者であることを前提としています。これはWindows 95 / 98 / MEの時代では広く普及していました( Windows XP / 2000でもある程度は管理者ですが、 Windows VistaやWindows 7ではそうではありません)。しかし、Unixライクな環境では、ユーザーが権限のない状態になる頻度がはるかに高いため、このような状況ではすぐに「アクセスが拒否されました」というエラーが発生します。そのため、プログラムは通常、設定を保存するためにHOME環境変数を使用するように設計されています(w3m$HOME/.w3mブラウザなど)。ダイナミックリンカーは、プログラムが非標準ディレクトリからライブラリをロードするために使用できる環境変数を提供します。移植可能なプログラムと設定が含まれていると仮定すると、コマンドラインは次のようになります。 LD_LIBRARY_PATH/mnt
HOME=/mnt/home/user LD_LIBRARY_PATH=/mnt/usr/lib /mnt/usr/bin/w3m www.example.com
相対的なライブラリ検索パスを可能にするGCCリンカーオプションを使用すると、さまざまなディレクトリパスでユーザーインタラクション(スクリプトや環境変数の調整など)を必要としないLinuxアプリケーションを実現できます。 [ 8 ]$ORIGIN
すべてのプログラムがこれを尊重するわけではありません。一部のプログラムは $HOME を完全に無視し、代わりにユーザー検索を行って/etc/passwdホーム ディレクトリを検索するため、移植性が損なわれます。
Autopackage、AppImage 、CDE など、管理者権限を必要としないクロスディストリビューションパッケージ形式もありますが、2000 年代の Linux コミュニティでは限定的に受け入れられ、サポートされていました。[ 9 ] [ 10 ] [ 11 ] 2015 年頃、 Linus Torvalds がDebConf 2014でこのトピックについて説明し、後にダイビング ログアプリケーションSubsurfaceにAppImageを支持したことで、Linux エコシステム向けのポータブルでディストリビューションに依存しないパッケージ化のアイデアはより注目を集めるようになりました。[ 12 ] [ 13 ] [ 14 ]例えば、MuseScoreとKrita は2016 年に続き、ソフトウェアの展開に AppImage ビルドを使い始めました。[ 15 ] [ 16 ] RedHat は 2016 年にFlatpakシステムをリリースしました。これは、 klik (現在は AppImage と呼ばれています) に触発されたAlexander Larsson のglickプロジェクトの後継です。 [ 17 ]同様に、Canonicalは2016年にUbuntuや他の多くのLinuxディストリビューション向けのSnapパッケージをリリースしました。
ドラッグアンドドロップでインストールできる多くの Mac アプリケーションは、Mac アプリケーションバンドルとして本質的に移植可能です。[ 18 ]例としては、Mozilla Firefox、Skype、Google Chromeなどが挙げられます。これらは管理者アクセスを必要とせず、中央の制限された領域に配置する必要もありません。/Users/username/Applications( ~/Applications) に配置されたアプリケーションは、メインフォルダに配置されたアプリケーションと同じように、macOS LaunchServices に登録されます/Applications。たとえば、Finder でファイルを右クリックし、「このアプリケーションで開く...」を選択すると、/Applications と ~/Applications の両方から利用できるアプリケーションが表示されます。開発者は、ユーザーがホームディレクトリにインストールを実行できる Mac 製品のインストーラーを作成できます。インストーラーのユーザーインターフェイスには、「私だけのためにインストール」というラベルが付いています。[ 19 ]このようなインストールは、ユーザーが実行します。
特別なキーワード $ORIGIN を使うと、「実行ファイルの実際の場所からの相対パス」を指定できます。ところが、突然 -rpath $ORIGIN/lib が使えることに気づき、それがうまく動作するようになりました。ゲームは正しいライブラリをロードしていたため、安定性と移植性が向上し、LGPLの文面だけでなく精神にも完全に準拠するようになりました。
コミュニティは、その無限の知恵で、CDEを徹底的に批判し続けています。[...] 「私たちは皆、パッケージ管理を使うべきです。」 私が言いたいのは、小さな石板に刻まれた私の言葉が山頂から伝わってくることです。パッケージ管理は万能薬ではありません。
の言う通りなら、Autopackageから得られる真の教訓は、ソフトウェアのインストールをいかに改善するかではなく、Linuxアーキテクチャの大規模な変更がこれほど後進的な段階になってから困難に、あるいは不可能に思える点にある。かつては期待されていたプロジェクトにとって、これは厳粛で残念な結末と言えるだろう。
私が関わっている別のプロジェクト、つまりダイビングログアプリで、この現象を目の当たりにしました。私たちはWindowsとOSX用のバイナリを作っていますが、Linux用のバイナリは基本的に作っていません。なぜでしょうか? Linuxデスクトップアプリケーションのバイナリを作るのは、本当に面倒だからです。
ようやく +Subsurface の「AppImage」バージョンを試すことができましたが、本当に「問題なく動作する」ようです。
アプリのメンテナーとして、もう自分のアプリをディストリビューションにバンドルしてほしくありません。メリットが全くないのに、あまりにも手間がかかりすぎます。バグレポートを受け取るたびに、まず「どのディストリビューションのどのバージョン? どのライブラリのどのバージョン? それらのライブラリにはどんなひどいパッチが適用されたの?」と尋ねます。いいえ、WindowsとMacはこれを正しく処理します。アプリが動作するライブラリは私が管理します。[...] AppImageを使えば、まさにそれを提供できます。彼らのコンピューターで動作するもの。