Loading article…
パッチとは、プログラムやファイルなどの既存のソフトウェア リソースを変更するためのデータであり、多くの場合、バグやセキュリティの脆弱性を修正するために使用されます。[ 1 ] [ 2 ]パッチを適用するとは、既存のリソースにデータを適用するプロセスでもあります。システムのパッチ適用には、パッチの適用が含まれます。パッチは、機能性、使いやすさ、またはパフォーマンスを向上させるために作成されることがあります。パッチは手動で作成することもできますが、一般的には、リソースの 2 つのバージョンを比較し、一方を他方に変換するために使用できるデータを生成するツールを使用して作成されます。
通常、パッチは変更対象となるリソースの特定のバージョンに適用する必要がありますが、例外もあります。一部のパッチ適用ツールは、既存のリソースのバージョンを検出し、複数のバージョンをサポートしている場合でも適切なパッチを適用できます。パッチがリリースされるにつれて、その累積サイズは大幅に増加し、リソース自体のサイズを超える場合もあります。これを管理するために、サポートするバージョンの数を制限したり、リソースの完全なコピーを提供したりすることがあります。
パッチ適用によってバイナリ実行ファイルを変更することが可能になります。これは技術的に難しい場合もありますが（実行ファイルの動作を深く理解する必要があるため）、ソースコードが入手できず完全な実行ファイルを作成できない場合には有効な手段となり得ます。また、完全なファイルを配布するよりも、より小さなファイルサイズで配布できるため、コスト削減にもつながります。
パッチは多くの場合、問題を解決することを目的としていますが、新たな問題を引き起こす可能性があります。これはソフトウェアの回帰と呼ばれる現象です。場合によっては、アップデートによって意図的に機能が無効化されることもあります。たとえば、ユーザーがライセンスを保有していない機能を削除するなどです。パッチ管理はライフサイクル管理の一部であり、どのシステムにどのタイミングでどのパッチを適用するかという戦略と計画が含まれます。通常、パッチは永続的に（つまりストレージに）適用されますが、場合によってはメモリに（デバッガなどのツールを介して）適用されることもあります。この場合、リソースがストレージから再ロードされると変更は失われます。
ソフトウェアアップデートは、同義語ではないにもかかわらず、パッチと混同されることがあります。アップデートは、パッチファイルとパッチ適用プロセスを使用して実装できます。また、パッチ適用はファイルの内容を変更することだけに限定されず、ファイル全体を追加、削除、置換することもパッチ適用であると主張する人もいます。通常、パッチは比較的小さな変更を意味するため、サイズや範囲が大きいパッチは、より一般的なソフトウェアアップデート、またはサービスパックなどのより具体的な名前で呼ばれることがあります。Windows NTとその後継バージョン ( Windows 2000、Windows XP、Windows Vista、Windows 7を含む) はサービスパックを使用します。[ 3 ]歴史的に、IBM はこのようなアップデートにFixPakおよびCorrective Service Disketteという用語を使用していました。 [ 4 ]
歴史的に、ソフトウェアベンダーはパッチを紙テープやパンチカードで配布し、受信者が元のテープ（またはデッキ）の指定された部分を切り取り、交換用のセグメントをパッチする（そのため「パッチ」という名前がついた）ことを想定していた。後のパッチ配布では磁気テープが使用された。その後、リムーバブルディスクドライブが発明されると、ソフトウェア開発者からディスク、あるいは後にCD-ROMを介して郵送でパッチが送られるようになった。インターネットが広く普及すると、開発者のWebサイトからパッチをダウンロードしたり、自動ソフトウェアアップデートを利用したりすることがエンドユーザーにとって容易になった。AppleのMac OS 9とMicrosoftのWindows ME以降、PCオペレーティングシステムはインターネット経由で自動ソフトウェアアップデートを取得する機能を獲得した。
コンピュータプログラムは、対象プログラムを更新するためのパッチ適用を連携して行うことができる場合が多い。自動化によってエンドユーザーの作業は簡素化され、更新プログラムを実行するだけで済む。その後、そのプログラムが対象プログラムの更新を完全かつ正確に行う。Microsoft Windows NTとその後継バージョン、および多くの商用ソフトウェア製品のサービスパックは、このような自動化戦略を採用している。
一部のプログラムは、ユーザーの介入をほとんど、あるいは全く必要とせずに、インターネット経由で自動的にアップデートできます。サーバーソフトウェアやオペレーティングシステムのメンテナンスは、多くの場合この方法で行われます。システム管理者が複数のコンピュータを管理している場合、このような自動化は一貫性の維持に役立ちます。セキュリティパッチの適用も、一般的にこの方法で行われます。
より大容量の記憶媒体と高速なインターネット帯域幅の出現に伴い、特に小規模なプログラムにおいては、既存のファイルを変更するのではなく、ファイル全体（あるいはプログラムのすべてのファイル）を置き換えることが一般的になった。
独自ソフトウェアのパッチは通常、ソースコードではなく実行可能ファイルとして配布されます。これらのファイルを実行すると、プログラムがメモリにロードされ、ディスク上の対象プログラムへのパッチコードのインストールを管理します。
他のソフトウェアのパッチは通常、パッチコードを含むデータファイルとして配布されます。これらのファイルは、インストールを実行するパッチユーティリティプログラムによって読み込まれます。このユーティリティは、対象プログラムの実行可能ファイル（プログラムのマシンコード）を、通常は新しいパッチコードを表すバイトで上書きすることによって変更します。新しいコードが古いコードが占めていた領域（バイト数）に収まる場合は、古いコードを直接上書きして配置することができます。これはインラインパッチと呼ばれます。新しいコードが古いコードよりも大きい場合は、パッチユーティリティは、新しいコードを含むロードレコードを、パッチ適用対象プログラムのオブジェクトファイルに追加します。パッチ適用されたプログラムが実行されると、実行は新しいコードに向けられ、古いコードの中で新しいコードが必要な箇所には、分岐命令（ジャンプまたは呼び出し）がパッチされます。例えばRadio Shack TRS-80のような初期の8ビットマイクロコンピュータでは、オペレーティングシステムにPATCH/CMDユーティリティが含まれており、テキストファイルからパッチデータを受け取り、対象プログラムの実行可能バイナリファイルに修正を適用します。
パッチコードは、実行時に実行されるメモリ領域を確保する必要があります。インラインパッチは難しくありませんが、追加のメモリ領域が必要な場合は、プログラマーが工夫する必要があります。当然ながら、パッチを適用するコードを最初に作成したプログラマーであれば、これは容易です。熟練したプログラマーは、最終的なイテレーションを作成する際に使用しないメモリを後で拡張するために確保することで、この必要性を事前に計画します。元の実装に関与していない他のプログラマーが、後で変更を組み込む場合、必要な追加バイト分の領域を見つけるか、確保する必要があります。この場合、最も幸運なのは、パッチを適用するルーチンが独立したモジュールである場合です。この場合、パッチを適用するプログラマーは、モジュールが占める領域を他のシステムコンポーネントに通知するポインターまたは長さインジケータを調整するだけで済みます。その後、拡張されたパッチコードでこのメモリ領域を自由に埋めることができます。パッチを適用するルーチンが独立したメモリモジュールとして存在しない場合、プログラマーは、拡張されたパッチコードのための十分な領域を確保するために、ルーチンを縮小する方法を見つける必要があります。一般的な対策としては、より効率的な命令シーケンスを見つけること（またはより効率的なアルゴリズムを用いて再設計すること）によってコードを短縮する、メッセージ文字列やその他のデータ領域を圧縮する、プログラム機能を大容量ストレージ（ディスクオーバーレイなど）に外部化する、あるいはパッチでインストールする変更よりも重要度が低いと判断されるプログラム機能を削除する、といったことが挙げられます。
メモリ内の小さなマシンコードパッチは、CP/MのDDTやMS-DOSのDEBUGデバッガなどのシステムデバッグユーティリティを使用して手動で適用できます。インタプリタ型BASICで作業するプログラマは、システムサービスルーチンやインタプリタ自体の機能を変更するためにPOKEコマンドをよく使用しました。
ソースコードのパッチとは、コードファイルのテキストをどのように変更するかを定義するものです。このようなパッチは通常、ファイルの2つのバージョン間の差分をエンコードしたテキストファイルです。この種のパッチは多くの場合diffコマンドによって作成されるため、パッチファイルも差分ファイルとなります。
ソースコードのパッチ適用は、オープンソースソフトウェアプロジェクトではよくあることです。メンテナーはパッチを受け取ったり、人々がパッチを公開したりすることで、問題点が修正され、プロジェクトのロケール以外の地域言語のサポートなど、機能が追加されます。Linuxカーネルの初期開発（完全なソースコードを公開したことで知られています）の例では、オリジナルの開発者であるリーナス・トーバルズは、多くのプログラマーから何十万ものパッチを受け取り、自身のオリジナルバージョンに適用しました。
Apache HTTP Server は、もともとBrian Behlendorf がNCSA HTTPd を改善するためにまとめた多数のパッチから発展したため、パッチの集合体であることを示唆する名前 ( 「パッチだらけのサーバー」 ) が付けられました。プロジェクトの公式サイトの FAQ には、「Apache」という名前はネイティブアメリカンのアパッチ族への敬意から選ばれたと記載されています。しかし、「パッチだらけのサーバー」という説明は、当初プロジェクトの Web サイトで提供されていました。[ 5 ]
{{cite web}}: CS1 maint: bot: 元の URL の状態が不明です (リンク)