هل MSVCRT ضمن Windows مثل glibc (libc) ضمن *nix؟

Question

كثيرًا ما أصادف برامج Windows التي يتم تجميعها في MSVCRT (أو ما يعادلها أكثر حداثة) مع الملفات التنفيذية للبرنامج.على جهاز كمبيوتر نموذجي، سأجد العديد من النسخ من نفس ملفات .DLL.ما أفهمه هو أن MSVCRT هي مكتبة وقت التشغيل C، وهي تشبه إلى حد ما glibc/libc.so ضمن *nix.

لماذا يتعين على برامج Windows إحضار مكتبات C الخاصة بها معها، بدلاً من مجرد مشاركة libc على مستوى النظام؟

---

تحديث:بفضل Shog9، بدأت القراءة عن SxS، مما فتح عيني على مشكلات ربط DLL (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx هي مقدمة مفيدة للمسألة..

Answer 1

[أنا المشرف الحالي على تقنية Native SxS في Microsoft]

يتم إصدار إصدارات جديدة من MSVCRT مع إصدارات جديدة من Visual Studio، وتعكس التغييرات التي تم إجراؤها على مجموعة أدوات C++.بحيث يمكن للبرامج المجمعة مع إصدارات VS التي تم إصدارها بعد استمرار إصدار معين من Windows أن تعمل في المستوى الأدنى (مثل مشاريع VS 2008 على نظام التشغيل Windows XP)، فإن MSVCRT قابل لإعادة التوزيع، لذا يمكن تثبيته هناك.

يقوم تثبيت CRT بإسقاط المكتبات في %windir%\winsxs\، وهو موقع نظام عام، يتطلب امتيازات المسؤول للقيام بذلك.

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

Answer 2

لا يوجد بالفعل "libc على مستوى النظام" في Windows.

في *nix، يوجد بشكل عام مترجم واحد، ورابط واحد، ومعهما تنسيق ملف كائن محدد جيدًا، واصطلاح استدعاء، ومواصفات تشويه الأسماء.تأتي هذه الأشياء عادةً مع نظام التشغيل.الحالة شبه الخاصة للمترجم (بالإضافة إلى التركيز على إمكانية النقل عبر نقاط * مختلفة) تعني أن بعض الأشياء يمكن أن تكون مُتوقع أن يكون موجودًا وأن يتم تسميته و/أو إصداره بطريقة تمكن البرامج من العثور عليه واستخدامه بسهولة.

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

راجع للشغل، الاسم ينبغي أن يكون دليلا هنا؛MSVCRT هو اختصار لـ "MicroSoft Visual C++ RunTime".إنها ليست في الواقع مكتبة "على مستوى النظام" بنفس الطريقة، على سبيل المثال، kernel32 هي - إنها مجرد مكتبة وقت التشغيل التي يستخدمها مترجمو MS، والتي من المفترض أنهم استخدموها عند إنشاء Windows.من الممكن أن يرتبط المترجمون الآخرون به، ولكن (1) قد تكون هناك مشكلات تتعلق بالترخيص؛و (2) سيقوم المترجمون بربط التعليمات البرمجية الخاصة بهم بـ MS - مما يعني (2 أ) أنه لم يعد لديهم أي طريقة للإضافة إلى وقت التشغيل أو إصلاح الأخطاء، دون الأمل في أن يقوم MS بإصلاحها؛و(2 ب) إذا قرر MS تغيير ما هو موجود في RTL (وهو ما يمكنهم فعله حسب الرغبة، وربما يكون ذلك في كل إصدار جديد من VC++)، أو كيفية ظهور الأسماء، فقد تتعطل تلك البرامج الأخرى.

Answer 3

اجابة قصيرة؟لأنه حتى SxS، MSVCRT لم يتم إصداره بشكل موثوق!هل يمكنك أن تتخيل الجنون الذي قد يحدث إذا كانت البرامج التي تم تجميعها واختبارها مقابل libc 5 ستبدأ بصمت في استخدام libc 6؟هذا هو الوضع الذي كنا فيه لسنوات عديدة على نظام التشغيل Windows.لن يثق معظمنا أبدًا مرة أخرى في MS مع الحفاظ على التغييرات الجذرية في الإصدار

Answer 4

ترتبط البرامج بإصدار محدد من وقت التشغيل، وهذا الإصدار المطلوب هو لا مضمونة للوجود على الجهاز الهدف.أيضًا، كانت مطابقة الإصدارات تمثل مشكلة.

في عالم Windows، من الأخلاق السيئة جدًا أن تتوقع من المستخدمين الخروج والعثور على مكتبة منفصلة وتثبيتها لاستخدام تطبيقك.عليك التأكد من تضمين أي تبعيات ليست جزءًا من النظام المضيف في تطبيقك.

في عالم Linux، لا يكون الأمر بهذه البساطة دائمًا، نظرًا لوجود تباين أكبر بكثير في الشكل الذي قد يبدو عليه النظام المضيف.