ربط ثابت أو ديناميكي بين CRT وMFC وATL وما إلى ذلك

Question

في التسعينات عندما بدأت استخدام MFC لأول مرة، كنت أقوم بربط تطبيقاتي ديناميكيًا وشحن ملفات MFC DLL ذات الصلة.تسبب لي هذا في بعض المشكلات (DLL hell!) وتحولت إلى الارتباط الثابت بدلاً من ذلك - ليس فقط لـ MFC، ولكن لـ CRT وATL.بخلاف ملفات EXE الأكبر حجمًا، لم يسبب لي الارتباط الثابت أي مشكلات على الإطلاق - فهل هناك أي جوانب سلبية واجهها أشخاص آخرون؟هل هناك سبب وجيه لإعادة النظر في الارتباط الديناميكي مرة أخرى؟تطبيقاتي هي بشكل أساسي STL/Boost في الوقت الحاضر FWIW.

Answer 1

هناك بعض السلبيات:

• حجم أكبر لـ exe (خاصة إذا قمت بشحن ملفات exe متعددة)
• مشاكل في استخدام ملفات DLL الأخرى التي تعتمد على الارتباط الديناميكي أو تفترضه (على سبيل المثال:ملفات DLL التابعة لجهات خارجية والتي لا يمكنك الحصول عليها كمكتبات ثابتة)
• أوقات تشغيل c مختلفة بين ملفات DLL ذات الارتباط الثابت المستقل (لا يوجد تخصيص/إلغاء تخصيص عبر الوحدات النمطية)
• لا توجد خدمة تلقائية للمكونات المشتركة (لا توجد قدرة على مطالبة مورد الوحدة الطرفية الثالث بتحديث التعليمات البرمجية الخاصة به لإصلاح المشكلات دون إعادة ترجمة التطبيق الخاص بك وتحديثه)

نقوم بإجراء ربط ثابت لتطبيقات Windows الخاصة بنا، وذلك في المقام الأول لأنه يسمح بنشر xcopy، وهو أمر غير ممكن مع تثبيت SxS DLL أو الاعتماد عليه بطريقة تعمل، نظرًا لأن العملية والآلية غير موثقة جيدًا أو يمكن إزالتها بسهولة.إذا كنت تستخدم ملفات DLL المحلية في دليل التثبيت، فسوف تعمل نوعًا ما، ولكنها غير مدعومة بشكل جيد.إن عدم القدرة على إجراء التثبيت عن بعد بسهولة دون المرور عبر MSI على النظام البعيد هو السبب الرئيسي لعدم استخدامنا للارتباط الديناميكي، ولكن (كما أشرت) هناك العديد من الفوائد الأخرى للارتباط الثابت.هناك إيجابيات وسلبيات كل منها؛نأمل أن يساعد هذا في تعدادهم.

Answer 2

تتضمن معظم الإجابات التي أسمعها حول هذا الأمر مشاركة ملفات dll الخاصة بك مع برامج أخرى، أو تحديث ملفات dll هذه دون الحاجة إلى تصحيح برامجك.

بصراحة أنا أعتبر هذه سلبيات وليست إيجابيات.عندما يتم تحديث ملف dll لجهة خارجية، فإنه يمكن أن يتغير بدرجة كافية لتعطيل برنامجك.وفي هذه الأيام، لم تعد مساحة القرص الصلب ثمينة كما كانت من قبل، فهل تريد 500 ألف إضافية في ملفك القابل للتنفيذ؟من يهتم؟

• يعد التأكد بنسبة 100% من إصدار dll الذي يستخدمه برنامجك أمرًا جيدًا.
• إن التأكد بنسبة 100% من أن العميل لن يعاني من صداع التبعية هو أمر جيد.

الإيجابيات تفوق بكثير السلبيات في رأيي

Answer 3

وطالما كنت حفاظ على استخدامك يقتصر على بعض المكتبات وعدم استخدام أي دلل على ذلك يجب أن تكون جيدة.

ولسوء الحظ، هناك بعض المكتبات التي لا يمكنك ربط بشكل ثابت. وأفضل مثال لدي هو قانون الزواج. إذا كنت من الاستفادة من دعم قانون الزواج البصرية استوديو، سيكون لديك للتأكد من تثبيت وقت التشغيل (في هذه الحالة vcomp.dll).

إذا كنت لا تستخدم في DLL ثم لا يمكن تمرير بعض البنود ذهابا وإيابا دون بعض الجمباز خطيرة. الأمراض المنقولة جنسيا :: سلاسل تتبادر إلى الذهن. إذا اكس ودلل ترتبط بشكل حيوي ثم تخصيص يقام في في CRT. خلاف ذلك البرنامج قد يحاول تخصيص سلسلة من جهة وإلغاء تخصيص ذلك من جهة أخرى. أشياء سيئة تترتب على ذلك ...

وقال ذلك، ما زلت ربط ثابت بلدي إكس وودلل. فإنه لا يقلل الكثير من variablilty في تثبيت وأنا أعتبر أن تستحق بعض القيود.

Answer 4

واحد ميزة جيدة استخدام ودلل هي أنه إذا العمليات التي متعددة يحمل نفس دلل يمكن مشاركة رمزها بينهما. وهذا يمكن حفظ الذاكرة وتقصير مرات التحميل لتطبيق تحميل DLL الذي يتم استخدامه بالفعل من قبل برنامج آخر.

Answer 5

لا، لا شيء جديد على هذا الصعيد. تبقى على هذا النحو.

Answer 6

وبكل تأكيد.

ويتم تخصيص على كومة "ثابتة". منذ تخصيص ينبغي أن يتم على إلغاء تخصيص على نفس كومة، وهذا يعني أنه إذا كنت تقوم بشحن مكتبة، يجب أن تأخذ الرعاية التي رمز العميل لا يمكن استدعاء "الخاص بك p = new LibClass() وحذف هذا الكائن نفسه باستخدام delete p;.

واستنتاجي: إما تخصيص درع وإلغاء تخصيص من رمز العميل، أو حيوي ربط CRT

.

Answer 7

وهناك بعض تراخيص البرمجيات مثل LGPL التي تتطلب منك إما استخدام DLL أو توزيع التطبيق الخاص بك كملفات الكائن الذي يمكن للمستخدم ربط معا. إذا كنت تستخدم مثل هذه المكتبة، وسوف ربما كنت ترغب في استخدامه بمثابة DLL.