すべてのアプリケーションが「ポータブル」ではないのはなぜですか？
私は最近、Windowsマシンに「インストール」することを大幅に減らし（インストーラーが嫌いです。プログラムがどこにインストールするかを知る必要があります...）、代わりにポータブルバージョンまたはスタンドアロンバージョンのアプリケーションを使用することを選択しました。
私はそれらをすべてWindowsパーティションとは別のドライブの「プログラム」ディレクトリに配置しているので、再インストールするたびに、最小限の労力ですべてのアプリケーションを利用でき、プラス面として、すてきなクリーンなセットアップが得られます。
OfficeやCreativeSuiteのようなアプリケーションでは、システム全体に数千のランダムなライブラリとツールがスローされる、非常に長いインストールプロセスを実行する必要があります。
Windowsアプリをインストールする必要があるのはなぜですか？ PhotoshopをOSXのフォルダにドラッグして、機能させることができないのはなぜですか？他の誰かがポータブルアプリに焦点を当てていますか、それとも私はすべてについてOCDになっていますか？
インストーラーは何年にもわたる進化の結果であり、少しの（単純化された）歴史は彼らが何をするのかを理解するのに役立ちます。
Windows 3.1モデルでは、アプリケーションごとにconfig.iniスタイルの構成ファイルが提案されており、重複やディスク領域の浪費を防ぐために、システムフォルダーに入る共有ライブラリがサポートされています。
Windows 95では、多くの構成ファイルを置き換えるアプリケーション構成の中央ストアを可能にするレジストリが導入されました。さらに重要なことに、Windowsの構成は同じ場所に保存されていました。
アプリケーションが後でクリーンアップされなかったため、レジストリが肥大化しました。 DLL地獄は、同じ共有ライブラリの複数のバージョンが互いに上書きした結果として発生しました。
.NETはapp.configの概念を導入しました（ほとんどのiniファイルは2をマークしますが、今回は構造を少し増やして、開発者が手動パーサーを作成する時間を無駄にします）。 GACは、DLL地獄を防ぐために、バージョン共有アセンブリに導入されました。
Windows XPなどVistaでは、Microsoftはユーザースペースを単一の標準的な場所にユーザーデータと構成ファイルを保存する場所として定義し、ローミングプロファイルと簡単な移行を可能にしようとしました（プロファイル）プログラムファイルにインストールされているアプリケーションを使用します。
したがって、その理由は、「Windowsのアプリケーションはある場所に存在し、それらの共有依存関係は別の場所にあり、ユーザー固有のデータは別の場所にあるように設計されている」ためだと思います。これは、単一の場所をxcopyするという概念に反します。
..それは、ユーザーアカウントを構成し、セキュリティアクセス許可を設定および確認し、更新プログラムをダウンロードし、Windowsサービスをインストールする前です...
xcopyは「単純なケース」であり、すべてに最適というわけではありません。
XCOPYデプロイメント は、数年前に未来の方法としてMicrosoftによって発表されました。まだ何もありません:)
それまでの間、PortableApps.comプラットフォームに興味があるかもしれません。
すばらしい質問です。少し前にStackOverflowで 関連する質問 を質問しました。
答えはしばしば「それが私たちが過去にそれをした方法だから」であるように思われます。申し訳ありませんが、それは私と一緒に洗うことはありません。
他の数人は、主な理由はレジストリによるものだと言っています。デバイスドライバやその他のCOMコンポーネントなどについて話している場合は、そうする必要があるかもしれませんが、ワードプロセッサやスプレッドシートなどのGUIアプリケーションでは必要ありません。
起動時に必要なレジストリ設定をチェックし、ユーザーにそれらの設定を求める/デフォルトを使用するアプリケーションを作成することはかなり可能です。または、現在多くのprotableアプリが行っているように、jstは、ポータブルモードで実行しているため、OS統合が現在制限されていることをユーザーに通知します。
インストーラーは、多くの場合、アプリケーションがどのように機能するかについて多くの「知識」を持っています。その後、アプリケーションが変更されると、インストーラーも更新しなければならないことがよくあります。これは、私の時間プログラミングで見たバグ/問題の典型的な原因です。
それはワンサイズフィットのすべてのアプローチです。
単純で率直な答え：それは単に誰がコントロールできるかという問題です。最近のほとんどのソフトウェアは、企業や組織の環境向けに企業の巨人によって設計されており、ユーザーはコンピューターに何をすべきかを指示するのではなく、何をすべきかを指示されます。
あなたの質問は、古い社会のような暴君によってではなく、企業の欲望と多くを支配する少数の人々の必要性によってますます侵食されている個人の権利と自由についての根本的な質問を提起するので、非常に重要です。
実のところ、IBMのような巨人の専制政治を非難していたのとまったく同じ人々が今日の時代のIBMになったことを忘れているようです...マイクロソフトの商慣行をよく見てください、= AppleとAdobeは、いくつか例を挙げて、制限付きライセンスを使用すると、IBMのビジネス慣行よりも良性であると率直に言ってくれます。同じIBMは、そのオープン性によって、実際にパーソナルコンピューティング革命...
私は何年にもわたって多くの自己完結型のポータブルアプリを使用してきましたが、例外なく、フットプリントとリソースの点で最も効果的で、最速で、最小であることが証明されています。最後になりましたが、ブロートウェアよりも優れているだけではありません。対応するものですが、ほとんどの場合、それらも無料です。
第二のパーソナルコンピュータ革命の時が来ました。肥大化を減らし、設定が保存されている場所を明確にすることで移植性を強化することは、有形の物理的な媒体上の別個の物理的な場所にある1つの別個のフォルダーで、正しい方向への一歩です。
レジストリとユーザーごとのストレージの組み合わせ。 registry は、特にアプリケーションが [〜＃〜] com [〜＃〜] ベース（レジストリで発生する登録が必要）である場合に重要です。ユーザーごとのストレージ（構成など）も重要なコンポーネントです。これを行う唯一の良い方法は、特別に設計されたディレクトリに保存することです（ 分離ストレージ を参照）。
主にWindowsレジストリが原因です。プログラムが特定のディレクトリにある場合でも、設定はレジストリに保存されることがよくあります。
また、プログラムがインストールディレクトリ以外のコンピュータ上の他のディレクトリ（たとえばsystem32）にファイルを配置することが原因である可能性もあります。
Xcopy /ポータブルインストールタイプに対するインストーラーの大きな利点の1つは、自己修復です。
Windowsインストーラシステムを適切に使用するアプリは、それに関するあらゆる種類の情報をマシンのWindowsインストーラデータベースに保存し、セットアップファイルの重要な部分のキャッシュを保持することがよくあります。
アプリが何らかの理由で壊れた場合（他の何かがファイルを削除/置換したり、レジストリが破損したり、ディスクの問題が発生したり、ユーザーがショートカットを削除したりするなど）、アプリが「アドバタイズされたショートカット」である場合、インストーラーは起動するたびに実際にキーファイルとキーをチェックします。それらが存在しない場合は置き換えます。または、[プログラムの追加と削除]に移動して、アプリの[修復]をクリックします。
多くのWindowsアプリケーションは、SQL Server、IIS、WMI、セキュリティドメイン、Active Directory、その他多くのシステム環境またはサービスを利用する必要があります。一般的なユーザーは、これらを構成する方法がわからない場合や、アクセスできない場合があります。
MicrosoftOfficeのようなアプリケーションは単一のファイルではありません。それらには、数十のファイル、実行可能ファイル、ユーティリティ、サービス、テンプレート、プラグイン、ドライバーなどが含まれています。アプリケーションをインストールするとき、新しいアプリが使用するすべてのものを単に上書きすることはできません。それは、すでに存在するものに適合している必要があります。 Windowsインストーラーは、ファイルをコピーするだけでなく、システム環境にクエリを実行し、スクリプトを実行してサービスをインストールし、管理者であるかのようにマシンをセットアップできます。
dbkk101は、Windowsアプリが「すべてがうまくいくことができない」理由を尋ねます。彼らはそうすることができます、それはインストーラーが何のためであるかです。
これは、アプリが必要とする大量のcruftwindowsアプリに部分的に関係していると思います。たとえば、レジストリキー、ユーザーデータ（/ Users // AppData）。おそらく、OSXはこれをより適切に/異なる方法で処理します。
繰り返しになりますが、アーカイブから抽出できるアプリを作成することは不可能ではありません。その場合、私はいつも満足しています。
.Net Frameworkは、このタイプの機能を有効にするためのプラットフォームであり、通常のユーザーが慣れているため、ほとんどの場合、インストーラーが使用されます。 MacユーザーがファイルをApplicationsフォルダーにコピーするのと同じ方法です。
インストーラーの大部分は、ファイルをProgram Filesフォルダーに展開し、ショートカットを作成するだけです。これはユーザーが知っていることのケースであり、多くの場合、アプリケーションが移植可能であっても、プロセスを同じに保つ方が簡単です。
一部のプログラムでは当然のことながら、インストールはばかげていますが、「ファイルをプログラムディレクトリにドラッグする」だけではありません。
少なくとも、インストールファイルを解凍し、適切なショートカットを設定して、不要になったときにプログラムを簡単に削除できる適切なインストーラー。私は解凍を考え、コピーがおそらく最も時間がかかるものです。
次に、共有ファイルがあります。これは、Windows IMOではそれほど多くはありませんが、Linuxの世界では特に当てはまります。
最も重要なことは、一部のプログラムはマシン用に構成する必要があり、一部（少なくとも私は推測する）はマシンに基づいて最適化を試みるか、少なくともAdobeのダイアログが私に信じさせるものです。
また、別のパーティションにインストールする理由は見たことがありません。すべてのレジストリ値と構成設定を失う傾向があります。さらに、私は実際に損失がWindowsの膨張を減らすのでそれを好む。
一部のプログラムでは、インストール場所がレジストリにある必要がありますが、他のプログラムでは、場所がプログラムにハードコードされている場合があります（これは、Perl.exeの場合です）。
基本的に、主な理由は、簡単な方法を取り、レジストリキーまたは実際のハードコードされたパスのいずれかをプログラムにハードコードしたプログラマーです。