「魂の叫び」を含む別の記事でこのメモを書くように促されました。まあ、何かが変更されたときにWindowsが再起動を必要とするのはなぜですか（通常、プログラムのインストール/アンインストールですが、他のケースもあります）？ なぜWindowsアプリケーション開発者はそのような吸盤であり、Linuxプログラム開発者（「通常のプログラム」をインストールするときにそのようなメッセージがない）ですか？
この現象は誰もが長い間知っていましたが、彼の「脚がどこから成長するのか」、そしてなぜ他のオペレーティングシステム（Linux、MacOS Xなど）で、そのようなウィンドウはWindowsで例外的で永続的なものなのか疑問に思ったことはありますか？
いいえ、それは「不正なソフトウェアライター」だけの責任ではありません。主な欠点はマイクロソフトにあります。 これらの無限の要求はすべて、20年以上前に行われたMS DOS設計の誤りと壊れたウィンドウの理論の組み合わせです。 マイクロソフトにとっては暑い時期でした。今日のようなモンスターではありませんでした。間違いを犯すことはできず、何年もの間皆をオフにするものを開発してから、前のバージョンのエラーを修正する次のバージョンのOSをリリースしました（Windows98 => Windows98SE、Windows Vista => Windows 7など）。 したがって、ローカルネットワークのサポートで何かをする必要があり、当時のリーダー（ネットワークオペレーティングシステムNetwareとNovellであった）を少なくとも合理的なものと対照する必要があった場合、長い間デザインを考える必要はありませんでした-それは最も簡単なことでしたほとんど間違いなくエラーや苦情なしで動作します。 ユーティリティSHARE.EXEがMS-DOSに登場し、複数のプログラムを同時に使用できるようになりました（最初は-MS DOSがシングルタスクのままであったため、後で-Windowsが普及した後、別のコンピューターでのみ）、同じプログラムがコミットされました間違い、その結果は今日まで解き明かされました。 さらに、そのときの間違いの恐怖に誰も気づきませんでした。
間違いは何でしたか？ Aと言って、MicrosoftはBとは言いませんでした。MicrosoftがUnixから主な機能である階層ファイルシステムをコピーしたとき（MS DOSの最初のバージョンにはこの機能さえなかったと思いますか？）、簡単にするために、そこから重要なアイデアをコピーしませんでした： 「ファイル」と「ファイル名」の概念の分離。 Unixでは、これらの概念は分離されています。 ファイル（または、むしろinode ）があり、その名前（ディレクトリ内のエントリ）があります。 iノードへのアクセス権とファイル名へのアクセス権は、一般的には相互接続されていません（実際、後でいくつかの制限を導入する必要がありましたが、これは別の話です）。 主なことは、プログラムがファイルを開いた場合で、それが排他モードで開いた場合でも、これはディレクトリ内のエントリへのアクセス権には適用されません。 これはどういう意味ですか？ これは、特に、任意のファイルを「削除」して（実際、このファイルが使用されている場合-これがスワップファイルである場合-使用されるまで削除されない）、その場所に新しいファイルを作成できることを意味します（実際、別の場所に新しいファイルが作成される可能性が高い-しかし、ここではディレクトリ内のエントリがそこに配置される）。 MS DOSでは、SHARE.EXEプログラム（およびWindows VistaやWindows 7などのOSのカーネルを含むそのすべての子孫）はそのようには動作しません。 ファイルへのアクセスがブロックされると、その名前へのアクセスもブロックされます！ MS-DOS（各ファイルに1つの名前のみを許可するFATファイルシステム）では論理的に見え、NTFSでは既に奇妙に見えました（ファイルに新しい名前を付けることはできますが、古い名前は削除できません）多くのプログラムがこれに依存しているため（20年以上前に決定が下されたと思います）。
このエラーの結果は何ですか？ 結果は最も深刻です。 Windows上の多くのファイルは（システムで使用されるため）操作中にまったく変更できないため、この問題を回避するためのいくつかのメカニズムが提案されています。 レジストリでファイル（ドライバーなど）の名前を指定し、更新時に新しいファイル/ディレクトリを作成し、再起動時（または別の「都合のよい時間」）に古いファイル/ディレクトリを削除できます。このアプローチは、特に.NETで使用されます。 再起動後にファイルを簡単に置き換えることができますが、これを行うことができる特別な「パッチ」が必要であるため（Windowsの場合）、すべてが単純ではありませんが、主なことは、その順番を待っている「更新済み」ファイルが通常の場所に表示されないことです。それが何であるかは不明です。したがって、多くのインストールプログラムは、「再起動後の構成変更の注文」のキューが空ではないことを検出し、単に再起動を強制します。 一般に、多くのことができ、実行されていますが、それでも、プログラムのインストールには再起動が必要な場合があります（開発者がこれを予見している場合）、または（IMNSHOの方が悪い場合）再起動には必要ありませんが、プログラムは動作しません。 再起動する前にインストールされたプログラムが動作し、その後壊れたときに最も楽しいです。 これは、あるプログラムが「再起動後に」特定の変更を命じ、別のプログラムのインストーラーがこれらの変更を考慮せずに2番目のプログラムをインストールしたときに発生します（それらは表示されません-それらはキューにあります！2番目のプログラムはユーザーを刺激しないように強制的に再起動を強制しませんでした！）再起動後、システムがクラッシュしました。 「壊れたウィンドウ理論」が最後のポイントです。問題のいくつかの解決策がシステムの再起動だけで、それ以外の場合は、開発者の生活を単純化する他の場合に再起動を必要としないのはなぜですか？
Unix（および、それに応じて、Linuxおよび/またはMacOS）では、状況は完全に異なります：ファイルはいつでも 「改善バージョン」に置き換えることができます（これを行うための十分な権限がある場合）。したがって、ほとんどのプログラムをインストールする場合、再起動は必要ありません-もちろん開発者は他の場合にそれを避けようとします...
残念ながら、最近Linuxでバーを下げ始めました。システムを停止せずに、または少なくともXを再起動せずに、KDE 3.xからKDE 4.xに切り替えてみてください。 これはそれほど単純ではなく、多くの松葉杖を必要とします...しかし、いずれにしても、そのような状況は、Linux / MacOS /などでWindowsよりもはるかに少ない頻度で発生します。 Windowsには、その祖先であるMS DOSから継承された「DNAエラー」があるためです。
この物語は私たちに何を教えてくれますか？ 設計エラーが異なるという事実：後で簡単に修正できるものもあれば、何十年も続くものもあります...それらを区別することを学ぶだけです...
DNAの間違い、または間違ったデザインが何百万もの損失につながる可能性がある
All Articles