خدمات استدعاء المنصة

خدمات استدعاء النظام الأساسي ، والتي يشار إليها عادةً باسم P/Invoke ، هي ميزة من ميزات تطبيقات البنية التحتية للغة المشتركة ، مثل وقت تشغيل اللغة المشتركة من Microsoft ، والتي تُمكّن التعليمات البرمجية المُدارة من استدعاء التعليمات البرمجية الأصلية .

توفر لغات البرمجة المُدارة، مثل C# أو VB.NET، وصولاً أصلياً إلى الفئات والأساليب والأنواع المُعرّفة ضمن المكتبات التي تُشكّل إطار عمل .NET. ورغم أن إطار عمل .NET يُوفّر مجموعة واسعة من الوظائف، إلا أنه قد يفتقر إلى الوصول إلى العديد من مكتبات نظام التشغيل منخفضة المستوى، والتي تُكتب عادةً بلغة برمجة غير مُدارة، أو مكتبات الطرف الثالث المكتوبة أيضاً بلغة برمجة غير مُدارة. يُعدّ P/Invoke الأسلوب الذي يُمكن للمبرمج استخدامه للوصول إلى الدوال في هذه المكتبات. يتم استدعاء الدوال داخل هذه المكتبات من خلال تعريف توقيع الدالة غير المُدارة ضمن الكود المُدار، والذي يُمثّل الدالة الفعلية التي يُمكن استدعاؤها كأي أسلوب مُدار آخر. يُشير التعريف إلى مسار ملف المكتبة، ويُحدّد مُعاملات الدالة وقيمتها المُعادة في أنواع مُدارة، والتي يُرجّح أن يتم تحويلها ضمنياً من وإلى الأنواع غير المُدارة بواسطة بيئة تشغيل اللغة العامة (CLR). عندما تصبح أنواع البيانات غير المُدارة معقدة للغاية بحيث لا يمكن إجراء تحويل ضمني بسيط من وإلى الأنواع المُدارة، يسمح الإطار للمستخدم بتحديد سمات على الدالة، والقيمة المرجعة، و/أو المعلمات لتحسين كيفية ترتيب البيانات بشكل صريح حتى لا تؤدي إلى استثناءات عند محاولة القيام بذلك ضمنيًا.

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

When using P/Invoke, the CLR handles DLL loading and conversion of the unmanaged previous types to CTS types (also referred to as parameter marshalling).^[1]To perform this, the CLR:

• Locates the DLL containing the function.
• Loads the DLL into memory.
• Locates the address of the function in memory and pushes its arguments onto the stack, marshaling data as required.

P/Invoke is useful for using standard (unmanaged) C or C++DLLs. It can be used when a programmer needs to have access to the extensive Windows API, as many functions provided by the Windows libraries lack available wrappers. When a Win32 API is not exposed by the .NET Framework the wrapper to this API must be written manually.

Writing P/Invoke wrappers can be difficult and error prone. Using native DLLs means that the programmer can no longer benefit from type safety and garbage collection as is usually provided in the .NET environment. When they are used improperly this may cause problems such as segmentation faults or memory leaks. Getting the exact signatures of the legacy functions for use in the .NET environment can be hard, which can result in such problems. For this purpose tools and websites exist to obtain such signatures, helping to prevent signature problems.

Other pitfalls include:

• Incorrect data alignment of user-defined types in the managed language: there are different ways data can be aligned depending on compilers or compiler directives in C and care must be taken to explicitly tell the CLR how to align data for non-blittable types. A common example of this is when trying to define a data type in .NET to represent a union in C. Two different variables overlap in memory, and defining these two variables in a type in .NET would cause them to be in different locations in memory, so special attributes must be used to correct the issue.
• تداخل جامع البيانات المهملة في اللغة المُدارة مع موقع البيانات: إذا كان مرجعٌ ما محليًا لدالة في .NET وتم تمريره إلى دالة أصلية، فعند انتهاء الدالة المُدارة، قد يستعيد جامع البيانات المهملة هذا المرجع. لذا، يجب الحرص على تثبيت مرجع الكائن ، لمنع جمعه أو نقله بواسطة جامع البيانات المهملة، مما قد يؤدي إلى وصول غير صالح من قِبل الوحدة الأصلية.

عند استخدام C++/CLI، يكون CIL المُصدر حرًا في التفاعل مع الكائنات الموجودة في الذاكرة المُدارة، وفي الوقت نفسه مع أي موقع ذاكرة أصلي قابل للعنونة. يمكن استدعاء كائن موجود في الذاكرة المُدارة، أو تعديله، أو إنشاؤه، باستخدام صيغة "object->field;" البسيطة لتعيين القيم أو تحديد استدعاءات الدوال. ينتج عن ذلك تحسينات كبيرة في الأداء بفضل التخلص من أي تبديل سياق غير ضروري، وانخفاض متطلبات الذاكرة (مكدسات أقصر).

وهذا يأتي مصحوباً بتحديات جديدة:

• يكون الكود عرضة لظاهرة التفكير المزدوج ^{[ 2 ]} إذا لم يتم معالجتها بشكل محدد
• مشكلة قفل اللودر ^{[ 3 ]}

تُحدد هذه المراجع حلولاً لكل مشكلة من هذه المشكلات في حال ظهورها. ومن أهم مزاياها الاستغناء عن تعريف البنية، وعدم وجود مشكلات تتعلق بترتيب تعريف الحقول والمحاذاة في سياق C++ Interop.

There are a number of tools which are designed to aid in the production of P/Invoke signatures.

Writing a utility application that would import C++ header files and native DLL files and produce an interface assembly automatically turns out to be quite difficult. The main problem with producing such an importer/exporter for P/Invoke signatures is the ambiguity of some C++ function call parameter types.

Brad Abrams has this to say on the subject:^[4]

The problem lies with C++ functions like the following:

__declspec(dllexport)voidMyFunction(char*params);

What type should we use for the parameter params in our P/Invoke signature ? This could be either a C++ null terminated string, or could be a char array or could be an output char parameter. So should we use string, StringBuilder, char[] or ref char ?

Regardless of this issue, there are a few tools available to make the production of P/Invoke signatures simpler.

One of the tools listed below, xInterop C++ .NET Bridge has resolved this issue by implementing multiple overrides of the same C++ method in .NET world, developers can then pick the correct one to make the call.

• Blittable types
• Java Native Interface, the standard way for Java programs to access native code
• Java Native Access, the Java equivalent of P/Invoke
• Windows library files
• J/Direct, the no-longer maintained equivalent API for Microsoft Java Virtual Machine

• A site devoted to P/Invoke