لماذا اختارت Microsoft STDCALL كاتفاقية API الخاصة بهم؟

Question

هل هناك سبب وجيه؟

هل وظائفها الداخلية (غير مصدرة) أيضا اتفاقية stdcall؟

Answer 1

لقد كان تكيفًا مع اتفاقية استدعاء Pascal للرمز 32 بت. كان Pascal هو اتفاقية استدعاء أنظمة التشغيل 16 بت مثل OS/2 و Windows 3. لماذا تم اختيار Pascal قليلاً من التخمين ، حتى أنني كنت جروًا صغيرًا في ذلك الوقت ، لكنه أكثر كفاءة. وهو ما كان مهمًا عندما كان 640 كيلو بايت هو كل ما كان عليك العمل معه.

معظم وظائف Win32 ليست حقيقية STDCALL لأنها تصف أيضًا كيفية تزيين الوظيفة المصدرة قبل تقديمها إلى الرابط. مثل Mumble void (int arg) يصبح _mumble@4. الرقم بعد @ يصف حجم إطار التنشيط. ولكن يتم تصدير معظم وظائف Win32 دون أي زخرفة. ربما لمنح المبرمج فرصة قتال لجعل العمل getProcaddress (). أعتقد أن الديكور كان يهدف إلى مساعدة الرابط على اكتشاف عدم التطابق بين توقيع وظيفة API المعلن والواقع الفعلي. وجود عدم تطابق في عدد الحجج التي تم تمريرها هو kaboom التلقائي لأن callee سوف تظهر أكثر أو أقل من الحجج خارج المكدس ثم تم تمريرها. من الصعب تشخيصها أيضًا. نقطة ضعف في stdcall ، فإن اتفاقية CDECL ليس لديها هذه المشكلة.

الاتصال الداخلي هو حقيبة مختلطة بين stdcall و CDECL و ThisCall. لا يمكنني القول أنني اكتشفت نمطًا على الإطلاق ، على الرغم من أن رمز Windows أحادي الطبقات ليس شيئًا أستمتع به.

Answer 2

الكود الذي تم تجميعه باستخدام STDCALL أصغر بكثير من الكود الذي تم تجميعه باستخدام CDECL (البديل). في الوقت الذي تم فيه اتخاذ القرار ، كان رمز أصغر هو رمز أسرع.