الكربون (API)

📅 آخر تحديث: ٢٢ يوليو ٢٠٢٦
✍️ نُشر في: ٢٢ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

كاربون هي واجهة برمجة تطبيقات (API) متوقفة ، مبنية على لغة C ، طورتها شركة آبل لنظام التشغيل ماك أو إس إكس . تم طرحها لتسهيل الانتقال من نظامي التشغيل ماك أو إس 8 وماك أو إس 9 ، حيث مكّنت المطورين من نقل تطبيقاتهم الحالية إلى نظام ماك أو إس إكس مع الحفاظ على التوافق مع نظام ماك أو إس الكلاسيكي . أكملت كاربون نظام كوكوا ، وهو واجهة برمجة تطبيقات كائنية التوجه موروثة من نظام نيكست ستيب ، والذي أصبح إطار عمل التطبيقات الرئيسي لشركة آبل.

مع تزايد اعتماد المطورين على Cocoa، لا سيما بعد إطلاق نظام iOS ، تضاءل دور Carbon. لم تُصدر Apple نسخة 64 بت من معظم واجهات برمجة تطبيقات Carbon، وأوقفت دعم الإطار في نظام التشغيل OS X 10.8 Mountain Lion عام 2012، وأزالته تمامًا مع نظام macOS 10.15 Catalina عام 2019، مما جعل Cocoa واجهة برمجة التطبيقات الأصلية الرئيسية لتطوير تطبيقات Mac.

تاريخ

تطبيق "Carbonized" Adobe ImageReady v7.0 يعمل مباشرة على نظام التشغيل Mac OS X 10.2

برمجة نظام التشغيل ماك الكلاسيكي

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

بمرور الوقت، تطور عدد من مكتبات الكائنات على نظام التشغيل Mac، ولا سيما مكتبة Object Pascal MacApp ومكتبة THINK C Think Class Library، والإصدارات اللاحقة من MacApp و PowerPlant من CodeWarrior في لغة C++ .

افتتان

مع استحواذ آبل على شركة نيكست في أواخر عام ١٩٩٦، طورت استراتيجية جديدة لنظام التشغيل تعتمد بشكل كبير على منصة أوبن ستيب لنظام ماك . كانت استراتيجية نظام التشغيل رابسودي الجديدة بسيطة نسبيًا؛ فقد احتفظت بمعظم مكتبات الكائنات الموجودة في أوبن ستيب تحت اسم "الصندوق الأصفر"، ونقلت واجهة المستخدم الرسومية الموجودة في أوبن ستيب لنظام ماك وجعلتها تبدو أقرب إلى نظام ماك، ونقلت العديد من واجهات برمجة التطبيقات الرئيسية من نظام ماك إلى نظام رابسودي الأساسي الشبيه بنظام يونكس (لا سيما كويك تايم وبحث آبل )، وأضافت محاكيًا يُعرف باسم "الصندوق الأزرق" لتشغيل برامج نظام ماك الموجودة.

عندما كُشِف عن هذه الخطة في مؤتمر المطورين العالمي (WWDC) عام ١٩٩٧، لاقت بعض الاعتراضات من مطوري نظام التشغيل ماك الحاليين، الذين انزعجوا من أن قواعد بياناتهم البرمجية ستُحصر فعليًا في مُحاكي من غير المرجح تحديثه. وأطلقوا على "الصندوق الأزرق" اسم "صندوق العقاب". أما المطورون الكبار مثل مايكروسوفت وأدوبي ، فقد رفضوا رفضًا قاطعًا، ورفضوا حتى مجرد التفكير في نقل النظام إلى OpenStep، الذي كان مختلفًا تمامًا عن نظام التشغيل ماك الحالي لدرجة انعدام التوافق تقريبًا.

أخذت شركة آبل هذه المخاوف على محمل الجد. عندما أعلن ستيف جوبز عن تغيير توجه آبل في مؤتمر WWDC التالي عام 1998، صرح قائلاً: "ما يريده المطورون حقًا هو نسخة حديثة من نظام التشغيل ماك، وآبل ستوفرها".

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

الكاكاو والكربون

بهدف توفير مسار ترقية حقيقي ومدعوم جيدًا لقواعد بيانات نظام التشغيل Mac OS الحالية، قدمت Apple نظام Carbon. يتألف Carbon من العديد من المكتبات والوظائف التي توفر واجهة برمجة تطبيقات (API) شبيهة بنظام Mac، ولكنها تعمل فوق نظام التشغيل الأساسي الشبيه بنظام Unix، بدلاً من نسخة من نظام Mac OS تعمل في وضع المحاكاة. تم تنظيف مكتبات Carbon وتحديثها بشكل شامل، كما تم تحسين حمايتها. فبينما كان نظام Mac OS مليئًا بواجهات برمجة التطبيقات التي تتشارك الذاكرة لتمرير البيانات، أعاد Carbon تنفيذ جميع عمليات الوصول هذه باستخدام إجراءات فرعية للوصول إلى أنواع البيانات غير الشفافة . وقد سمح هذا لـ Carbon بدعم تعدد المهام الحقيقي وحماية الذاكرة ، وهي ميزات طالب بها مطورو Mac لعقد من الزمان. كما أدت التغييرات الأخرى عن واجهة برمجة التطبيقات السابقة إلى إزالة الميزات التي كانت غير متوافقة من حيث المفهوم مع نظام Mac OS X، أو ببساطة أصبحت قديمة. على سبيل المثال، لم يعد بإمكان التطبيقات تثبيت معالجات المقاطعات أو برامج تشغيل الأجهزة .

لدعم Carbon، تغير نموذج Rhapsody بالكامل. فبينما كان Rhapsody في الأساس OpenStep مع مُحاكي، فإن واجهة برمجة تطبيقات OpenStep وCarbon، في النظام الجديد، ستتشارك، قدر الإمكان، في الشيفرة البرمجية. ولتحقيق ذلك، أُعيد تنفيذ العديد من أجزاء الشيفرة المفيدة من المستويات الدنيا لنظام OpenStep، المكتوبة بلغة Objective-C والمعروفة باسم Foundation، بلغة C خالصة. عُرفت هذه الشيفرة باسم Core Foundation ، أو CF اختصارًا. وأصبحت نسخة من Yellow Box، التي نُقلت لاستدعاء CF، واجهة برمجة تطبيقات Cocoa الجديدة ، كما استدعت استدعاءات Carbon، الشبيهة بنظام Mac، نفس الدوال. في النظام الجديد، أصبح Carbon وCocoa متماثلين. كان من شأن هذا التحويل أن يُبطئ أداء Cocoa عادةً، نظرًا لاستدعاء دوال الكائنات لمكتبات C الأساسية، لكن Apple استخدمت تقنية أطلقت عليها اسم toll-free bridging لتقليل هذا التأثير. [ 1 ]

كجزء من هذا التحويل، قامت آبل بكتابة خادم نوافذ ومحرك رسومات جديدين من الصفر ليحلا محل برنامج Display PostScript المقيد بترخيص : وهو Quartz (الذي يُعرف أيضًا باسم "Display PDF"). [ 2 ] وفر Quartz استدعاءات واجهة برمجة تطبيقات C يمكن استخدامها من Carbon أو Cocoa. وتم عزل نظام التشغيل الأساسي نفسه بشكل أكبر وإصداره باسم Darwin .

التحرر والتطور

طُرحت مكتبة Carbon بشكل غير مكتمل عام 2000، كمكتبة مشتركة متوافقة مع نظام التشغيل Mac OS 8.1 الصادر عام 1997. سمحت هذه النسخة للمطورين بنقل برامجهم إلى Carbon دون فقدان إمكانية تشغيلها على أجهزة Mac OS الحالية. عُرفت عملية النقل إلى Carbon باسم "Carbonization". بدأ الدعم الرسمي لنظام Mac OS X عام 2001 مع إصدار Mac OS X v10.0 ، وهو أول إصدار عام من النظام الجديد. استُخدمت Carbon على نطاق واسع في الإصدارات الأولى من Mac OS X من قِبل جميع شركات البرمجيات الكبرى تقريبًا، حتى من قِبل Apple. على سبيل المثال، ظل Finder تطبيقًا مبنيًا على Carbon لسنوات عديدة، ولم يُنقل إلى Cocoa إلا مع إصدار Mac OS X 10.6 عام 2009. [ 3 ]

أدى الانتقال إلى تطبيقات ماكنتوش 64 بت، بدءًا من نظام التشغيل Mac OS X v10.5 الذي صدر في 26 أكتوبر 2007، إلى فرض أولى القيود الرئيسية على Carbon. إذ لا توفر Apple توافقًا بين واجهة المستخدم الرسومية لنظام ماكنتوش ولغة البرمجة C في بيئة 64 بت، بل تشترط استخدام لغة Objective-C مع واجهة برمجة تطبيقات Cocoa. [ 4 ] اعتبرت العديد من التعليقات هذا مؤشرًا على قرب زوال Carbon، وهو موقف تعزز عندما صرحت Apple بعدم إضافة أي تحديثات رئيسية جديدة إلى نظام Carbon، [ 5 ] [ 6 ] وتأكد أكثر مع إيقاف دعمه نهائيًا في عام 2012.

التحول إلى الكاكاو

على الرغم من المزايا المزعومة لـ Cocoa، إلا أن الحاجة إلى إعادة كتابة كميات كبيرة من التعليمات البرمجية القديمة أبطأت عملية انتقال التطبيقات المبنية على Carbon، وأبرز مثال على ذلك برنامج Adobe Photoshop [ 7 ] ، الذي تم تحديثه لاحقًا إلى Cocoa في أبريل 2010. وامتد هذا الأمر ليشمل برامج Apple الرئيسية، مثل iTunes [ 8 ] ، وتطبيق Finder، و Final Cut Pro (بالإضافة إلى الميزات الموجودة في محرك QuickTime الذي يدعمه [ 9 ] )، والتي ظلت مكتوبة بلغة Carbon لسنوات عديدة. وقد تم إصدار iTunes وFinder وFinal Cut Pro لاحقًا بإصدارات Cocoa.

الإهمال والتوقف

في عام ٢٠١٢، مع إصدار نظام التشغيل OS X 10.8 Mountain Lion، اعتُبرت معظم واجهات برمجة تطبيقات Carbon قديمة. كانت هذه الواجهات متاحة للمطورين، واستمرت جميع تطبيقات Carbon بالعمل، ولكن لن يتم تحديثها. في ٢٨ يونيو ٢٠١٧، أعلنت Apple أن برامج ٣٢ بت لنظام macOS، مثل جميع تطبيقات Carbon، لن تُدعم "بشكل كامل" على إصدارات macOS اللاحقة لإصدار macOS 10.13 High Sierra . [ ١٠ ] أزال نظام macOS 10.15 Catalina رسميًا دعم تطبيقات ٣٢ بت، بما في ذلك جميع تطبيقات Carbon. [ ١١ ]

بنيان

ينحدر Carbon من Toolbox ، ولذلك فهو يتألف من "مديرين". كل مدير عبارة عن واجهة برمجة تطبيقات (API) مرتبطة وظيفيًا، تُعرّف مجموعات من هياكل البيانات والوظائف اللازمة لمعالجتها. غالبًا ما تكون المديرين مترابطة أو متعددة الطبقات. يتكون Carbon من مجموعة واسعة من الوظائف لإدارة الملفات والذاكرة والبيانات وواجهة المستخدم وخدمات النظام الأخرى. يتم تنفيذه كأي واجهة برمجة تطبيقات أخرى: في macOS، ينتشر عبر عدة أطر عمل (كل منها عبارة عن بنية مبنية حول مكتبة مشتركة )، وأهمها Carbon.frameworkو ApplicationServices.frameworkو و CoreServices.framework، وفي نظام Mac OS الكلاسيكي، يوجد في مكتبة مشتركة واحدة باسم CarbonLib.

لا يُعدّ Carbon مجرد أداة للتوافق، بل هو واجهة برمجة تطبيقات أصلية لنظام التشغيل Mac OS X. ويقع تقريبًا جنبًا إلى جنب مع Cocoa في مخطط البنية. تستطيع تطبيقات Carbon استخدام جميع الوظائف الأصلية لنظام التشغيل Mac OS X، ويمكنك دمج نوافذ Carbon وCocoa في نفس العملية.

يتوافق برنامج Carbon مع جميع تنسيقات الملفات التنفيذية المتوفرة لنظام التشغيل Mac OS بمعالجات PowerPC. يتطلب التوافق الثنائي بين نظام التشغيل Mac OS X والإصدارات السابقة استخدام ملف بتنسيق تنفيذي مفضل ، وهو ما لم تدعمه Apple مطلقًا في بيئة تطوير Xcode الخاصة بها .

تميل الأجزاء الأحدث من Carbon إلى أن تكون أكثر توجهاً نحو الكائنات في تصميمها، ومعظمها يعتمد على Core Foundation . بعض المديرين، مثل مدير HIView (وهو مجموعة فرعية من مدير التحكم)، مُنفذة بلغة C++ ، لكن Carbon لا تزال واجهة برمجة تطبيقات C.

بعض الأمثلة على مديري الكربون:

  • مدير الملفات — يدير الوصول إلى نظام الملفات، وفتح الملفات وإغلاقها وقراءتها وكتابتها.
  • مدير الموارد — يدير الوصول إلى أجزاء البيانات في فرع الموارد الخاص بالملف. تشمل أمثلة الموارد الأيقونات والأصوات والصور وقوالب الأدوات، وما إلى ذلك.
  • مدير الخطوط — يدير الخطوط . تم إيقافه (كجزء من QuickDraw ) منذ نظام التشغيل Mac OS X الإصدار 10.4 ، لصالح خدمات Apple Type Services (ATS).
  • QuickDraw — أدوات رسومات ثنائية الأبعاد. تم إيقاف دعمها منذ نظام التشغيل Mac OS X الإصدار 10.4 ، لصالح Quartz 2D.
  • مدير أحداث Carbon — يحول نشاط المستخدم والنظام إلى أحداث يمكن للبرنامج التعرف عليها والاستجابة لها.
  • HIObject - واجهة برمجة تطبيقات جديدة كليًا موجهة للكائنات، تُضيف إلى Carbon نموذجًا برمجيًا كائنيًا لبناء واجهات المستخدم الرسومية. هذه الواجهة متوفرة في نظام التشغيل Mac OS X الإصدار 10.2 والإصدارات الأحدث، وتمنح مبرمجي Carbon واجهة برمجة تطبيقات أكثر قوة. بدءًا من Mac OS X الإصدار 10.2 ، تُعدّ HIObject الفئة الأساسية لجميع عناصر واجهة المستخدم الرسومية في Carbon. يدعم Interface Builder ، وهو جزء من أدوات تطوير Apple، فئة HIView. تقليديًا، كانت بنى واجهات المستخدم الرسومية من هذا النوع تُترك لأطر عمل تطبيقات خارجية. بدءًا من Mac OS X الإصدار 10.4، أصبحت HIObjects من نوع NSObjects، وترث إمكانية تحويلها إلى تدفقات بيانات لنقلها أو حفظها على القرص.
  • يستخدم HITheme برنامجي QuickDraw و Quartz لعرض عناصر واجهة المستخدم الرسومية على الشاشة. تم تقديم HITheme في نظام التشغيل Mac OS X الإصدار 10.3 ، ويُعد Appearance Manager طبقة توافق فوق HITheme منذ ذلك الإصدار.
  • مدير HIView — يُدير إنشاء عناصر التحكم ورسمها واختبارها والتحكم بها. منذ نظام التشغيل Mac OS X الإصدار 10.2، أصبحت جميع عناصر التحكم عبارة عن HIViews. في نظام التشغيل Mac OS X الإصدار 10.4، أُعيد تسمية مدير عناصر التحكم إلى مدير HIView.
  • مدير النوافذ — يُدير إنشاء النوافذ وتحديد مواقعها وتحديثها والتحكم بها. منذ نظام التشغيل Mac OS X الإصدار 10.2، تحتوي النوافذ على واجهة عرض رئيسية (HIView).
  • مدير القوائم — يُدير إنشاء القوائم واختيارها والتعامل معها. منذ نظام التشغيل Mac OS X الإصدار 10.2، أصبحت القوائم كائنات HIObjects. ومنذ نظام التشغيل Mac OS X الإصدار 10.3، يُمكن رسم محتوى القوائم باستخدام HIViews، وتستخدم جميع القوائم القياسية HIViews للرسم.

إدارة الفعاليات

كان مدير الأحداث في Mac Toolbox يستخدم في الأصل نموذج الاستقصاء لتصميم التطبيقات. تطلب حلقة الأحداث الرئيسية للتطبيق من مدير الأحداث حدثًا باستخدام GetNextEvent. إذا كان هناك حدث في قائمة الانتظار، يُعيده مدير الأحداث إلى التطبيق، حيث تتم معالجته، وإلا فإنه يعود فورًا. يُسمى هذا السلوك " الانتظار النشط "، وهو تشغيل حلقة الأحداث دون داعٍ. يُقلل الانتظار النشط من وقت وحدة المعالجة المركزية المتاح للتطبيقات الأخرى، ويُقلل من طاقة بطارية أجهزة الكمبيوتر المحمولة. يعود تاريخ مدير الأحداث الكلاسيكي إلى نظام التشغيل Mac OS الأصلي عام 1984، عندما كان التطبيق قيد التشغيل مضمونًا بأنه التطبيق الوحيد قيد التشغيل، ولم تكن إدارة الطاقة مصدر قلق.

مع ظهور MultiFinder وإمكانية تشغيل أكثر من تطبيق في وقت واحد، ظهرت دالة جديدة في مدير الأحداث، وهي WaitNextEvent ، التي تسمح للتطبيق بتحديد فترة انتظار. إحدى الحيل البسيطة لتحديث الشيفرة القديمة إلى نموذج أكثر كفاءة دون تغييرات جوهرية في شيفرتها المصدرية هي ببساطة ضبط قيمة مُعامل الانتظار المُمرر إلى WaitNextEvent على قيمة كبيرة جدًا. في نظام macOS، يؤدي هذا إلى وضع الخيط في حالة انتظار عندما لا يكون هناك ما يفعله، ولا يُعيد حدثًا إلا عند وجود حدث للمعالجة. بهذه الطريقة، يُعكس نموذج الاستقصاء بسرعة ليصبح مُكافئًا لنموذج الاستدعاء، حيث يُنفذ التطبيق عملية إرسال الأحداث بالطريقة الأصلية. مع ذلك، توجد بعض الثغرات. على سبيل المثال، تستدعي دالة ModalDialog في مجموعة الأدوات القديمة، دالة GetNextEvent القديمة داخليًا، مما يؤدي إلى الاستقصاء في حلقة مُغلقة دون حظر.

يُقدّم Carbon نظامًا بديلًا يُسمى Carbon Event Manager. (لا يزال نظام Event Manager الأصلي موجودًا لضمان التوافق مع التطبيقات القديمة). يوفر Carbon Event Manager حلقة الأحداث للمطور (استنادًا إلى نظام Core Foundation CFRunLoopفي التنفيذ الحالي)؛ حيث يقوم المطور بإعداد معالجات الأحداث والدخول إلى حلقة الأحداث في الدالة الرئيسية، ثم ينتظر حتى يقوم Carbon Event Manager بإرسال الأحداث إلى التطبيق.

المؤقتات

في نظام التشغيل ماك الكلاسيكي، لم يكن هناك دعم لمؤقتات مستوى التطبيق (كان مدير الوقت متاحًا، لكنه كان يُنفذ استدعاءات المؤقت عند حدوث مقاطعة، ما يجعل استدعاء معظم إجراءات صندوق الأدوات غير آمن). عادةً ما كان يُترك تنفيذ المؤقتات لمطوري التطبيقات، وكان ذلك يتم عادةً عن طريق حساب الوقت المنقضي خلال حدث الخمول - أي الحدث الذي تُرجعه دالة WaitNextEvent عندما لا يتوفر أي حدث آخر. ولضمان دقة معقولة لهذه المؤقتات، لم يكن بإمكان المطورين تحمل تأخير WaitNextEvent لفترة طويلة، لذا كانت تُضبط معلمات "النوم" عادةً على قيم منخفضة. ينتج عن ذلك سلوك جدولة غير فعال للغاية، حيث لن ينام الخيط لفترة طويلة، بل سيستيقظ بشكل متكرر لإرجاع أحداث الخمول هذه. أضافت آبل دعم المؤقتات إلى Carbon لمعالجة هذه المشكلة - حيث أصبح النظام قادرًا على جدولة المؤقتات بكفاءة عالية.

تطبيقات مفتوحة المصدر

يحتوي GNUstep على تطبيق لواجهة برمجة تطبيقات Carbon يُسمى Boron. ويهدف إلى التوافق مع الأجزاء غير المهملة من ApplicationServices وCoreServices. ويُشتق الاسم من حقيقة أن البورون يسبق الكربون في الجدول الدوري للعناصر . [ 12 ] كما يحتوي Darling أيضًا على تطبيق لواجهة برمجة تطبيقات Carbon. كلا التطبيقين غير مكتملين إلى حد كبير ويتكونان في الغالب من دوال وهمية.

انظر أيضاً

مراجع

  1. ↑ "مفاهيم في برمجة Objective-C: الربط المجاني" . developer.apple.com . 2012. تم الاطلاع عليه في 8 مايو 2017 .
  2. ^ سيراكوزا، جون (2000). "تحديث نظام التشغيل Mac OS X: الكوارتز والأكوا" . archive.arstechnica.com . تم الاسترجاع في 8 مايو 2017 .
  3. ↑ كرازيت، توم (17 أكتوبر 2008). "أبل تنقل فايندر إلى كوكو" . سي نت . مؤرشف من الأصل في 11 يوليو 2015. تم الاطلاع عليه في 21 مايو 2015 .
  4. ↑ شركة آبل. "دليل تمهيدي لأنظمة 64 بت لمطوري Carbon" . مؤرشف من الأصل في 11 يونيو 2009.
  5. ↑ شركة آبل. "اختيار مسار تطوير لواجهة مستخدم Carbon الخاصة بك" . تعديل تطبيقك لاستخدام عنونة 64 بت . مؤرشف من الأصل في 4 أغسطس 2009.
  6. ↑ سيراكوزا، جون (3 أبريل 2008). "رابسودي وبلوز" . آرس تكنيكا . تم الاطلاع عليه في 5 فبراير 2023 .
  7. ↑ جون ناك. "فوتوشوب، لايت روم، وخارطة طريق أدوبي 64 بت" . مؤرشف من الأصل في 14 أبريل 2015.
  8. ↑ كريس فورسمان (3 سبتمبر 2010). "تجربة عملية لـ iTunes 10: أداء أسرع، وخيارات واجهة مستخدم مثيرة للجدل" . مؤرشف من الأصل في 2 أبريل 2015.
  9. ↑ جون سيراكوزا (سبتمبر 2009). "نظام التشغيل ماك أو إس إكس 10.6 سنو ليوبارد: مراجعة آرس تكنيكا" . مؤرشف من الأصل في 13 يوليو 2014.
  10. ↑ شركة آبل (28 يونيو 2017). "متطلبات 64 بت لتطبيقات ماك" . مؤرشف من الأصل في 30 يناير 2018. تم الاطلاع عليه في 18 فبراير 2018 .
  11. ↑ موقع MacRumors (4 يونيو 2019). "تطبيقات 32 بت غير مُحسَّنة لأجهزة Mac الخاصة بك ستتوقف عن العمل على نظام macOS Catalina" . تم الاطلاع عليه بتاريخ 10 أغسطس 2019 .
  12. ↑ "gnustep/libs-boron: البورون هو الذرة التي تسبق الكربون" . GitHub . GNUstep. 23 مارس 2019.
  • مكتبة مراجع الكربون (رابط مطوري أبل) في آلة Wayback (تمت أرشفة بتاريخ 20 أبريل 2009)