برسی یک سیستم 386

[rayk]

پاسخ : برسی یک سیستم 386

بلاک oem و سیستم فایل fat12
[hr]
حالا یه بار دیگه نگاهی به بلاک پارامترهای OEM که تو پست قبلی بهش اشاره کرده بودیم میندازیم. حالا به اندازه کافی پیش زمینه برای درک این کدهای به ظاهر خیلی زشت رو داریم. پس کمی بیشتر واردشون میشم.

 bpbBytesPerSector: DW 512
 bpbSectorsPerCluster: DB 1
 bpbReservedSectors: DW 1
 bpbNumberOfFATs: DB 2
 bpbRootEntries: DW 224
 bpbTotalSectors: DW 2880
 bpbMedia: DB 0xF0
 bpbSectorsPerFAT: DW 9
 bpbSectorsPerTrack: DW 18
 bpbHeadsPerCylinder: DW 2
 bpbHiddenSectors: DD 0
 bpbTotalSectorsBig: DD 0
 bsDriveNumber: DB 0
 bsUnused: DB 0
 bsExtBootSignature: DB 0x29
 bsSerialNumber: DD 0xa0a1a2a3
 bsVolumeLabel: DB "MOS FLOPPY "
 bsFileSystem: DB "FAT12  "

دو خط اول همونطور که از اسمشون پیداست به ترتیب تعداد بایت ها در هر سکتور و تعداد سکتورها در هر کلاستر رو مشخص میکنند که نشون میده تعداد سکتورها در فلاپی ما 1 هستش که البته میشه تغییرش داد ولی توصیه میکنم این کار رو نکنید. خط سوم هم تعداد سکتورهای رزرو شده رو مشخص میکنه. منظور از سکتور رزرو شده، سکتوری هست که توی جدول FAT استفاده نمیشه و نمیشه در حالت عادی اطلاعاتش رو تغییر داد. مثلاً تو حالت عادی شما اگه وارد یک CD ویندوز که قابلیت Bootable داره بشید. تو محیط ویندوز نمی تونید فایلهای مربوط به سکتور بوت اون دیسک رو ببینید ، در مورد درایو C یا فلاپی هم که سکتور راه انداز دارند وضع به همین ترتیب هستش. در حالت عادی ویندوز یا بقیه سیستم عاملها این اجازه رو به کابر نمیدن که اطلاعات این سکتور رو تغییر بدن، ولی با برنامه های خاصی مثل partcopy میشه این کار رو انجام داد. به همین دلیله که وقتی شما تو پست قبلی بوت لودرتون رو به فلاپی منتقل کردید بعد از وارد شدن به فلاپی چیزی نمیدید. از اونجایی که ما فقط به یک سکتور برای راه اندازی احتیاج داشتیم مقدار این پارامتر رو برابر 1 قرار دادیم.

پارامتر بعدی تعداد جدول های FAT رو مشخص میکنه که برای فلاپی همیشه برابر 2 هست. دو پارامتر بعدی به ترتیب حداکثر دایرکتوری های موجود در ریشه درایو و تعداد کل سکتورهای درایو رو نشون میدن که برای فلاپی به ترتیب 224 و 2880 باید باشه. پارامتر بعدی، یعنی bpbMedia یک عدد هشت بیتیه که هر بیت معنی خاصی داره که توضیح میدم.

بیت 0 : اگه 0 باشه یعنی فلاپی یک وجهی و اگه 1 باشه یعنی دو وجهیه

بیت 1 : اگه 0 باشه یعنی هر جدول FAT توی 9 سکتور جا میگیره و اگه 1 باشه توی 8 سکتور

بیت 2 : تعداد شیارها رو نشون میده که اگه 0 باشه یعنی 80 شیار و اگه 1 باشه یعنی 40 شیار

بیت 3 : نشون دهنده نوع دیسک هست که اگه 0 باشه یعنی ثابته ( مثل هارد ) و اگه 1 باشه یعنی قابل جابه جاییه ( مثل فلاپی و CD )

بیت های 4 تا 7 : بلا استفاده هستند.

در اینجا ما از عدد 0xF0 = 11110000 استفاده کردیم که نشون دهنده یک دیسک جابحا شونده و تک وجهی با 80 شیار و 9 سکتور در هر FAT هست.

پارامتر بعدی هم همون 9 سکتور در هر FAT رو مشخص میکنه. دو پارامتر بعدی هم به ترتیب تعداد سکتورها در هر شیار و تعداد هدها در هر سیلندر رو مشخص میکنند که برابر با 18 و 2 هستند.

چهار پارامتر بعدی مهم نیستند و همین مقادیر رو که میبینید همیشه براشون استفاده کنید.

سه پارامتر بعدی هم به ترتیب شماره سریال دیسک، برچسپ یا Label دسیک و نوع سیستم فایل دیسک رو مشخص میکنند. توجه کنید که برچسب دیسک حتماً باید 11 کاراکتر و نوع سیستم فایل 8 کاراکتر باشند. به همین دلیل از جای خالی استفاده شده. خب حتمآ میپرسید حالا این چیزهایی که گفتیم چه ربطی به ماجرا داره.

در واقع ما برای دستیابی به فایل ها روی هر دیسکی به این پارامترها احتیاج داریم. به طور ذاتی یک درایور دیسک چه از نوع سخت، چه از نوع نرم هیچ اطلاعی از نوع فایل سیستم، سکتور راه انداز، نحوه راه اندازی سیستم ، چگونگی تشکیل فایل و... نداره. حتی یک درایور هیچ تعریفی از فایل براش نشده. درایور دیسک فقط میتونه یک سری اطلاعات رو به صورت دسته ای از بیت ها در محل های مشخصی از دیسک ذخیره کنه یا اونها رو بخونه. در واقع این برنامه نویس هست که به CPU میفهمونه منظورش از یک فایل یا دایرکتوری چیه و تمام این مفاهیم قبل از استفاده به اون شکلی که مثلاً توی ویندوز دیدید باید توسط سیستم عامل تعریف بشه. مهمترین چیزی که برای تعریف مفهوم فایل به درد ما میخوره همین پارامترهای بلاک OEM هستش.

[rayk]

پاسخ : برسی یک سیستم 386


نکاتی در مورد سیستم های فایل

---

[list type=decimal]
[li]سیستم فایل چیزی به جز یک سری تعاریف نیست که به ما کمک می کنه تا مفهوم فایل رو با استفاده از دستورات سطح پایین و وقفه ها پیاده سازی کنیم.[/li]
[li]یک فایل چیزی جز یک سری اطلاعات به صورت مجموعه ای از بیت ها نیست. این اطلاعات میتونه شامل هرچیزی باشه ( مثلاً فایل متنی یا صوتی ). این ما هستیم که تعیین میکنیم این بیت ها به چه صورت تفسیر بشه. ما حتی میتونیم یک فایل متنی یا صوتی رو به صورت یک فایل اجرایی ، اجرا کنیم ولی نتیجه انجام این کار قابل پیش بینی نخواهد بود.[/li]
[li]میدانیم که هر سکتور برابر با 512 بایت است و فایل ها روی این سکتور ها ذخیره میشوند. اما حجم فایل ها همیشه برابر با 512 بایت یا مضرب صحیحی از این عدد نیست. بنابراین باید مابقی بایت های سکتوری که به عنوان آخرین سکتور از یک فایل است را با اطلاعات خاصی علامت گذاری کنیم.[/li]
[li]ممکن است تمام سکتور های حاوی اطلاعات یک فایل خاص پشت سر هم قرار نگرفته باشند. به اینگونه فایل ها، فایل های تکه تکه یا گسسته گفته میشود. درنتیجه برای خواندن اینگونه فایل ها باید تمام سکتورها را جداگانه خواند و در کنار هم قرار داد.[/li]
[li]برخی از سیستم های فایل معروف عبارتند از FAT12 , FAT16 , FAT32 , NTFS , ext2 , ext3 و ... . اما برخی شرکت ها ممکن است از سیستم فایل مربوط به خود استفاده کنند که معمولاً کارایی این نوع سیستم فایل پایینتر از سیستم فایل های استاندار است. مگر موارد خاصی مانند سیستم فایل اختصاصی گوگل GFS که کارایی بسیار بالایی داره.[/li][/list]



نکاتی در مورد سیستم فایل FAT12


سیستم فایل FAT12 قدیمی ترین سیستم فایل استاندارد جهان میباشد که در سال 1977 توسط مایکروسافت معرفی شد و هنوز هم به عنوان یک سیستم فایل استاندارد مورد استفاده قرار میگیرد. برخی از خصوصیات این سیستم فایل عبارتند از:[list type=decimal]
[li]این سیستم از سلسله مراتب دارکتوری پشتیبانی نمیکند. این به این معنی است که فقط یک دارکتوری ریشه در این نوع سیستم فایل وجود دارد.[/li]
[li]آدرس دهی کلاسترها به صورت 12 بیتی صورت میگیرد. این به این معنی است که حداکثر تعداد کلاسترها 4096 است.[/li]
[li]به دلیل محدودیت فوق و با توجه با سکتورهای رزرو شده، حداکثر تعدار فایل در این سیستم 4077 فایل میباشد.[/li][/list]
این ها محدودیت های بزرگی هستند. در سیستم FAT16 امکان ذخیره بیش از 65535 فایل وجود دارد و ایجاد دایرکتوری نیز پشتیبانی میشود. باین حال فعلاً جهت سادگی کار از FAT12 استفاده خواهیم کرد. هرچند ساختار کلی FAT12 و FAT16 بسیار شبیه به هم هست. ولی FAT32 ساختار کاملاً متفاوتی داره. در آینده از FAT16 و FAT32 برای توسعه سیستم عامل استفاده خواهیم کرد.

[rayk]

پاسخ : برسی یک سیستم 386

نحوه ذخیره اطلاعات در FAT12
[hr]

سکتورهای ذخیره سازی فایل ها دایرکتوری ریشه جدولFAT دوم جدول FAT اول سکتورهای رزرو شده بوت سکتور این جدول نشاندهنده ساختار کلی یک دیسک فرمت شده با سیستم فایل FAT12 هستش. همونطور که میبینید سکتور راه انداز در اولین محل قرار گرفته. درک صحیح این جدول جهت لود کردن فایل های روی دیسک بسیار مفید خواهد بود. دقت کنید که دو جدول FAT وجود دارد که بعد از سکتور های رزرو شده قرار گرفته اند. ( اگر سکتور رزرو شده ای وجود نداشته باشد بعد از سکتور راه انداز قرار میگیرند ). این دو جدول معمولاً یکسان هستند و از دومی برای انجام اعمال بازیابی از دیسک در صورت از دست رفتن ناخواسته اطلاعات استفاده میشود. همچنین دونستن این نکهته مهمه که دارکتوری ریشه همیشه بعد از این دو جدول قرار میگیره. با این تفاسیر ما با دونستن تعداد سکتورها در هر FAT و تعداد سکتورهای رزرو شده و جمع کردن اونها با سکتور راه انداز میتونیم اولین سکتور مربوط به دایرکتوری ریشه رو به دست بیاریم که میدونیم مقدار این پارامترها در بلاک OEM تعریف شده. با جستجو در دایرکتوری ریشه هم میتونیم محل قرار گیری هر فایل روی دیسک رو پیدا کنیم. جدول FAT در واقع آرایه ای از مقادیر 12 بیتی را در خود ذخیره کرده که هر اندیس از این آرایه معرف وضعیت کلاستر معادل این اندیس است. یعنی مثلاً مقدار پنجم از این جدول مشخص کننده پنجمین کلاستر بوده و با توجه به مقدار این عدد 12 بیتی مشخص میشود که وضیعیت کلاستر مذکور چیست؟ این وضعیت میتونه یکی از حالات زیر باشه: 0x00 : این مقدار به معنی آزاد بودن کلاستر است. 0x01 : این مقدار نشان میدهد که این کلاستر جزو سکتورهای رزروشده هست. 0x002 تا 0xFEF :آ نشان میدهد که این کلاستر درحال استفاده توسط یک فایل میباشد. 0xFF0 تا 0xFF6 : این مقادیر توسط سیستم رزرو شده. 0xFF7 : این مقدار نشاندهنده یک کلاستر خراب و غیر قبل استفاده است. 0xFF8 تا 0xFFF : این مقادیر نشاندهنده کلاستر پایانی یک فایل هستند. در واقع جدول FAT آرایه ای از این مقادیر است. پس اگه اولین کلاستر یک فایل مثلاً X باشد با خوندن X امین مقدار از این جدول میتونیم اطلاعات خوبی راجع به فایل به دست بیاریم. اگه این مقدار بین 0xFF8 تا 0xFFF باشه یعنی این فایل فقط یک کلاستر داره و خوندن همین کلاستر به معنی خوندن کل فایل هست و اگه عددی بین 0x002 تا 0xFEF مثل Y باشه نشون میده که کلاستر شماره Y هم کلاستر بعدی فایل رو تشکیل میده و ... . همچنین یادتون باشه که توی بلاک OEM ما تعداد سکتور های یک کلاستر رو 1 تعریف کردیم. پس در اینجا مفهوم سکتور و کلاستر تقریباً یکسان است. پس حالا تنها مسئله باقی مونده اینه که چطور اولین کلاستر یا سکتور یک فایل رو پیدا کنیم. جدول دایرکتوری ریشه همونطور که مشاهده کردید جدول FAT مجموعه ای از مقادیر 12 بیتی بود. جدول دارکتوری ریشه هم ساختاری مشابه دارد با این تفاوت که این جدول به صورت آرایه ای از مقادیر 32 بایتی تشکیل میشه و هر عضو 32 بایتی مشخصات یک فایل رو نگهداری میکنه و هر بایت از این 32 بایت معنی بخصوصی داره. کاربرد هر بایت به صورته : 0 تا 7 : این 8 بایت حاوی نام فایل هستند ( در صورتی که نام فایل ها کمتر 8 کاراکتر باشه باید بایت ها پایانی با space پر بشه ) 8 تا 10 : این 3 بایت برای ذخیره پسوند فایل استفاده میشه ( در صورتی پسوند کمتر از 3 کاراکتر باشه باید از space استفاده کنیم ) 11 : برای ذخیره صفات فایل استفاده میشه و هر بیت معنی خاصی داره : [li]0 : فقط خواندنی[/li] [li]1 : مخفی[/li] [li]2 : سیستمی[/li] [li]3 : برچسب[/li] [li]4 : ساب دایرکتوری[/li] [li]5 : آرشیو[/li] [li]6 : کاربرد سیستمی[/li] [li]7 : بدون کاربرد[/li] [li]12 : بدون کاربرد[/li] 13 : زمان ساخت برحسب 10 میلی ثانیه ( بین 0 تا 199 ) 14 و 15 : یک عدد 16 بیتی برای نگهداری زمان ساخت فایل با فرمت زیر : [li]0 تا 4 : ثانیه تقسیم بر دو ( بین 0 تا 29 ). برای یافتن تانیه دقیق باید از یایت 13 کمک بگیریم[/li] [li]5 تا 10 : دقیقه ( بین 0 تا 59 )[/li] [li]11 تا 15 : ساعت ( بین 0 تا 23 )[/li] 16 و 17 : یک عدد 16 بیتی دیگر برای نگهداری زمان ساخت فایل با فرمت زیر : [li]0 تا 4 : روز ( بین 1 تا 31 )[/li] [li]5 تا 8 : ماه ( بین 1 تا 12 )[/li] [li]9 تا 15 : سال ( 0 = 1980 و 127 = 2107 )[/li] 18 و 19 : آخرین تاریخ دسترسی به فایل با فرمت بالا 20 و 21 : EA index هستش و در سیستم های OS/2 و NT کاربرد داره و به کار ما نمیاد. 22 و 23 : زمان آخرین اصلاحات روی فایل ( با فرمت 14 و 15 ) 24 و 25 : ترایخ آخرین اصلاحات روی فایل ( با فرمت 16 و 17 ) 26 و 27 : شماره اولین کلاستر فایل 28 تا 32 : اندازه فایل هرچند این لیست خیلی طولانی هست ولی خیلی ساده و واضحه. همین جا این توضیح رو اضافه کنیم که این مقادیر در واقع مواردی استاندار هستند، ولی ما توی سیستم عامل خودمون میتونیم معنی هر بیت و بایت رو تغییر بدیم و سیستم فایل خودمون رو سفارشی کنیم. ولی دونستن این مقادیر برای این مهمه که در اکثر سیستم عامل ها از جمله ویندوز این موارد رعایت شده و چون ما فایل کرنل و مرحله دوم بوت لودر رو از طریق ویندوز به فلاپی کپی میکنیم باید بدونیم که ویندوز فایل ها رو با این الگو توی دارکتوری ریشه ذخیره میکنه. توجه به این نکته خیلی مهمه که تعداد کاراکتر های تشکیل دهنده نام فایل و پسوند فایل حتماً باید برابر با 8 و 3 باشه و در صورتی که اسم و پسوند مورد نظر ما طولی کمتر از این مقادیر داسته باشه باید با فاصله جاهای خالی رو پر کنیم. همچنین 3 بایت مربوط به پسوند میتونه کلاً با فضای خالی پر بشه ولی اسم فایل باید حتماً یک کاراکتر داشته باشه. بنابراین اگه فایل مرحله دوم بوت لودر اسمش مثلاً Stage2.SYS باشه ما باید توی بوت لودر دنبال فایلی به اسم "Stage2 SYS" بگردیم. در این مورد به "Stage2.SYS" اسم خارجی فایل و "Stage2 SYS" اسم داخلی فایل گفته میشه.

[rayk]

پاسخ : برسی یک سیستم 386

جستجوی فایل و خواندن فایل در FAT12
[hr]

خب فکر کنم دیگه بحث خیلی طولانی شده و شما کم کم دارید از کلمه FAT12 متنفر میشد. پس دیگه باید وارد مرحله بعدی بشیم.
توی پست قبلی در مورد بلاک OEM یا همون بلاک بارامترهای بایاس bpb کمی با هم صحبت کردیم. حالا با استفاده از این پارامترها و مطالبی که تا حالا تو این پست مطرح شد می خواهیم خوندن فایل از روی دیسک رو شروع کنیم برای سادگی رجوع به bpb ها یه بار دیگه اینجا ذکرشون میکنیم.

bpbBytesPerSector:    DW  512
bpbSectorsPerCluster:  DB  1
bpbReservedSectors:   DW  1
bpbNumberOfFATs:     DB  2
bpbRootEntries:       DW  224
bpbTotalSectors:      DW  2880
bpbMedia:           DB  0xF0
bpbSectorsPerFAT:     DW  9
bpbSectorsPerTrack:   DW  18
bpbHeadsPerCylinder:  DW  2
bpbHiddenSectors:    DD  0
bpbTotalSectorsBig:    DD  0
bsDriveNumber:       DB  0
bsUnused:           DB  0
bsExtBootSignature:   DB  0x29
bsSerialNumber:      DD  0xa0a1a2a3
bsVolumeLabel:       DB  "MOS FLOPPY "
bsFileSystem:        DB  "FAT12 "

در ابتدا باید یه اسم مناسب برای فایل مورد نظر پیدا کنیم. از اونجایی که هدف از خوندن این فایل ، لود کردن کرنل یا همون هسته سیستم عامل و همچنین آماده سازی سیستم برای ورود به مود 32 بیتی هستش من اسم این فایل رو KRNLDR.SYS انتخاب میکنیم. یادتون باشه که طول این اسم حتماً 11 کاراکتر باشه پس توی برنامه از شکل داخلی اون یعنی "KRNLDR SYS" استفاده میکنیم. همچنین اسم فایل منبع این برنامه رو KRNLDR.ASM انتخاب می کنیم.
خب، برنامه ای که قراره ما به عنوان مرحله دوم بوت لودر بنوسیم فعلاً خیلی ساده هست. فعلاً هدف ما آموزش چگونگی لود کردن یک فایل از دیسک و اجرا کردن اونه. این برنامه تنها کاری که انجام میده نمایش دادن یک پیغام ساده روی مانیتور و بعد متوفق کردن سیستم با فرمان hlt هستش. بعد ها با توضیحاتی که در مورد مود 32 بیتی دادم یاد میگیرید که چطور از این فایل برای آماده سازی سیستم برای ورود به مود 32 بیتی استفاده کنید و همین برنامه رو تا حدی توسعه میدیم و بعدشم که نوبت به مهمترین بخش طراحی سیستم عامل، یعنی نوشتن کرنل توی مود 32 بیتی میرسه. سورس برنامه KRNLDR.ASM رو این زیر میتونید ببینید.

org  0x0
bits  16
jmp  main


;*************************************************;
; Prints a string
; DS=>SI: 0 terminated string
;************************************************;


Print:
  lodsb
  or    al, al
  jz    PrintDone
  mov  ah, 0eh
  int   10h
  jmp  Print
PrintDone:
  ret


;*************************************************;
; Second Stage Loader Entry Point
;************************************************;


main:
  cli
  push  cs
  pop   ds
  mov  si, Msg
  call   Print
  cli
  hlt


;*************************************************;
; Data Section
;************************************************;


Msg  db  "Preparing to load operating system...",13,10,0

حالا میتونید با فرمان های زیر برنامه رو ترجمه و روی فلاپی کپی کنید. دقت کنید که نیازی به استفاده از partcopy نیست و حتی از طریق Explorer ویندوز یا Send to هم میتونید این کار رو انجام بدید. در مورد کرنل هم که بعد ها مینویسیم وضع به همین ترتیب خواهد بود.

nasm -f bin KRNLDR.ASM -o KRNLDR.SYS
copy KRNLDR.SYS A:\KRNLDR.SYS