Loading article…
ポータブルアプリケーション（ポータブルアプリ）は、スタンドアロンソフトウェアとも呼ばれ、他のファイルを変更したり、他のソフトウェアをインストールしたりすることなく動作するように設計されたコンピュータプログラムです。このようにして、セットアップや副作用なしに、互換性のあるコンピュータに簡単に追加、実行、削除できます。[ 1 ]
実際には、ポータブルアプリケーションは、ユーザーが作成したデータと構成設定を、アプリケーションが存在するディレクトリと同じ場所に保存することがよくあります。これにより、ユーザーの設定とデータを含むプログラムを異なるコンピュータ間で簡単に転送できます。構成オプションを持たないプログラムもポータブルアプリケーションになり得ます。[ 1 ]
ポータブルアプリケーションは、内蔵大容量ストレージ、ファイル共有、クラウドストレージ、 USBドライブ、ペンドライブ[ 2 ]、フロッピーディスクなどの外部ストレージを含むあらゆるデータストレージデバイスに保存できます。プログラムファイルと構成情報およびデータは、ストレージメディアのみに保存されます。構成情報が必要ない場合は、ポータブルプログラムはCD-ROMやDVD-ROMなどの読み取り専用ストレージから実行できます。一部のアプリケーションは、インストール版とポータブル版の両方で提供されています。
デフォルトでは移植性を持たないアプリケーションでも、コマンドライン引数などの他のメカニズムを通じてオプションで移植性をサポートする場合があります。例えば、/portableプログラムに移植可能なプログラムとして動作するように指示したり、--cfg=/path/inifile設定ファイルの場所を指定したりすることが挙げられます。
他のアプリケーションと同様に、ポータブルアプリケーションもコンピュータシステムのハードウェアおよびオペレーティングシステムと互換性がある必要があります。
オペレーティングシステムによって、移植性の実装は多かれ少なかれ複雑になります。AmigaOSのようなオペレーティングシステムでは、すべてのアプリケーションは定義上移植可能です。
ほとんどのポータブルアプリケーションは、ホストコンピュータにファイルや設定を残したり、既存のシステムや構成を変更したりしません。アプリケーションは、Windows レジストリ[ 3 ]に書き込んだり、構成ファイル ( INI ファイルなど) をユーザー プロファイルに保存したりしない場合もありますが、今日では多くのポータブルアプリケーションがそうしています。ただし、多くのアプリケーションは、構成ファイルをポータブル ディレクトリに保存しています。ドライブ レターの割り当てが変わるため、コンピュータを変更するとファイル パスが異なることが多いため、ポータブルアプリケーションが相対形式でファイルを保存する可能性もあります。一部のアプリケーションにはこの動作をサポートするオプションがありますが、多くのプログラムはこの動作を行うように設計されていません。このようなプログラムでよく使われる手法は、ランチャー プログラムを使用して、アプリケーションの起動時に必要な設定とファイルをホストコンピュータにコピーし、アプリケーションの終了時にそれらをアプリケーションのディレクトリに戻すことです。
アプリケーションのソースコードを変更することなく、Windows内でアプリケーションの移植性を実現するための代替戦略として、アプリケーション仮想化があります。アプリケーションは、ランタイムレイヤーに対して「シーケンス化」または「パッケージ化」され、このランタイムレイヤーは、アプリケーションのファイルシステムおよびレジストリへの呼び出しを透過的に傍受し、アプリケーションが認識することなく、これらの呼び出しを他の永続ストレージにリダイレクトします。このアプローチでは、アプリケーション自体は変更されず、移植性も確保されます。
同じアプローチは、アプリケーション全体だけでなく、ランタイムライブラリ、COMコンポーネント、ActiveXなどの個々のアプリケーションコンポーネントにも使用されます。 [ 4 ]その結果、個々のコンポーネントがこのように移植されると、元のポータブルアプリケーションに統合したり、相互に競合することなく、同じオペレーティングシステム(OS) 上で異なる構成/設定で繰り返しインスタンス化 (仮想的にインストール) したりすることが可能になります。移植されたコンポーネントは OS で保護されている関連エンティティ (レジストリとファイル) に影響を与えないため、コンポーネントのインストールと管理に管理者権限は必要ありません。
Microsoft は、2005 年という早い時期から、Windows オペレーティングシステム用のアプリケーション固有のレジストリの必要性を認識していました。[ 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
ディレクトリパスが変化する場合でも、ユーザー操作（スクリプトや環境変数の変更など）を必要としないLinuxアプリケーションは、相対ライブラリ検索パスを許可するGCCリンカーオプションを使用することで実現できます。 [ 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 の精神と文字面にも完全に準拠するようになりました。
Linuxコミュニティは、その無限の知恵で、CDEを激しく非難し続けます。[...]「私たちは皆、パッケージ管理を使用すべきです。」私が言いたいことは、そして私の言葉が小さな石板に書かれて山頂から運ばれてくることを願います。パッケージ管理は万能薬ではありません。
の言うことが正しいとすれば、Autopackage の真の教訓は、ソフトウェアのインストールを改善する方法ではなく、Linux の歴史のこの段階で大規模なアーキテクチャ変更を行うことの難しさ、あるいは不可能性にある。かつては非常に有望に見えたプロジェクトにとって、これは身が引き締まるような、残念な結末である。
私は、自分が関わっている別のプロジェクト、つまりダイブログアプリでこれを直接見てきました。私たちは Windows と OSX 用のバイナリを作成しますが、基本的に Linux 用のバイナリは作成しません。なぜでしょうか? Linux デスクトップアプリケーション用のバイナリを作成するのは、とんでもなく面倒だからです。
ようやく+Subsurfaceの「AppImage」バージョンを試してみたところ、本当に「ただ動く」ようです。
アプリのメンテナーとして、私はもう自分のアプリをディストリビューションにバンドルしたくありません。全く何のメリットもないのに、あまりにも面倒です。バグ報告を受け取るたびに、私の最初の質問は「ああ、どのディストリビューションのどのバージョンですか？どのライブラリのどのバージョンですか？それらのライブラリにどのようなとんでもないパッチが適用されましたか？」です。いいえ、Windows と Mac はこれを正しく行っています。私は自分のアプリが使用するライブラリを制御します。[...] AppImage を使用すれば、まさにそれを提供できます。彼らのコンピュータで実行できるものです。