পাঠ ৫৩ · ৫৬-এর মধ্যে · মডিউল ১৩
Home / Courses / Operating Systems (OS) / কেস স্টাডি

কেস স্টাডি: Windows OS আর্কিটেকচার

Case study: Windows OS architecture
১০ মিনিট পড়া উচ্চ · Advanced Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • Windows NT-এর হাইব্রিড কার্নেল ডিজাইন এবং এটি কেন সম্পূর্ণ মনোলিথিক বা সম্পূর্ণ মাইক্রোকার্নেল নয়
  • Windows-এর প্রায়োরিটি শিডিউলিং ও প্রায়োরিটি বুস্টিং কীভাবে L11-এর aging ধারণার একটি বাস্তব প্রয়োগ
  • NTFS-এর জার্নালিং কীভাবে ext4-এর মতোই একই মূল সমস্যা সমাধান করে
  • Windows-এর ACL-ভিত্তিক সিকিউরিটি মডেল M11/L46-এর সাথে কীভাবে যুক্ত
  • Linux ও Windows-এর আর্কিটেকচারাল দর্শনের সরাসরি পাশাপাশি তুলনা

১ · NT কার্নেল — একটি হাইব্রিড ডিজাইন

আধুনিক প্রতিটি Windows সংস্করণের মূলে থাকা Windows NT কার্নেল M1/L04-এ শেখা দুটি চরমের (মনোলিথিক ও মাইক্রোকার্নেল) কোনোটিই পুরোপুরি নয় — এটি একটি হাইব্রিড কার্নেলHybrid Kernelমনোলিথিক ও মাইক্রোকার্নেলের মাঝামাঝি একটি ডিজাইন দর্শন — মাইক্রোকার্নেলের মতো একটি ছোট, লেয়ার্ড কোর (Executive) থাকে, কিন্তু পারফরম্যান্সের জন্য অনেক উপাদান এখনও কার্নেল মোডে চলে। — L52-এর Linux-এর বিপরীতে, যেখানে সবকিছু একটি বড় প্রোগ্রাম। Windows NT-এর কেন্দ্রে আছে একটি ছোট কোর, যাকে বলা হয় Executive — এটি প্রসেস/থ্রেড ম্যানেজমেন্ট, মেমরি ম্যানেজমেন্ট, IPC-র মতো মৌলিক সার্ভিস সরবরাহ করে, লেয়ার্ড ডিজাইনে (L04-এর লেয়ার্ড পদ্ধতির সাথে সরাসরি সমান্তরাল)। কিন্তু বিশুদ্ধ মাইক্রোকার্নেলের বিপরীতে, Windows NT ফাইল সিস্টেম ও গ্রাফিক্স ড্রাইভারের মতো অনেক উপাদানকেও কার্নেল মোডে (user-mode message-passing এর ওভারহেড এড়িয়ে) চালায় — L04-এর "মনোলিথিক দ্রুত কিন্তু কম আইসোলেটেড, মাইক্রোকার্নেল আইসোলেটেড কিন্তু ধীর" এই ট্রেড-অফের একটি ইচ্ছাকৃত, ব্যবহারিক মধ্যপন্থা।

Linux (L52) — মনোলিথিক শিডিউলার + মেমরি + FS + ড্রাইভার একটি একক ঠিকানা-স্পেসে (কার্নেল মোড) Windows NT — হাইব্রিড Executive (কোর সার্ভিস) FS/গ্রাফিক্স ড্রাইভার (পারফরম্যান্সের জন্য কার্নেল মোডে) মাইক্রোকার্নেলের লেয়ার্ড আদর্শ + মনোলিথিকের গতি হার্ডওয়্যার (উভয়ের জন্য)
দুটোই একই সমস্যা (কার্নেল ডিজাইন) সমাধান করে, কিন্তু ভিন্ন ট্রেড-অফ বেছে নিয়ে — L04-এর তত্ত্ব বাস্তবে এভাবেই রূপ নেয়।

২ · শিডিউলিং — প্রায়োরিটি + বুস্টিং

Windows-এর শিডিউলার M3/L12-এর মাল্টিলেভেল ফিডব্যাক কিউ-স্টাইল ধারণার একটি বাস্তব রূপ — প্রতিটি থ্রেডের একটি প্রায়োরিটি স্তর থাকে, এবং শিডিউলার সবসময় সর্বোচ্চ প্রায়োরিটি স্তরের রেডি থ্রেড চালায়। কিন্তু এখানেই L11-এর এজিং ধারণার একটি সরাসরি, বাস্তব প্রয়োগ দেখা যায় — প্রায়োরিটি বুস্টিংPriority Boostingযেসব থ্রেড দীর্ঘক্ষণ রেডি কিউতে অপেক্ষা করেছে বা সবেমাত্র I/O সম্পন্ন করেছে, তাদের প্রায়োরিটি সাময়িকভাবে বাড়িয়ে দেওয়া — L11-এর "aging" ধারণার একটি বাস্তব, নামযুক্ত সংস্করণ। — যেসব থ্রেড দীর্ঘক্ষণ অপেক্ষা করেছে বা সবেমাত্র I/O শেষ করেছে (এবং তাই সাধারণত ইন্টারঅ্যাকটিভ/রেসপন্সিভ হওয়ার কথা), তাদের প্রায়োরিটি সাময়িকভাবে বাড়িয়ে দেওয়া হয় — L11-এ যেভাবে আমরা তত্ত্বে দেখেছিলাম "অপেক্ষা যত বাড়ে, প্রায়োরিটিও তত বাড়ে, শেষমেশ starvation এড়ানো যায়" — Windows ঠিক এই আচরণটিই বাস্তবে প্রয়োগ করে।

৩ · NTFS জার্নালিং

Windows-এর স্ট্যান্ডার্ড ফাইল সিস্টেম NTFSও, L52-এর ext4-এর মতোই, M9/L41-এ শেখা জার্নালিং ব্যবহার করে ক্র্যাশ কনসিস্টেন্সি নিশ্চিত করতে — একটি মেটাডেটা-পরিবর্তন লগ (`$LogFile`) রাখে, যাতে সিস্টেম ক্র্যাশ হলেও ফাইল সিস্টেম দ্রুত একটি সামঞ্জস্যপূর্ণ অবস্থায় ফিরে আসতে পারে — Linux ও Windows সম্পূর্ণ ভিন্ন কার্নেল দর্শন হওয়া সত্ত্বেও, এই নির্দিষ্ট সমস্যায় (ক্র্যাশ কনসিস্টেন্সি) একই সমাধান বেছে নিয়েছে, কারণ এটিই বাস্তবে সবচেয়ে কার্যকর সমাধান।

৪ · সিকিউরিটি মডেল — ACL

Windows-এর সিকিউরিটি মডেল M11/L46-এ শেখা Access Control List (ACL) ধারণা ব্যাপকভাবে ব্যবহার করে — প্রতিটি ফাইল/অবজেক্টে একটি সিকিউরিটি ডিসক্রিপ্টর থাকে যা তালিকা করে কোন ইউজার/গ্রুপ কী অপারেশন করতে পারবে, ঠিক L46-এ "প্রতিটি অবজেক্ট জানে কারা তাকে অ্যাক্সেস করতে পারে" মডেলের মতো (ক্যাপাবিলিটি-ভিত্তিক মডেলের বিপরীতে)।

৫ · কোড: Windows সাবসিস্টেম ও Linux-এর সাথে পাশাপাশি তুলনা

নিচের কোড সেলে Windows-এর সাবসিস্টেমকে কোর্স মডিউলের সাথে যুক্ত করা হলো, এবং L52-এর Linux ডেটা পুনরায় ব্যবহার করে একটি সরাসরি Linux-বনাম-Windows তুলনা করা হলো।

Python
# Windows-এর বাস্তব সাবসিস্টেম -- এই কোর্সের মডিউল/পাঠের সাথে সরাসরি সংযোগ
windows_subsystems = {
    "NT Executive শিডিউলার": {
        "course_module": "M3 (CPU শিডিউলিং), L11-L12",
        "real_technique": "প্রায়োরিটি + মাল্টিলেভেল ফিডব্যাক-স্টাইল কিউ + প্রায়োরিটি বুস্টিং",
    },
    "NTFS ফাইল সিস্টেম": {
        "course_module": "M9 (ফাইল সিস্টেম), L41",
        "real_technique": "Write-ahead জার্নালিং ($LogFile) দিয়ে ক্র্যাশ কনসিস্টেন্সি",
    },
    "সিকিউরিটি সাবসিস্টেম": {
        "course_module": "M11 (সিকিউরিটি ও প্রোটেকশন), L46",
        "real_technique": "প্রতিটি অবজেক্টে ACL-ভিত্তিক সিকিউরিটি ডিসক্রিপ্টর",
    },
    "NT Executive কোর": {
        "course_module": "M1 (OS স্ট্রাকচার), L04",
        "real_technique": "হাইব্রিড কার্নেল -- লেয়ার্ড কোর + কার্নেল-মোড ড্রাইভার",
    },
}

# L52-এর ডেটা এখানে পুনরায় তৈরি করে সরাসরি পাশাপাশি তুলনা
linux_subsystems = {
    "CFS শিডিউলার": {"course_module": "M3, L09-L11", "real_technique": "Virtual-runtime-ভিত্তিক ন্যায্য শিডিউলিং"},
    "ext4 ফাইল সিস্টেম": {"course_module": "M9, L41", "real_technique": "Write-ahead জার্নালিং"},
    "সিকিউরিটি মডেল": {"course_module": "M11, L46-L47", "real_technique": "Unix পারমিশন বিট (DAC)"},
    "কার্নেল ডিজাইন": {"course_module": "M1, L04", "real_technique": "মনোলিথিক + লোডেবল মডিউল"},
}

print(f"{'Windows সাবসিস্টেম':28} | {'কোর্স মডিউল':22} | বাস্তব কৌশল")
print("-" * 100)
for name, info in windows_subsystems.items():
    print(f"{name:28} | {info['course_module']:22} | {info['real_technique']}")

print("\n=== Linux বনাম Windows -- আর্কিটেকচারাল কনট্রাস্ট ===")
comparison_rows = [
    ("কার্নেল ডিজাইন", "মনোলিথিক", "হাইব্রিড"),
    ("শিডিউলিং কৌশল", "Virtual runtime (CFS)", "প্রায়োরিটি + বুস্টিং"),
    ("ফাইল সিস্টেম", "ext4 (জার্নালিং)", "NTFS (জার্নালিং)"),
    ("সিকিউরিটি মডেল", "Unix পারমিশন বিট", "ACL"),
]
print(f"{'দিক':20} | {'Linux':26} | Windows")
print("-" * 70)
for aspect, linux_val, windows_val in comparison_rows:
    print(f"{aspect:20} | {linux_val:26} | {windows_val}")

    
মূল কথা · Key takeaway

একই মূল সমস্যাগুলোর (শিডিউলিং, মেমরি, ফাইল সিস্টেম, সিকিউরিটি) ভিন্ন ভিন্ন বাস্তব সমাধান থাকতে পারে — Linux ও Windows দুটোই সফল, বহুল-ব্যবহৃত OS, কিন্তু ভিন্ন ইঞ্জিনিয়ারিং ট্রেড-অফ বেছে নিয়েছে। এই কোর্সের তত্ত্ব দুটোকেই বোঝার একটি সাধারণ ভাষা দেয়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ Windows NT-কে "হাইব্রিড" বলা হয় কেন — এটি কি শুধু মনোলিথিকের আরেকটি নাম?

না। মনোলিথিক (L52-এর Linux) সবকিছুকে একটিমাত্র বড় প্রোগ্রামের অংশ হিসেবে দেখে, কোনো অভ্যন্তরীণ লেয়ারিং কাঠামো ছাড়াই। Windows NT-এর একটি স্পষ্ট, লেয়ার্ড Executive কোর আছে (মাইক্রোকার্নেলের ডিজাইন-দর্শনের সাথে সামঞ্জস্যপূর্ণ), কিন্তু সেই দর্শনটি পুরোপুরি অনুসরণ না করে, পারফরম্যান্সের জন্য ফাইল সিস্টেম/গ্রাফিক্সের মতো অংশকেও কার্নেল মোডে রাখে (যা বিশুদ্ধ মাইক্রোকার্নেল করত না) — এই মিশ্রণটাই একে "হাইব্রিড" করে তোলে।

প্র ০২ প্রায়োরিটি বুস্টিং না থাকলে Windows-এর প্রায়োরিটি শিডিউলিং-এ কোন ক্লাসিক সমস্যাটি হতে পারত (L11 দেখুন)?

Starvation — একটি নিম্ন-প্রায়োরিটি থ্রেড কখনোই CPU না পাওয়ার ঝুঁকিতে থাকত, যদি উচ্চ-প্রায়োরিটি থ্রেডগুলো ক্রমাগত আসতেই থাকে। L11-এ আমরা এটি "এজিং" দিয়ে সমাধান করেছিলাম — অপেক্ষার সময় বাড়লে প্রায়োরিটিও বাড়ানো। Windows-এর প্রায়োরিটি বুস্টিং ঠিক এই এজিং ধারণারই একটি নামযুক্ত, বাস্তব-জগতের প্রয়োগ।

প্র ০৩ Linux ও Windows দুটোই ফাইল সিস্টেমে জার্নালিং বেছে নিয়েছে, যদিও তাদের কার্নেল ডিজাইন সম্পূর্ণ ভিন্ন। এটি কী প্রমাণ করে?

এটি দেখায় যে কিছু সমস্যার সমাধান কার্নেল-ডিজাইন-নিরপেক্ষ — ক্র্যাশ কনসিস্টেন্সি (M9/L41) একটি মৌলিক ফাইল সিস্টেম সমস্যা, কার্নেল মনোলিথিক না হাইব্রিড তার সাথে সরাসরি সম্পর্কিত নয়। জার্নালিং যেহেতু প্রমাণিতভাবে কার্যকর ও পুরনো ধাঁচের ফুল-ডিস্ক-স্ক্যান রিকভারির চেয়ে অনেক দ্রুত, তাই স্বাধীনভাবে ডিজাইন করা দুটি ভিন্ন সিস্টেমও একই সমাধানে পৌঁছেছে — একটি শক্তিশালী ইঞ্জিনিয়ারিং নীতির একটি ভালো উদাহরণ।

অনুশীলন

  1. চিন্তা করুন: উপরের তুলনা টেবিলে "ভার্চুয়াল মেমরি/পেজ রিপ্লেসমেন্ট" নিয়ে একটি নতুন সারি যোগ করলে Linux (L52-এর clock অ্যালগরিদম) কলামে কী লিখবেন? Windows-এর জন্য কী লিখবেন (ইঙ্গিত: Windows-ও একটি working-set-ভিত্তিক অ্যাপ্রোচ ব্যবহার করে, M8/L35 দেখুন)?

    Linux: "ডিমান্ড পেজিং + clock/second-chance অ্যালগরিদম"। Windows: "ডিমান্ড পেজিং + working-set-ভিত্তিক ট্রিমিং" — Windows প্রতিটি প্রসেসের একটি working set (M8/L35-এর ধারণা) ট্র্যাক করে এবং মেমরি চাপ বাড়লে সেই working set থেকে কম-ব্যবহৃত পেজ ছেঁটে ফেলে (trim) — দুটোই ভিন্ন বাস্তবায়ন হলেও একই মূল লক্ষ্য (কম গুরুত্বপূর্ণ পেজ evict করা) অর্জন করে।

  2. পরীক্ষা করুন: কোড সেলে comparison_rows-এ একটি নতুন টাপল যোগ করুন — ("লোডেবল ড্রাইভার", "হ্যাঁ (LKM)", "হ্যাঁ (কিন্তু কার্নেল-মোডে বেশি অংশ)") — এবং তুলনা টেবিলটি আবার প্রিন্ট করে নিশ্চিত হন এটি সঠিকভাবে যোগ হয়েছে।

    তালিকায় যোগ করলে লুপ স্বয়ংক্রিয়ভাবে এটি নতুন সারি হিসেবে প্রিন্ট করবে, কারণ লুপটি comparison_rows-এর প্রতিটি টাপলের ওপর সাধারণভাবে চলে — এটি নিশ্চিত করে কোডটি হার্ডকোড করা নয়, সত্যিকারের ডেটা-চালিত।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
কেস স্টাডি: Linux কার্নেল আর্কিটেকচার