Chengcheng OS (CCOS) هو نظام تشغيل 64 بت. أنا أكتبها على x86 ، لأنني أحب الحزن والبؤس. كان هذا المشروع لا يزال في التطوير. أنا مبتدئ لتصميم نظام التشغيل. العديد من مفاهيم التصميم التي قمت بتطبيقها مستوحاة من Windows NT مثل CCLDR (OS Loader لـ Chengcheng OS) ومدير الذاكرة. وهناك الكثير من الدورات التدريبية التي أحتاج إلى تعلمها في الأشهر القادمة. لذلك ، لن أقوم بتحديث المشروع بشكل متكرر.

UEFI
يستخدم CCOS UEFI للاضطراب ccoskrnl. UEFI يسهل بشكل كبير تطوير محمل OS. يمكن للمطور استدعاء الواجهات التي توفرها UEFI مباشرة (استخدم لغة C بدلاً من التجميع). هناك شيء واحد يجب ملاحظته هنا ، أن CCOS لا يزال يحتاج إلى CCLDR (ملف قابل للتنفيذ ثنائي آخر) لتحميل CCOSKRNL. يشبه إلى حد ما "محمل التمهيد في المرحلة الثانية". ولكن في الواقع ، يقوم BOOTX64.EFI بتقسيم مساحة kernel فقط ويبحث عن مساحة ذاكرة فعلية مناسبة لتحميل صورة CCOSKRNL. بعد ذلك ، ستقوم CCLDR بتخطيط مساحة kernel في عنوان عالٍ لمساحة العنوان الظاهري وتعيين GDT (جدول الوصف العالمي ، وهي بنية مهمة للهندسة المعمارية x86.)
متعددة
يعد دعم المعالجات المتعددة تحديًا هائلاً بالنسبة لي. لا أضمن تنفيذًا جيدًا لنظام المعالجات المتعددة. في الوقت الحالي ، يمكن لـ CCOS نشطة معالجات التطبيق الأخرى بشكل صحيح. ليس مثل عرض نظام التشغيل الآخر ، تضع CCOS روتين تهيئة معالج التطبيق في ملف ثنائي معزول وتحميله في أول 1 MIB من الذاكرة الفعلية وبناء جدول الصفحة على حد سواء لمساحة الذاكرة. قبل تشغيل معالجات التطبيقات ، ستقوم CCOs بإصلاح الاقتباس من العنوان النسبي للبرنامج الثنائي. يجب أن أعترف ، هذا تصميم أحمق.
apic
APIC (وحدة تحكم المقاطعة المتقدمة القابلة للبرمجة) هي مكون حاسم في نظام الكمبيوتر الحديث. يوفر إمكانية نظام متعددة المعالجات ويدعم أولوية المقاطعة متعددة المستويات على مستوى الأجهزة. لسوء الحظ ، APIC معقدة. نظرًا لأن فهم APIC يحتاج تمامًا إلى معرفة سليمة لنظام الكمبيوتر ، فأنا فقط أقوم بتنفيذ برنامج التشغيل الأساسي لـ APIC.
truetype
يعرض CCOS أحرفًا على الشاشة من خلال تقديم خطوط truetype (الخط الافتراضي في CCOS هو Adobe Source Han Sans SC VF ). لا يستحق إخراج الأحرف باستخدام عرض TrueType. بالنسبة لتطوير نظام التشغيل المبكر ، يعد استخدام خط النقطات أكثر طريقة موصى بها لإخراج الأحرف.
ربما يكون أعظم شيء في تخزين الشخصيات كخطوط العريضة هو أن هناك حاجة إلى مخطط واحد فقط لكل حرف لإنتاج جميع أحجام هذا الحرف الذي سيحتاجه نظام التشغيل. يمكن تحجيم مخطط واحد إلى مجموعة هائلة من الأحجام المختلفة ، بعضها موضح أدناه. يتيح ذلك عرض نفس الحرف على شاشات من القرارات المختلفة ، والطباعة على عدد كبير من الأحجام المختلفة. إن توسيع نطاق الخطوط العريضة للحرف هو عملية رياضية بسيطة ، كما هو الحال بالفعل في التحولات الأخرى مثل الدوران والانعكاسات.
بنية truetype معقدة ، قمت بتطبيق خطاب الخطوط فقط دون التلميح من trueType. التلميح في قلب truetype. قرر مخترعوها ، على دراية بتنوع الرأي في الطريقة "الصحيحة" لنوع التلميح ، أنه لا يوجد نموذج واحد يلمح إلى فرضهم على المطورين من النوع. بدلاً من ذلك ، قاموا بربط مجموعة متنقرة بسيطة نسبيًا بلغة برمجة تفسير جديدة. لقابلية القراءة للخط ، ومع ذلك ، هذا يكفي.
هذه هي issus cirtical هنا ، وهو أن عملية إخراج النص من CCOs هي تجمع للغاية. الأداء السيئ سوف يتباطأ بشكل خطير تشغيل CCOs. لا أعرف كيفية تحسين الوظيفة لأن رسم الخط هو عملية معقدة نسبيًا. طريقة أخرى هي استخدام خط النقطات بدلاً من ذلك خط truetype.
شار واسعة
تقدم CCOS نوعين من الحرف ، "char" و "WCH_T" (شار ، 4-bytes) ، لتخزين جميع الشخصيات. بغض النظر عن نوع الحرف ، يقوم CCOs دائمًا بتحويل WCH_T أولاً ، ثم يقوم بإخراج سلسلة واسعة. في الواقع ، يستخدم TrueType Earser في CCOS فقط "Unicode 2.0 و Disantics" ، أي معرف النظام الأساسي = 0 ومعرف الترميز = 3 في CMAP (CMAP - حرف إلى جدول رسم خرائط فهرس Glyph ، وهو دعامة في Truetype.). لذلك ، فإنه يدعم حصريًا أحرف Unicode الأساسية متعددة اللغات (U+0000 إلى U+FFFF).
مدير الذاكرة
أفكار التصميم الخاصة بإدارة الذاكرة مستوحاة من Window NT ، والتي تحتوي على قاعدة بيانات PFN ، والمظهر ، ونظام رسم الخرائط الذاتية للصفحات ، وإدارة تجمع الذاكرة ، ولكن ليس كل شيء.
إخراج الرسومات مع النوافذ المتعددة
يدعم CCOS النوافذ المتعددة ، مما يعني أنه يمكن إخراج النص في نافذة مختلفة على الشاشة. من المثير للاشمئزاز تصحيح المعالجات المتعددة من خلال فتح نافذة من النصوص على كل معالج. حتى لو لم يكن لديك برنامج تشغيل الماوس ، يمكن للمستخدم أيضًا استخدام لوحة المفاتيح لتحديد النافذة التي تحتاج إلى إدخال الأحرف.
إصلاح الأخطاء: أضف Spinlock لمنع تعارضات إخراج Windows المتعددة
مدير الذاكرة الديناميكي مع اكتشاف تسرب الذاكرة
إدارة نظام PTE
إدارة PCIE
سائق NVME
برنامج تشغيل لوحة المفاتيح (غير عاجل)
QEMU مع 2 GIB RAM أو أعلى
أقوم بتقسيم مساحة الذاكرة تقريبًا بحيث تستخدم مساحة kernel فقط ربع Rame. ولكن هناك حاجة إلى ملاحظة أن روتين getMemoryMap () قد أعاد معلومات خريطة الذاكرة غير الصحيحة عند محاولة تخصيص ذاكرة الوصول العشوائي العليا (أكبر من 2 GIB) لـ QEMU. أنا لا أحاول البرامج الثابتة الأخرى لـ OVMF ، لذا أعتقد أن مثل هذا الخطأ قد ينبع من OVMF الخاص بي.
X86_64 وحدة المعالجة المركزية (Intel أو AMD) مع مجموعة تعليمات AVX
هناك اختلافات طفيفة في برمجة الهندسة المعمارية X86_64 بين Intel 64 و AMD64. أقوم بتطوير CCOS استنادًا إلى AMD CPU ولكن استخدم أدلة Developer الخاصة بـ Intel® 64 و IA-32 Architectures كدليل مرجعي Architechure X86_64. في الوقت الحالي ، مهما كان بائع وحدة المعالجة المركزية.
للتثبيت ، يرجى الرجوع إلى بناء ccoskrnl
تم توفير مكتبة الرياضيات (Resperibs/libm.a) بواسطة estrella
لا ترخيص.
البريد الإلكتروني: [email protected]
Chengcheng OS: https://github.com/ccoskrnl/ccoskrnl
أدلة مطور برامج Intel® 64 و IA-32
AMD64 Architecture Programmer دليل المجلد 2: برمجة النظام
لغة البرمجة C
Osdev ويكي
مواصفات ACPI
مواصفات UEFI