أساسيات البرمجه في نظام الويندوز (الجزء الأول)

نكمل ما توقفنا به الفقره الماضيه وهو موضوع الKernel Object ، حيث تبدأ رحلة برمجه الويندوز Windows System Programming من خلال معرفة كائنات الكيرنل Kernel Objects والمقابض Handle لهذه الكائنات، وهذا الموضوع يعتبر من المواضيع المهمه لأي مبرمج ويندوز. فعلى بركة الله نبدأ .

1.4. كائنات النظام Kernel Objects:

كائنات الكيرنل هي عباره عن بنية بيانات في الذاكرة ينشئها الكيرنل وهو الوحيد الذي يستطيع التعامل معها بشكل مباشر, وتتكون هذه البنية من عده حقول تحتوي على معلومات حول الكائن ، وبعض الحقول تكون موجوده في كل كائنات الكيرنل المختلفه (مثل عداد الإستخدام Usage Count و الSecurity Descriptor) . والأغلب في الحقول تكون متعلقة بالكائن نفسه مثلا الكائن من نوع Process Object يكون له معرف ID وله Exit Code وله أولويه Priority وأما الكائن من نوع File Object يكون له إزاحه Byte Offset وله طريقة للفتح Open Mode وللتشارك Share Mode. وهكذا ..

هناك العديد من كائنات الكيرنل Kernel Objects منها File و Event و Pip و Process و Thread و Semaphore و FileMapping وغيرها الكثير .

ولأن هذه الكائنات هي عباره عن بني بيانات ينشئها ويتعامل معها الكيرنل فيستحيل على التطبيقات العادية الوصول لتلك البني في الذاكرة وتعديل محتوياتها بشكل مباشر. واذا أرادت التطبيقات التعامل مع هذه البنى فهي تستخدم دوال معينه تستطيع التعامل مع تلك البني باستخدام مقبض Handle للKernel Object. فعند انشاء أي Kernel Object فسوف تعود الدالة بمقبض Handle لذلك الكائن ويمكن أن يستخدم هذا المقبض أي Thread داخل العملية .

هذه المقابض (طولها 32 بت في أنظمه 32 ) هي متعلقة بالعملية Process-Relative بمعنى في حال أرسلت هذا المقبض لThread في عملية أخرى (باستخدام أي من طرق التواصل بين التطبيقات IPC) فإن ذلك الThread لن يصل لذلك المقبض بل سيصل ربما لمقبض أخر تماما أو سوف تفشل العملية ، وسوف نوضح هذه العملية بشيء من التفصيل بعد التعرف على جدول المقابض في كل عملية Process Handle Table.

1.4.1. Usage Count:

كائنات الكيرنل يمتلكها الكيرنل وليست العملية بمعنى اذا قامت العملية باستدعاء دالة لإنشاء Kernel Object وأنتهت هذه العملية فقد يمكن أن لا يقوم النظام بحذف هذا الكائن من الذاكرة Destroy في حال كانت هناك عملية أخرى تستخدم هذا الكائن. وبالتالي لن يحذف destroy الكيرنل هذا الكائن حتى تقوم العملية التالية بالتوقف عن استخدام هذه الكائن. باختصار شديد وهي النقطة المهمه هو أن الKernel Object يمكن أن يتواجد حتى بعد انتهاء العملية التي قامت بانشائه.

ويعلم الكيرنل عدد العمليات التي تستخدم هذا الكائن من خلال الحقل Usage Count وهو يوجد في أي Kernel Object . فعندما يقوم الكيرنل بانشاء Object يتم وضع الUsage Count لها الكائن بالقيمه 1 وعندما تقوم عملية اخرى باستخدام هذا الكائن يزداد الUsage Count بواحد وهكذا. وعند تنتهي العملية يتم طرح واحد من الUsage Count من جميع الكائنات التي انشئأتها العملية. وأي كائن له Usage Count مساوي لصفر يقوم الكيرنل مباشره بتحريره من الذاكرة. وهكذا لن يبقى أي كائن في الذاكرة لا تستخدمه أي عملية.

1.4.2. Security:

يتم حمايه كائنات الكيرنل من خلال الـ security descriptor وهو يصف من الذي يملك الكائن (العملية التي أنشأته) وما هي المجموعه groups والمستخدمين Users المخولين للوصول لهذا الكائن واستخدامه وما الذين لا يحق لهم الوصول.

وكل الدوال التي تنشئ Kernel Object لها معامل وهو SECURITY_ATTRIBUTE مثلا الدالة التالية لانشاء ملف CreateFile سنجد أن هناك معامل للحماية وهكذا مع جميع الدوال التي تنشئ كائنات الكيرنل:

الشكل ‏30 يبين تصريح الدالة CreateFileA

في أغلب التطبيقات نرسل NULL لهذا المعامل وبالتالي يتم انشاء الكائن بالحماية الموجوده في العملية الحالية. واذا أردنا عمل حماية يجب عمل كائن من البنية SECURITY_ATTRIBUTES وتهيئتها ثم ارسال العنوان كمعامل لأي داله من دوال انشاء الKernel Object. ويتكون SECURITY_ATTRIBUTES من الحقول التالية:

الشكل ‏31 يبين تعريف الSECURITY_ATTRIBUTES

هناك حقل واحد من هذه الحقول متعلق بالحماية وهو lpSecurityDescriptor واذا كنا نريد تحديد الوصول للكائن فيجب انشاء SECURITY_ATTRIBUTES واعطاء قيمة lpSecurityDescriptor . بالنسبة للحقل الأخير bInheritHandle فهو غير متعلق بالحماية وسنتحدث عنه بعد قليل عند الحديث عن مشاركة المقابض بين العمليات.

وعند الوصول لأي كائن في الكيرنل Kernel Object (وصول وليس انشاء) فيجب تحديد العملية التي نريد أن نجريها على هذا الكائن عن الوصول اليه. فمثلا اذا كنا نريد الوصول لكائن من نوع FileMapping للقرائه سوف نستدعي دالة الوصول Open :

الشكل 32 يبين استدعاء دالة تنشئ Kernel Object

المعامل الأول لهذه الدالة يحدد نوع العملية (القرائه في هذه الحالة) التي نريد أن نجريها على الكائن ، وتقوم الدالة OpenFileMapping أولا بفحص الحماية قبل أن تعيد المقبض للكائن الموجود. فاذا كان المستخدم الذي استدعى هذه الدالة ضمن مجموعه المستخدمين المخولين للوصول لهذا الكائن فسوف تعيد الدالة المقبض والا سوف تعيد NULL وعند معرفه الخطأ باستخدام GetLastError سيخرج (5) وهو ERROR_ACCESS_DENIED . على العموم أغلب التطبيقات لا تستخدم الحماية Security كثيرا.

يمكن للتطبيق التعامل مع أنواع كائنات أخرى بخلاف كائنات الكيرنل مثل User Object أو GDI Object والتي تستطيع انشاء والتعامل مع النوافذ والفأره والخطوط وغيرها. لمعرفة هل الكائن الحالي هو Kernel Object أم لا يكون ذلك عن طريق النظر الى الدالة التي قامت بانشائه فاذا وجدت معامل SECURITY_ATTRIBUTES سوف يكون الكائن هو كيرنل والا سوف يكون خلاف ذلك.

1.4.3. Process Kernel Object Handle Table:

عندما يتم انشاء عملية يتم انشاء Handle Table لهذه العملية (جدول للمقابض) ويستخدم هذا الجدول لحفظ معلومات كائنات الكيرنل (كائنات الكيرنل فقط Kernel Object وليس بقية الكائنات مثل كائنات الرسم والمستخدم User and GDI Objects). طريقة بناء هذه الجدول وكيفية ادارته غير موثقة Undocumented وبالتالي المعلومات التي ستوضح أدناه هي ليست معلومات تفصيليه حول طريقة العمل ولكنها تعطي فكره عن المفهوم بشكل عام حيث هذا المفهوم ضروري لمبرمج نظام الويندوز.

الشكل التالي يبين كيف يبدوا شكل جدول المقابض Handle Table وكما يتضح فهو مصفوفه من بنى البيانات Array of Data Structure وكل خانه فيها تتكون من مؤشر للكائن و Access Mask و Flags .

الشكل ‏33 يبين تركيب جدول المقابض في العملية

وعند انشاء العملية يكون هذا الجدول فارغاً ويتم التعامل معه عندما يقوم الThread داخل العملية بانشاء أي Kernel Object (عن طريق استدعاء أي دالة من دوال انشاء Kernel Object ) حيث يقوم الكيرنل بحجز منطقة في الذاكرة للكائن ويقوم بتهيئتها. ثم بعد ذلك يقوم الكيرنل بالبحث في جدول المقابض عن مكان فارغ وبما أن الجدول حاليا فارغا (كما في الشكل السابق) يقوم الكيرنل بايجاد الموقع الأول 1 ويقوم باستخدامه . وهكذا تكون قيمه مؤشر الكائن (العمود الثاني) هي عنوان الذاكرة التي يوجد بها الكائن ، وستكون الAccess Mask هي Full Access وسيتم وضع الFlag ببعض القيم سنوضحها بعد قليل.

من الدوال التي تنشئ Kernel Object : CreateThread , CreateProcess CreateFile, CreateSemaphore وغيرها الكثير . وكل من هذه الدوال تنشئ Kernel Object وترجع Handle متعلق بالعملية Process-Relative . وهذا المقبض يمكن ان يستخدمه أي Thread داخل العملية. قيمه هذا المقبض يجب أن تقسم على 4 (أو اجراء عمليتين ازاحه لليمين Two Right Bit-Shift) . للحصول على رقم الموقع index في جدول المقابض للعملية. وبالتالي عند عمل debug للتطبيق وفحص قيمه هذا المقبض Handle سنجد أنها قيم صغيره 4 و 8 وهكذا .

وعندما يتم استدعاء دالة تستقبل Kernel Object كمعامل سوف يتم ارسال القيمه العاده من الدوال (المقبض) انشاء كائن الكيرنل Create* ومن داخل الدالة سوف تقوم بالنظر الى جدول المقابض للحصول على عنوان الكائن في الذاكرة حتى تقوم بمعالجته. وفي حال تم ارسال مقبض خاطئ سوف تعود الدالة بخطأ وتكون قيمه GetLastError هي ERROR_INVALID_HANDLE .

أما في حال تم استدعاء دالة لانشاء Kernel Object ولم تعمل الدالة بشكل صحيح سوف ترجع 0 (NULL) ولذلك يكون دائما قيمه أول مقبض تبدأ من 4. وهناك بعض الدوال ترجع -1 (INVALID_HANDLE_VALUE) عند الخطأ مثل الدالة CreateFile لذلك يجب النظر الى التوثيق Documentation والتأكد من القيمه الراجعه.

الشكل 34 يبين استخدام خاطي للقيم الراجعه.

1.4.4. Closing Kernel Object:

بغض النظر عن كيفية انشاء الكائن سوف يتم انهاء التعامل معه من خلال الدالة CloseHandle وتقوم الدالة بفحص هل المقبض المرسل صحيح أم لا واذا كان كذلك يتم الذهاب لموقع الكائن في الذاكرة من خلال العنوان الموجود في جدول المقابض ويقوم بطرح واحد من الUsage Count للكائن واذا وصلت قيمه الUsage Count للكائن صفر سيقوم الكائن بحذف الكائن وتحريره من الذاكرة .

أما اذا تم ارسال مقبض خاطئ للدالة فسوف يحدث شيء من اثنين ، الأول أن الدالة سوف ترجع خطأ FALSE ويكون الخطا عند استدعاء GetLastError هو ERROR_INVALID_HANDLE ، أما الإحتمال الثاني هو أن يتم عمل throws للexception (0xC0000008) اذا كانت العملية تعمل في طور التنقيح.

وقبل أن تعود الدالة CloseHandle تقوم بحذف المدخل لهذا الكائن من جدول المقابض للعملية. وبالتالى يكون المقبض غير صحيح ويجب عدم استخدامه . (سوف يتم حذف المدخل سواء تم حذف الكائن من الذاكرة أو اذا لم يتم حذفه –في حال وجود عملية اخرى تستخدم هذا الكائن-).

ومن الأفضل بعد استدعاء الدالة CloseHandle هو وضع القيمه NULL في المقبض ، لأنه اذا تم استخدامه بعد ذلك سوف يقوم النظام باصدار خطأ لأن المقبض غير صحيح حيث لا وجود لمدخل لهذا المقبض في جدول المقابض. أو الأسوأ وهو أن يتم استخدام هذا المدخل بواسطه Kernel Object جديد وبالتالي يتم الوصول لمقبض أخر وقد يكون من نوع مختلف وبالتالي حدوث مشاكل غير متوقعه في البرنامج.

وفي حال لم يتم عمل CloseHandle سوف يحدث Leak (تسرب للذاكرة) اثناء عمل العملية ولكن عندما تنتهي يتم انهاء وتحرير كل المصادر حيث يقوم النظام بالبحث في جدول المقابض للعملية واذا وجد مدخل (كائن لم يتم انهاء التعامل معه) يقوم النظام بطرح واحد من الUsage Count وحذف المدخل من الجدول. واذا وصل الUsage Count لهذه المقبض الى صفر يقوم النظام بحذف الكائن من الذاكرة.

بالتالي يمكن أن يحدث Leak للKernel Object أثناء عمل العملية ولكن عند انتهاءها يضمن النظام تحرير كل شيء.والحديث ينطبق على بقية أنواع الكائنات الأخرى مثل GDI and User Object.

وهناك طريقة لكشف وجود Kernel Object Leak وعن عن طريق مراقبة الHandle للعملية فاذا كان الرقم يتصاعد فهذا يعني أن هناك Leak وأن هناك العملية لم تنهي العمل من الكائنات بعد الإنتهاء منها.

الشكل ‏ 35 يبين وجود Leak في برنامج حيث يتصاعد عدد الHandle بشكل كبير

1.4.5. تشارك كائنات الكيرنل بين العمليات:

تحتاج المسارات Threads في العمليات عادة للتشارك في كائنات الكيرنل والتي أنشأتها عمليات أخرى وقد يكون ذلك لأسباب مختلفة منها عند اراده تشارك البيانات في عمليتين مختلفتين في النظام (يتم ذلك باستخدام FileMapping) ، أو اراده تشارك البيانات بين عمليتين مختلفتين في نظامين مختلفين يرتبطان بشكبة (ويتم ذلك من خلال MailSlots أو named pipes)، أو عند اراده استخدام الsynchronization لجعل عملية تنبة notify العملية الأخرى عند حدوث حدث معين (يتم من خلال Mutex أو Semaphore).

وبما أن أي مقبض الكائن متعلق بالعملية Process-Relative فإن العملية ليست سهله ، وكما ذكرنا سابقا أن مايكروسوفت جعلت المقبض متعلق بالعملية وذلك لجعل النظام أكثر متانه Robustness حتى لا تجعل أي عملية تستخدم هذا الكائن بكل سهوله ، والسبب الثاني هو الحماية security حيث أن أي Kernel Object له حماية يحددها من ينشئ هذا الكائن ، وأي عملية تريد أن تستخدم هذا الكائن يجب أن يكون لها الصلاحية لذلك .

سوف نتناول الأن 3 طرق لكي تجعل العمليات تتشارك في الKernel Object وهي :

Object Handle Inheritance

Naming Objects

Duplicating Object Handle

A. الطريقة الأول لتشارك كائنات الكيرنل Object Handle Inheritance:

يتم استخدام هذه الطريقة عندما تكون للعمليات علاقه parent-Child بمعنى أن العملية الأولى تقوم بانشاء العملية الثانية Spawn Process وهنا يمكن السماح للعملية الإبن بالوصول الى كائنات العملية الأب. ولعمل ذلك يجب اتباع الخطوات التالية.

أولا عندما تقوم العملية الأب بانشاء Kernel Object تحدد هذه العملية بأن المقبض قابل للوراثه Inheritable Handle وذلك من خلال عمل نسخه من التركيب SECURITY_ATTRIBUTES واسناد القيمه TRUE للعضو bInheritHandle . كما يبين المقطع التالي.

الشكل 36 يبين جعل مقبض الكائن قابل للوراثه

نعود الى جدول المقابض والى العمود Flags والذي يحدد هل المقبض قابل للوراثه (1) كما في الشكل السابق ، أو أنه غير قابل للوراثه (0) وذلك في حال انشاء الKernel Object وتمرير القيمه NULL للمعامل SECURITY_ATTRIBUTES .

لنفرض أن جدول المقابض كان بهذا الشكل:

الشكل ‏ 37 يبين جدول المقابض وهناك مقبضين أحدهما قابل للوراثه (3) والأخر غير ذلك (1)

الخطوه الثانيه عند استخدام هذه الطريقة (Object Handle Inheritance) هي انشاء العملية الإبن Spawn Child Process ويتم ذلك من خلال الدالة CreateProcess.

الشكل 38 يبين تصريح الدالة CreateProcess

هذه الدالة تنشئ عملية وليست مهمه حاليا في سياق الحديث ، ما يهمنا الأن هو المعامل bInheritHandle وعاده يتم ارسال القيمه FALSE وهكذا يتم اخبار النظام بإن العملية الإبن Child Process لن ترث أي مقبض قابل للوراثة في العملية الأب. وعند ارسال القيمه TRUE فإن العملية الأبن سوف ترث أي مقبض قابل للوراثه في العملية الأب. وحين ارسال القيمه TRUE سيقوم النظام بعد انشاء مساحة العنواين للعملية الإبن وقبل أن تبدأ بالعمل بنسخ مداخل (نقصد بها السطر بالكامل ) جميع المقابض القابلة للوراثه في جدول المقابض في العملية الأب الى جدول المقابض في العملية الإبن ويضعها في نفس المواقع بالضبط وهذه معلومة مهمه. وبالإضافة الى نسخ مداخل المقابض في الجدول يقوم الكيرنل بزيادة الUsage Count للكائن لأن هناك عملية جديده تستخدم هذا الكائن ولكي يتم حذف هذا الكائن من الذاكرة يجب أن تقوم العمليتين باستدعاء CloseHandle أو أن يتم انهاء العمليتين (وكما ذكرنا سابقا ان عند انتهاء العملية سيقوم النظام بتحرير كل المصادر المستخدمه بواسطة العملية). ولا يشترط أن تنهي أي عملية استخدام الكائن قبل العملية الثانيه ويمكن لأي عملية سواء الأب أو الإبن أن تنهي التعامل مع الكائن وهذا لن يؤثر على تعامل العملية الأخرى مع الكائن.

الشكل التالي نجد جدول المقابض للعملية الإبن قبل أن تبدأ بالعمل وسوف نجد أنه تم نسخ مدخل المقبض القابل للوراثه في العملية الأب (وهو في الموقع 3) وتم نسخه الى نفس الموقع في العملية الإبن (3) كما نلاحظ أن عنوان الكائن في الذاكرة و الAccess Mask والFlags هي نفسها كما في العملية الأب.

الشكل 39 يبين جدول المقابض للعمليه الإبن

وهذا يعني أنه في حال قامت العملية الإبن بانشاء عملية جديدة spawn process ومررت القيمه TRUE للمعامل bInheritHandle في الدالة CreateProcess فسوف يتم انشاء عملية ترث المقبض بنفس العنوان والAccess Mask والFlags. (لاحظ أن وراثه المقابض تكون في لحظه انشاء العملية الإبن وسوف ترث المقابض القابله للوراثه الحالية، وفي حال بعد ذلك قامت العملية الأب بانشاء Kernel Object ومقبضه قابل للوراثه فإن العملية الإبن لن ترث ذلك المقبض) .

B. الطريقة الثانية لتشارك كائنات الكيرنل Named Object :

الطريقة الثانيه لتشارك كائنات الكيرنل وهي عن طريق تسمية الكائنات Naming Objects، فأغلب كائنات الكيرنل يمكن تسميتها وقت انشائها ، على سبيل المثال كل الدوال التالية تستقبل معامل يحدد إسم كائن الكيرنلCreateMutex , CreateEvent , CreateSemaphore CreateFileMapping ,CreateJobObject .

الشكل 40 يبين أحد الدوال التي تنشئ Kernel Object

كل هذه الدوال تستقبل معامل pszName وهو يحدد لنا اسم الكائن ، وعندما نرسل NULL لهذا المعامل فيتم انشاء كائن من غير اسم Anonymous Kernel Object وفي تلك الحالة اذا أردت مشاركة الكائن للعمليات الأخرى فيجب استخدام طريقة وراثه المقابض التي وضحناها قبل قليل أو أستخدام الدالة DuplicateHandle كما سيتبين عند الحديث حول الطريقة الثالثه للتشارك كائنات الكيرنل بين العمليات .

أما في حال ارسال اسم للكائن عند انشائه (ويجب أن يكون طوله بحدود MAX_PATH) وهنا سيتم وضع الكائن مع بقية كائنات الكيرنل المنشئة مسبقا في مساحة أسماء واحده Single Namespace وفي حال كان هناك كائن كيرنل له نفس الإسم (وحتى اذا لم يكن من نفس النوع فلن يتم انشاء الكائن الجديد) .

المثال التالي يوضح أنه لم يتم انشاء Semaphore وسترجع الدالة NULL لأن هناك كائن كيرنل له نفس الإسم AnyName وسوف تكون قيمه الناتج من الدالة GetLastError هي القيمه 6 (ERROR_INVALID_HANDLE) !

الشكل 41 يبين انشاء كائنان في الكيرنل بنفس الإسم

تعرفنا في الأعلى حول انشاء كائن في الكيرنل له اسم Naming Kernel Object ، ولكي يتم مشاركة الكائنات بين العمليات ستقوم العملية الأولى A بالإستدعاء للدالة وستقوم بانشاء كائن في الكيرنل وتعطي له الإسم MyMutex :

HANDLE hMutexProcessA = CreateMutex (NULL, FALSE, TEXT ("MyMutex"));

وعندما تبدأ العملية الثانية بالعمل (لا يشترط أن تكون أبن للعملية A وهذا ما يميز طريقة الNaming Object على طريقة Handle Inheritance) سوف يستدعي الدالة التالية :

HANDLE hMutexProcessB = CreateMutex (NULL, FALSE, TEXT ("MyMutex"));

قامت العملية الثانية بتسمية الكائن بنفس الإسم وسوف يقوم النظام في البداية بالتحقق من وجود كائن بنفس الإسم ولأنه يوجد هذا الكائن سوف يقوم النظام بالتحقق من نوع هذا الكائن وبما أنها من نفس النوع سوف يقوم النظام بالتحقق من الحماية Security وهل العملية الثانية لها صلاحيات الوصول وفي حال كان كذلك يقوم النظام بتهيئة مدخل جديد في جدول المقابض للعملية B ويكون المؤشر للكائن الموجود . أما اذا لم يكن الكائن من نفس النوع أو العملية ليست لها صلاحيات للوصول سوف تفشل الدالة وترجع NULL .

عادة الدوال التي تنشئ كائنات في الكيرنل (مثلا CreateMutex ) ترجع مقبض له كامل الصلاحيات Full Access وفي حال أردنا تحديد الصلاحيات لهذا المقبض فيتم استدعاء الدالة الإضافية والتي تنتهي بEx (مثل CreateMutexEx) .

نعود للمثال السابق ولنفرض أن الدالة عملت بنجاح وهنا بالطبع لن يتم انشاء كائن جديد ولكن كل ما في الأمر أن العملية B تكون حصلت على مقبض للكائن (المقبض كالعاده متعلق بالعملية Process-Relative ) وقد يكون قيمه هذا المقبض مختلفة ولكنه في النهايه يؤشر للكائن في الذاكرة . ولأنه تم الحصول على مقبض للكائن سوف يتم زياده الUsage Count للكائن بواحد ولن يتم حذف الكائن من الذاكرة الا في حال قامت العمليتان A و B باغلاق المقبض CloseHandle .

طريقة أخرى لتشارك الكائنات من خلال الأسماء وهو باستدعاء الدوال Open* وليس من خلال الدوال Create* ، ومن هذه الدوال : OpenMutex, OpenEvent OpenSemaphore , OpenJobObject . ولهذه الدوال نفس المعاملات للدوال التي تقوم بانشاء الكائن .

ولكن لن تستطيع ارسال القيمه NULL لإسم الكائن عند استدعاء دوال الOpen* ، ويجب أن يتم ارسال اسم للكائن وستقوم هذه الدوال بالبحث في مساحة الأسماء Namespace عن كائن له هذا الإسم واذا لم تم ايجاده سوف ترجع الدالة NULL وترجع دالة الخطأ GetLastError القيمه 2 وهي (ERROR_FILE_NOT_FOUND ) . واذا تم ايجاد كائن له نفس الإسم ولكنه من نوع مختلف سيتم ارجاع NULL وسوف ترجع دالة الخطأ GetLastError القيمه 2 وهي ERROR_INVALID_HANDLE. أما في حال كان من نفس النوع وسوف يفحص النظام الصلاحية (من خلال المعامل dwDesiredAccess) وهل يسمح لها وفي تلك الحالة سوف يتم الحصول على المقبض ويدخل في جدول المقابض وتزداد Usage Count للكائن بواحد. وفي حال تم ارسال القيمه TRUE للمعامل bInheritHandle في دوال Open* سوف يكون المقبض قابل للوراثه.

اذا الفرق الرئيسي بين دوال الCreate* والOpen* هي أن دوال الCreate* تنشئ الكائن اذا لم يكن موجود بينما تفشل دوال Open* في تلك الحالة.

ولم تضع مايكروسوفت طريقة أو أي نصائح لتسمية تلك الكائن وقد تحصل أحيانا مشكلة في حال قام شخص بكتابة برنامج وأنشئ كائنات بالإسم X وقام شخص أخر في برنامج أخر وأنشئ كائنات بنفس الإسم ، والحل الأفضل هو انشاء GUID واستخدام الإسم لهذا الGUID في اسم الكائنات. وهناك حل أخر عن طريق وضع الكائن في مساحة أخرى بخلاف المساحة العامة وسوف نتطرق لها بعد قليل.

الكائنات التي تسمى Named Object عاده تستخدم لكي تمنع تشغيل أكثر من نسخه واحده من التطبيق ولعمل ذلك فقط يتم استدعاء أي دالة من دوال Create* في الدالة الرئيسية وقم بتسمية الكائن بأي اسم ، وعندما ترجع الدالة يتم النظر لGetLastError فاذا كانت قيمته هي ERROR_ALREADY_EXISTS فهذا يعني أن هناك نسخه من التطبيق تعمل وبالتالي نقوم باغلاق النسخه الحالية ، المثال التالي يبين ذلك .

الشكل ‏42 يبين كود للتحقق من وجود نسخه أخرى تعمل من التطبيق

C. الطريقة الثالثة لتشارك كائنات الكيرنل DuplicateHandle:

الطريقة الثالثة لتشارك الكائنات بين العمليات وهو باستخدام الدالة DuplicateHandle ولها التصريح التالي.

الشكل 43 يبين تصريح الدالة DuplicateHandle

وتقوم هذه الدالة بنسخ المدخل للمقبض من جدول المقابض في العملية الأولى الى جدول المقابض في العملية الثانية . والمعامل الأول والثالث في الدالة هما مقبضان يجب أن يكونا متعلقين بالعملية Process-Relative التي سوف تستدعي الدالة DuplicateHandle ويجب أن يكونا من نوع Process والا فلن تعمل الدالة .

المعامل الثاني وهو مقبض Handle من أي نوع من كائنات الكيرنل وهو غير متعلق بالعملية التي سوف تستدعي الدالة DuplicateHandle ويجب أن يكون متعلق بالعملية التي مقبضها هو المعامل الأول للدالة DuplicateHandle ، أما المعامل الرابع فهو مؤشر للمقبض والذي سيم نسخ قيمه المقبض في العملية hTargetProcessHandle اليه .أما أخر ثلاثه معاملات فهي لتحديد قيمه الAccess Mask والFlag وأخيرا المعامل dwOptions فهو يمكن أن بالقيمة 0 أو أحد الFlags التالية DUPLICATE_SAME_ACCESS و DUPLICATE_CLOSE_SOURCE .وعند تحديد الFlag الأول سوف يتم نسخ الAccess Mask كما هو من المقبض في العملية الأولى الى العملية الثانية وسوف يتم حينها تجاهل المعامل الخامس في الدالة DuplicateHandle ، أما الFlag الثاني فيعني أن العملية سوف تغلق المقبض بعد النسخ وبالتالى لن يتأثر الUsage Count عند استخدام هذا الFlag (لأنه سيطرح منه واحد وسوف يزيد بواحد).

نأخذ مثال وليكن لدينا العملية S وهي العملية الأولى source process والتي تملك بعضا من كائنات الكيرنل وليكن لدينا العملية T وهي العملية الثانية والتي تريد الوصول لذلك الكائن Target Process وليكن لدينا العملية C وهي العملية التي ستقوم باستدعاء الدالة DuplicateHandle لكي تقوم بالنسخ.

الشكل التالي يبين جدول المقابض للعملية C ويحتوي على مقبض للعملية الأولى S ومقبض للعملية الثانية T .

الشكل 44 يبين Process C Handle Table

والشكل التالي يبين جدول المقابض للعملية S ويحتوي على مقبض واحد لكائن في الكيرنل :

الشكل 45 يبين Process S Handle Table

الشكل التالي بين جدول المقابض للعملية T قبل أن تستدعي العملية C الدالة DuplicateHandle ويحتوي جدول المقابض للعملية T على مقبض لكائن في الكيرنل.

الشكل ‏46 يبين Process T Handle Table

بعد ذلك عندما تقوم العملية C باستدعاء الدالة DuplicateHandle بالكود التالي سوف يكون شكل جدول المقابض للعملية T كما يوضحه الشكل التالي.

DuplicateHandle (1, 2, 2, &hObj, 0, TRUE, DUPLICATE_SAME_ACCESS);

الشكل 47 يبين Process T Handle Table

وكما يوضح الشكل السابق فإن مدخل المقبض الثاني في العملية S تم نسخه كمدخل أول في جدول المقابض في العملية T ، وقامت الدالة DuplicateHandle بوضع القيمه 1 في المتغير hObj وهو موقع Index المدخل في العملية T . ولأنه تم استخدام الFlag (DUPLICATE_SAME_ACCESS) فسوف يكون الAccess Mask لهذا المقبض في العملية T مشابه للAccess Mask في مدخل المقبض في العملية S وهكذا لن يتم النظر الى المعامل dwDesiredAccess. وأخيراً سنجد أن الFlag المختص بالوراثه (العمود الأخير في الشكل السابق) للمدخل الجديد أصبح 1 والسبب أننا أرسلنا القيمه True كمعامل للدالة DuplicateHandle وقمنا بتحديد أن ذلك المقبض قابل للوراثه .

لكن بعد استدعاء الدالة DuplicateHandle لن تعرف العملية أن الكائن أصبح متاح للإستخدام ولذلك يجب أن تقوم العملية C باخبار Notify العملية T بعد استدعاء الدالة DuplicateHandle وذلك باستخدام أي طريقة من طرق التواصل بين العمليات Interprocess Communication (IPC) .

ما قمنا بعمله الأن باستخدام الدالة DuplicateHandle من خلال 3 عمليات حتى نقوم بعملية تشارك الكائن ولكن في الغالب لا تستخدم هذه الطريقة بسبب أن العملية الثالثه C قد لا تعرف رقم المقبض للكائن في العملية الأولى S .

لكن الدالة DuplicateHandle دالة مرنه ويمكن أن نستخدمها فقط بين عمليتين كما سنوضح ذلك الأن ، ولنفرض أن لدينا العملية S تمتلك كائن في الكيرنل وتريد أن تسمح للعملية T الوصول لهذا الكائن وسوف يتم استدعاء الدالة DuplicateHandle بالطريقة التي يوضحها الشكل 6-48.

استدعاء الدالة GetCurrentProcess سوف يرجع مقبض للعملية الحالية ، وبعد استدعاء الدالة DuplicateHandle سوف يكون المتغير hObjInProcessT هو مقبض متعلق بالعملية T ويؤشر لنفس الكائن الذي يؤشر اليه hObjInProcessS . ويجب على العملية S عدم اغلاق المقبض المتعلق بالعملية T كما يوضح الكود التالي ذلك.

// Process S should never attempt to close the duplicated handle.
CloseHandle (hObjInProcessT);

الشكل ‏ 48 يبين طريقة تمرير المقبض للعملية T بعد استخدام الدالة DuplicateHandle

الى هنا نصل لنهاية الجزء الأول ..

وأي ملاحظات يرجي طرحها ..

المره القادمة سنبدأ بالغوص في Memory Managment أو الProcess/Thread ، حسب ما يتيسر ..

والسلام عليكم ورحمه الله وبركاته ،،

مشاء الله عليك اخوي

درس رائع جدا

الله يجزاك الجنة ..

والله درس رائع جدا بس المهم الاْكمال وبارك الله فيك يا اخى

مشاء الله عليك ..مشاء الله عليك

شرررح رائع بمعنى الكلمة ..اتضحة لي الرؤية الان ....

واصل ابداعك