WindowsはまだDLLを使用しており、MacプログラムはDLLをまったく使用していないようです。どちらかの手法を使用することのメリットまたはデメリットはありますか？
プログラムのインストールに必要なすべてのDLLが含まれているため、100％正常に機能する場合、すべてのライブラリを静的にリンクするのと同じでしょうか。
8112 次
9 に答える
12
MacOS Xは、他の種類のUnixと同様に、DLLの単なる別の形式である共有ライブラリを使用します。
また、DLLまたは共有ライブラリコードを複数のプロセス間で共有できるため、どちらも有利です。これは、OSがDLLまたは共有ライブラリをロードし、それを使用するプロセスの仮想アドレス空間にマッピングすることによって行われます。
于 2009-06-02T11:27:46.783 に答える
1
Windowsでは、GDIおよびUSERライブラリはDLLとしてのみ使用できるため、動的にロードされるライブラリを使用する必要があります。動的ロードを含まないプロトコルを使用して、これらのいずれかをリンクしたり、それらと通信したりすることはできません。
他のOSでは、複雑なアプリに対してとにかく動的読み込みを使用する必要があります。そうしないと、正当な理由もなくバイナリが肥大化し、長期的にはアプリがシステムと互換性がなくなる可能性が高くなります（ただし、短期的には静的リンクすると、ライブラリの小さな重大な変更からある程度保護できます）。また、それらに依存するOSのプロプライエタリライブラリにリンクすることはできません。
于 2009-06-02T11:31:00.253 に答える
1
WindowsはまだDLLを使用しており、MacプログラムはDLLをまったく使用していないようです。どちらの手法を使用することのメリットとデメリットはありますか？
ソフトウェアの更新が容易になるため、どのような種類のモジュール化も適しています。つまり、プログラムのバグが修正された場合に、プログラムのバイナリ全体を更新する必要はありません。一部のdllにバグが表示された場合は、dllのみを更新する必要があります。
imoの唯一の欠点は、プログラムの開発に別の複雑さを導入することです。たとえば、dllがacまたはc ++ dllの場合、異なる呼び出し規約などです。
プログラムのインストールに必要なすべてのDLLが含まれている場合、それはすべてのライブラリを静的にリンクすることと同じですか？
多かれ少なかれはい。静的リンクを想定しているdllで関数を呼び出しているかどうかによって異なります。dllは、LoadLibrary（）やGetProcAddress（）などを介してのみアクセスできる「独立した」ダイナミックライブラリである可能性もあります。
于 2009-06-02T11:35:07.673 に答える
1
共有ライブラリ（WindowsではDLL、Unixでは.so）の大きな利点の1つは、ライブラリとそのコンシューマーを個別に再構築できることです。静的ライブラリでは、ライブラリを再構築してから、すべてのコンシューマーを再リンクする必要があります。これは、Unixシステムでは非常に低速です。 Windowsではそれほど高速ではありません。
于 2009-06-02T11:35:25.050 に答える
1
MacOSソフトウェアも「dll」を使用します。名前が異なるだけです（共有ライブラリ）。
ソフトウェアのさまざまなコンポーネントで再利用したいコードがある場合、DLLは理にかなっています。ほとんどの場合、これは大きなソフトウェアプロジェクトでは理にかなっています。
静的リンクは、コードを再利用する必要がない場合、小さな単一コンポーネントアプリケーションに適しています。コンポーネントに外部依存関係がないため、配布が簡素化されます。
于 2009-06-02T11:40:32.373 に答える
0
メモリ/ディスクスペースの使用に加えて、共有ライブラリを使用するもう1つの重要な利点は、ライブラリの更新が、ライブラリを使用するシステム上のすべてのプログラムによって自動的に取得されることです。
InfoZIP ZIPライブラリにセキュリティの脆弱性があった場合、DLL / .soを更新すると、これらを使用するすべてのソフトウェアが自動的に安全になりました。静的にリンクされたソフトウェアは再コンパイルする必要がありました。
于 2009-06-02T11:44:17.560 に答える
-1
はい、このテキストを参照してください：
ダイナミックリンクには次の利点があります
。メモリを節約し、スワッピングを減らします。多くのプロセスは、メモリ内のDLLの単一のコピーを共有して、単一のDLLを同時に使用できます。対照的に、Windowsは、静的リンクライブラリで構築された各アプリケーションのメモリにライブラリコードのコピーをロードする必要があります。
ディスクスペースを節約します。多くのアプリケーションは、ディスク上のDLLの単一のコピーを共有できます。対照的に、静的リンクライブラリで構築された各アプリケーションには、個別のコピーとして実行可能イメージにリンクされたライブラリコードがあります。
DLLへのアップグレードは簡単です。DLL内の関数が変更された場合、関数の引数と戻り値が変更されない限り、それらを使用するアプリケーションを再コンパイルまたは再リンクする必要はありません。対照的に、静的にリンクされたオブジェクトコードでは、関数が変更されたときにアプリケーションを再リンクする必要があります。
アフターマーケットサポートを提供します。たとえば、ディスプレイドライバDLLを変更して、アプリケーションの出荷時に使用できなかったディスプレイをサポートすることができます。
多言語プログラムをサポートします。異なるプログラミング言語で記述されたプログラムは、プログラムが関数の呼び出し規約に従っている限り、同じDLL関数を呼び出すことができます。プログラムとDLL関数は、次の点で互換性がある必要があります。関数が引数をスタックにプッシュすることを期待する順序、関数またはアプリケーションがスタックのクリーンアップを担当するかどうか、引数が渡されるかどうかレジスタ内。
MFCライブラリクラスを拡張するメカニズムを提供します。既存のMFCクラスからクラスを派生させ、MFCアプリケーションで使用するためにそれらをMFC拡張DLLに配置できます。
国際版の作成を容易にします。DLLにリソースを配置することにより、アプリケーションの国際バージョンを作成するのがはるかに簡単になります。アプリケーションの各言語バージョンの文字列を個別のリソースDLLに配置し、異なる言語バージョンに適切なリソースをロードさせることができます。
DLLを使用することの潜在的な欠点は、アプリケーションが自己完結型ではないことです。別のDLLモジュールの存在に依存します。
于 2009-06-02T11:41:46.910 に答える
-1
WindowsはまだDLLを使用しており、MacプログラムはDLLをまったく使用していないようです。どちらの手法を使用することのメリットとデメリットはありますか？
どちらも共有ライブラリを使用しており、異なる名前を使用しているだけです。
プログラムのインストールに必要なすべてのDLLが含まれているため、100％正常に機能する場合、すべてのライブラリを静的にリンクするのと同じでしょうか。
幾分。ライブラリをプログラムに静的にリンクすると、単一の非常に大きなファイルが取得され、DLLを使用すると、多くのファイルが作成されます。
静的にリンクされたファイルには、「共有ライブラリの解決」ステップ（プログラムのロード中に発生します）は必要ありません。ずっと前に、静的プログラムをロードするということは、プログラム全体が最初にRAMにロードされ、次に「共有ライブラリの解決」ステップが発生することを意味していました。現在、実際に実行されるプログラムの部分のみがオンデマンドでロードされます。したがって、静的プログラムでは、DLLを解決する必要はありません。DLLを使用すると、一度にすべてをロードする必要はありません。したがって、パフォーマンスに関しては、同等である必要があります。
これは「DLL地獄」を残します。Windows上の多くのプログラムは、必要なすべてのDLLを持ってきて、それらをWindowsディレクトリに書き込みます。正味の効果は、最後にインストールされたプログラムが機能し、他のすべてが壊れている可能性があることです。ただし、簡単な回避策があります。DLLをEXEと同じディレクトリにインストールします。Windowsは最初に現在のディレクトリを検索し、次にさまざまなWindowsパスを検索します。このようにすると、ディスクスペースが少し無駄になりますが、プログラムは機能し、さらに重要なことに、他のものを壊すことはありません。
Windowsディレクトリに（同じバージョンで）すでに存在するDLLをインストールするべきではないと主張する人もいるかもしれませんが、そうすると、必要なバージョンを首を折るようなもので上書きする悪いアプリに対して再び脆弱になります。欠点は、アプリのセキュリティ修正を自分で配布する必要があることです。コードを保護するためにWindowsUpdateなどに依存することはできません。これはタイトな場所です。クラッカーはセキュリティの問題から多くのお金を稼いでおり、セキュリティ修正をすぐに発行しなかったため、誰かが銀行のデータを盗んだときに人々はあなたを気に入らないでしょう。
アプリケーションを非常に緊密に、たとえば20年間サポートすることを計画している場合は、プログラムディレクトリにすべてのDLLをインストールするのが適切です。そうでない場合は、すべてのDLLの適切なバージョンがインストールされていることを確認するコードを記述し、ユーザーにそのことを知らせて、アプリが突然クラッシュし始める理由をユーザーに知らせます。
于 2009-06-02T12:24:00.523 に答える
-1
私の見解では、共有コンポーネントにはいくつかの利点がありますが、欠点として認識されることもあります。
- 共有コンポーネントは、プロセス内のインターフェイスを定義します。そのため、どのコンポーネント/インターフェイスを外部に表示し、どのコンポーネント/インターフェイスを非表示にするかを決定する必要があります。これにより、どのインターフェイスが安定している必要があり、どのインターフェイスが安定している必要がなく、コンポーネント外のコードに影響を与えることなくリファクタリングできるかが自動的に定義されます。
- C++およびWindowsの場合のメモリ管理は十分に検討する必要があります。したがって、通常は、同じdllで解放されていないdllの外部でメモリを処理するべきではありません。これを行うと、次の場合にコンポーネントが失敗する可能性があります。異なるランタイムまたはコンパイラバージョンが使用されている。
したがって、共有コンポーネントを使用すると、ソフトウェアをより適切に整理するのに役立つと思います。
于 2009-06-03T08:54:59.347 に答える