Windows-এর ভেতর — NT kernel, process, memory আর registry

১ · NT কেন আলাদা — Cutler, VMS আর ১৯৯৩

বাংলাদেশের বেশিরভাগ অফিস, ব্যাংকের কাউন্টার, সাইবার ক্যাফে আর বাসার ল্যাপটপে যে OS চলে, সেটি Windows. কিন্তু “Windows” নামের নিচে আসলে দুটি সম্পূর্ণ আলাদা বংশ ছিল। একটি MS-DOS-এর ওপর দাঁড়ানো — Windows 3.x, 95, 98, ME. অন্যটি শূন্য থেকে লেখা নতুন একটি kernel — Windows NT. ২০০১ সালে Windows XP থেকে সাধারণ ব্যবহারকারীর Windows-ও NT-তে চলে আসে, আর DOS-বংশ শেষ হয়। আজকের Windows 10, Windows 11, Windows Server — সবই NT.

NT-এর নকশাকারীরা শুরুতেই কয়েকটি লক্ষ্য লিখে নিয়েছিলেন। Microsoft-এর প্রকাশিত বিবরণ আর Windows Internals বইয়ের ধারায় সাধারণত এগুলো বলা হয় (তালিকার শব্দচয়ন সূত্রভেদে একটু আলাদা):

এই কোর্সে Windows এর আগেও বারবার এসেছে, কিন্তু টুকরো টুকরো ভাবে। এই পর্ব সেগুলো এক জায়গায় জোড়া লাগাবে — একই কথা আবার বলবে না, বরং কোন টুকরো কোথায় বসে, সেটি দেখাবে:

২ · বড় ছবি — user mode আর kernel mode-এ কে কোথায়

পর্ব ০৬-এ দেখেছেন, Windows-কে বলা হয় hybrid kernel: নকশায় আলাদা আলাদা “ব্যবস্থাপক”, কিন্তু গতির জন্য তারা সবাই একই kernel address space-এ চলে। এবার পুরো ভবনের নকশাটি এক ছবিতে দেখা যাক — ওপর থেকে নিচে।

User mode — সিস্টেম প্রসেসের দল

Task Manager-এর Details ট্যাব খুললে কয়েকটি প্রসেস সব Windows-এ দেখবেন। এরা কে, কী করে:

সাধারণ প্রোগ্রাম Windows-এর সাথে কথা বলে Win32 API দিয়ে — kernel32.dll, kernelbase.dll (Windows 7 থেকে kernel32-এর অনেক কাজ এখানে সরেছে), user32.dll, gdi32.dll. এগুলোকে বলে environment subsystem-এর DLL: একটি নির্দিষ্ট “OS-এর চেহারা” তারা প্রোগ্রামকে দেখায়। নিচের আসল দরজা কিন্তু একটিই — ntdll.dll. এখানে থাকে native API (NtCreateFile, NtReadFile, NtAllocateVirtualMemory…), image loader, heap-এর অংশ আর প্রতিটি system call-এর ছোট্ট “stub”:

ntdll!NtCreateFile:
    mov   r10, rcx          ; 1st argument: syscall clobbers rcx, so keep a copy
    mov   eax, 55h          ; system service number for NtCreateFile (this build)
    syscall                 ; CPU jumps to kernel mode: nt!KiSystemCall64
    ret                     ; back with an NTSTATUS in eax (0 = STATUS_SUCCESS)

পর্ব ০৫-এর Linux-এর syscall-এর সাথে প্রায় হুবহু মিল — নম্বর eax-এ, তারপর syscall instruction. পার্থক্য হলো নীতিতে: Linux-এর syscall নম্বর স্থির, প্রকাশ্য ABI. Windows-এর নম্বর build-ভেদে বদলায়, আর Microsoft শুধু Win32 API-কেই স্থির চুক্তি হিসেবে ধরে। তাই Windows-এ “সরাসরি syscall” লেখা প্রোগ্রাম পরের আপডেটে ভেঙে যেতে পারে।

Kernel mode — ntoskrnl, HAL, driver আর win32k

• ntoskrnl.exe-এর ওপরের অংশ — Executive: object manager, security reference monitor, process manager, memory manager, I/O manager, cache manager, configuration manager (registry), Plug and Play ও power manager, ALPC. এরা নীতি (policy) ঠিক করে।
• নিচের অংশ — “kernel”: thread dispatching ও scheduling, interrupt আর exception বিতরণ, multiprocessor সমন্বয়ের মৌলিক যন্ত্র (spinlock, dispatcher object). এটি mechanism দেয়।
• HAL (hal.dll): interrupt controller, timer, মাদারবোর্ডের পার্থক্য লুকায়। (নতুন Windows-এ HAL-এর অনেক অংশ kernel-এর ভেতরেই জুড়ে দেওয়া হয়েছে বলে Microsoft-এর সূত্রে উল্লেখ আছে।)
• Driver (.sys): ডিভাইস driver, file system driver (ntfs.sys), filter driver — সবই kernel mode-এ, একই অধিকারে।
• win32k.sys: জানালা ব্যবস্থাপক আর গ্রাফিক্সের kernel অংশ। NT 4.0 (১৯৯৬) গতির জন্য এটিকে csrss থেকে kernel-এ নামিয়ে আনে — এর দাম নিয়ে ভাবনার প্রশ্ন ২ দেখুন।

৩ · Object manager আর security — সবকিছুই object, হাতে handle

NT-এর সবচেয়ে সুন্দর নকশা-সিদ্ধান্ত সম্ভবত এটি: kernel যা কিছু সামলায় — ফাইল, প্রসেস, thread, event, mutex, semaphore, registry key, token, job, section (ভাগ করা মেমরি) — সবই একই কাঠামোর object. প্রতিটি object-এর একটি সাধারণ header থাকে (নাম, ধরন, security descriptor, গণনা) আর ধরনভেদে আলাদা body. এদের দেখভাল করে object manager.

প্রসেস কখনো object-এর আসল ঠিকানা পায় না। পায় একটি সংখ্যা — handle — যা আসলে প্রসেসের নিজস্ব handle table-এর একটি সারির নম্বর। প্রতিটি সারিতে থাকে object-এর pointer আর খোলার সময় অনুমোদিত অধিকার (granted access). Handle-এর মান ৪-এর গুণিতক (নিচের দুটি বিট অন্য কাজে লাগে)।

এখান থেকে দুটি গুরুত্বপূর্ণ নিয়ম বেরোয়:

• অধিকার যাচাই হয় খোলার সময়। CreateFile বা OpenProcess-এর সময় security reference monitor একবার যাচাই করে; এরপর handle দিয়ে প্রতিটি কাজে শুধু দেখা হয় চাওয়া কাজটি granted access-এর মধ্যে কি না। Unix-এর file descriptor-ও (পর্ব ৪১) একই নীতিতে চলে।
• দুটি গণনা: handle count (কতগুলো handle খোলা) আর pointer বা reference count (handle ছাড়াও kernel-এর ভেতরের কতগুলো জায়গা object-টিকে ধরে আছে)। Handle count শূন্য হলে নামওয়ালা object namespace থেকে সরে যায় (ফাইলের ক্ষেত্রে driver “cleanup” বার্তা পায়); reference count শূন্য হলে তবেই object মুছে যায়।

নামওয়ালা object থাকে একটি গাছের মতো object namespace-এ — Unix-এর ফাইল-গাছের মতো, কিন্তু kernel-এর ভেতরে। কয়েকটি পরিচিত ডাল: \Device\HarddiskVolume3 (একটি volume), \GLOBAL??\C: (একটি symbolic link, যা C:-কে আসল device-এ নিয়ে যায়), \Sessions\1\BaseNamedObjects\ (প্রোগ্রামের তৈরি নামওয়ালা event, mutex), \REGISTRY\MACHINE (registry). Sysinternals-এর WinObj দিয়ে এই গাছ ঘুরে দেখা যায়।

Win32 থেকে handle দেখতে এমন — কোডটি Windows-এর জন্য (এখানের Linux runner-এ চলবে না), আউটপুটও একটি উদাহরণ:

#include <windows.h>
#include <stdio.h>

int main(void) {
    HANDLE h = CreateFileW(L"C:\\data\\report.txt", GENERIC_READ, FILE_SHARE_READ,
                           NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (h == INVALID_HANDLE_VALUE) {
        printf("CreateFile failed, error %lu\n", GetLastError());  /* 2 = not found */
        return 1;
    }
    HANDLE dup;
    DuplicateHandle(GetCurrentProcess(), h, GetCurrentProcess(), &dup,
                    0, FALSE, DUPLICATE_SAME_ACCESS);      /* a second handle, same object */
    printf("handle %p, duplicate %p\n", h, dup);
    CloseHandle(h);
    CloseHandle(dup);                                      /* last handle closed */
    return 0;
}
/* example output:  handle 00000000000000A4, duplicate 00000000000000A8 */

এবার ভেতরের হিসাবটি নিজে চালিয়ে দেখুন। নিচের simulator দুটি প্রসেস A আর B-এর handle table আর প্রতিটি object-এর H (handle count) ও P (pointer count) রাখে। সরলতার জন্য handle শুরু হয়েছে 0x4 থেকে; আসল প্রসেসে loader আগেই অনেক handle খোলে, তাই মান বড় হয়।

// Simplified NT object manager: per-process handle tables, two counts per object
const objs = {}, tab = { A: [], B: [] };
const hv = i => "0x" + ((i + 1) * 4).toString(16);       // handle = (slot+1)*4
function open(p, name, access) {                          // create or open by name
  if (!objs[name]) objs[name] = { H: 0, P: 0 };
  let i = tab[p].indexOf(null);
  if (i < 0) i = tab[p].push(null) - 1;
  tab[p][i] = { name, access }; objs[name].H++; objs[name].P++;
  return hv(i);
}
function deref(name) {                                   // drop one pointer reference
  if (--objs[name].P === 0) { delete objs[name]; return " -> " + name + " DELETED"; }
  return "";
}
function close(p, h) {
  const i = parseInt(h, 16) / 4 - 1, e = tab[p][i];
  tab[p][i] = null; objs[e.name].H--; return deref(e.name);
}
function show(what, note = "") {
  console.log(what + note);
  for (const p in tab) console.log("   " + p + ": " + (tab[p].map((e, i) =>
    e ? hv(i) + "=" + e.name + "(" + e.access + ")" : hv(i) + "=free").join("  ") || "(empty)"));
  console.log("   objects: " + Object.keys(objs).map(n => n + " H=" + objs[n].H + " P=" + objs[n].P).join(", "));
}
let a1 = open("A", "data.txt", "RW"); show("1. A opens data.txt -> " + a1);
let a2 = open("A", "JobDone", "ALL"); show("2. A creates event JobDone -> " + a2);
let b1 = open("B", "JobDone", "SYNC"); show("3. B opens JobDone by name -> " + b1);
let b2 = open("B", "data.txt", "R"); show("4. A duplicates its handle into B -> " + b2);
objs["data.txt"].P++; show("5. kernel references data.txt (I/O in flight)");
show("6. A closes " + a1, close("A", a1));
show("7. B closes " + b2, close("B", b2));
show("8. I/O completes, kernel drops its reference", deref("data.txt"));
let a3 = open("A", "log.txt", "W"); show("9. A opens log.txt -> " + a3 + " (slot reused)");
show("10. A closes " + a2 + ", B closes " + b1, close("A", a2) + close("B", b1));

3. B opens JobDone by name -> 0x4
   A: 0x4=data.txt(RW)  0x8=JobDone(ALL)
   B: 0x4=JobDone(SYNC)
   objects: data.txt H=1 P=1, JobDone H=2 P=2
5. kernel references data.txt (I/O in flight)
   objects: data.txt H=2 P=3, JobDone H=2 P=2
7. B closes 0x8
   A: 0x4=free  0x8=JobDone(ALL)
   B: 0x4=JobDone(SYNC)  0x8=free
   objects: data.txt H=0 P=1, JobDone H=2 P=2
8. I/O completes, kernel drops its reference -> data.txt DELETED
9. A opens log.txt -> 0x4 (slot reused)
10. A closes 0x8, B closes 0x4 -> JobDone DELETED

Linux-এ এর সবচেয়ে কাছের জিনিস file descriptor table. এখানের runner Linux, তাই তুলনার জন্য নিচের bash block চালিয়ে দেখুন — এটি Windows নয়, Linux-এর সমতুল্য দৃশ্য:

echo "== Linux 'handle table': /proc/self/fd of this ls process =="
exec 3</etc/passwd 4>notes.txt          # the shell opens two more files
ls -l /proc/self/fd | awk 'NR > 1 {print $9, $10, $11}'
echo "== dup: fd 5 shares fd 3's open file (like DuplicateHandle) =="
exec 5<&3
ls -l /proc/$$/fd | awk 'NR > 1 && $9 >= 3 {print $9, $10, $11}'
echo "== per-process limit on open fds =="
ulimit -n
echo "== threads and resident memory (Windows: thread count, working set) =="
grep -E '^(Name|Threads|VmSize|VmRSS|VmHWM):' /proc/self/status
ps -o pid,nlwp,rss,vsz,comm -p $$
exec 3<&- 4>&- 5<&-

== Linux 'handle table': /proc/self/fd of this ls process ==
0 -> pipe:[921268467]
1 -> pipe:[921268508]
2 -> pipe:[921268469]
3 -> /etc/passwd
4 -> /home/wandbox/notes.txt
5 -> /proc/3/fd
== dup: fd 5 shares fd 3's open file (like DuplicateHandle) ==
255 -> /home/wandbox/prog.sh
3 -> /etc/passwd
4 -> /home/wandbox/notes.txt
5 -> /etc/passwd
== per-process limit on open fds ==
1024
== threads and resident memory (Windows: thread count, working set) ==
Name:	grep
VmSize:	    3660 kB
VmHWM:	    1864 kB
VmRSS:	    1864 kB
Threads:	1
    PID NLWP   RSS    VSZ COMMAND
      2    1  3408   4324 bash

Security reference monitor — token, SID, privilege আর UAC

“কে খুলছে?” — এই প্রশ্নের উত্তর রাখে প্রতিটি প্রসেসের access token. লগইনের সময় lsass পরিচয় যাচাই করার পর token তৈরি হয়, আর প্রতিটি নতুন প্রসেস সাধারণত parent-এর token-এর কপি পায়। Token-এ থাকে ব্যবহারকারীর SID, তার সব group-এর SID, privilege-এর তালিকা (যেমন SeShutdownPrivilege, SeDebugPrivilege), আর integrity level. Object খোলার সময় security reference monitor token-কে object-এর DACL-এর সাথে মেলায় — DACL-এর গঠন আর ACE-এর ক্রম পর্ব ৪৬-এ বিস্তারিত দেখেছেন, এখানে আর বলছি না।

Windows Vista (২০০৭) থেকে UAC চালু: administrator group-এর ব্যবহারকারী লগইন করলে দুটি token তৈরি হয় — একটি ছাঁটা (Medium integrity, admin-অধিকার নিষ্ক্রিয়) আর একটি পূর্ণ (High integrity). সাধারণ প্রোগ্রাম চলে ছাঁটাটিতে; পূর্ণ অধিকার লাগলে সম্মতির জানালা আসে, যা আলাদা “secure desktop”-এ দেখানো হয়, যাতে অন্য প্রোগ্রাম নকল ক্লিক পাঠাতে না পারে। Sandbox, AppContainer আর integrity level-এর ব্যবহার পর্ব ৪৯-এ।

৪ · Process, thread আর job — আর scheduler-এর এক ঝলক

Windows-এ process হলো একটি পাত্র: একটি address space, একটি handle table, একটি access token আর অন্তত একটি thread. CPU পায় শুধু thread — scheduler কখনো “প্রসেস” বাছে না, বাছে thread. Linux-এর মতো (পর্ব ১৪) Windows-ও one-to-one মডেল: প্রতিটি user thread-এর পেছনে একটি kernel thread.

Kernel-এর ভেতরে প্রতিটি প্রসেস একটি EPROCESS কাঠামো, যার শুরুতে বসানো থাকে kernel-স্তরের KPROCESS; প্রতিটি thread একটি ETHREAD, যার শুরুতে KTHREAD. Executive-এর ব্যবস্থাপকেরা E-অংশ দেখে, নিচের kernel (dispatcher) দেখে শুধু K-অংশ — স্তরভাগের সুন্দর উদাহরণ। User space-এ আছে তাদের ছায়া: PEB (process environment block) আর প্রতি thread-এ TEB — loader, heap আর thread-local storage এগুলো ব্যবহার করে।

Scheduler — পর্ব ১৯-এর সংক্ষিপ্ত পুনরাবৃত্তি

পর্ব ১৯-এ বিস্তারিত দেখেছেন: Windows-এর scheduler ৩২ স্তরের preemptive priority scheduler — ১৬–৩১ “real-time”, ১–১৫ variable, ০ শুধু zero page thread-এর জন্য (অংশ ৬-এ একে আবার দেখবেন)। প্রতিটি স্তরে Round Robin, আর variable স্তরে I/O শেষ হলে, foreground জানালায় আর অনাহারে থাকা thread-এ সাময়িক boost. এখানে শুধু দুটি নতুন কথা যোগ করি:

• Ready queue-র কাঠামো: প্রতিটি processor-এর জন্য ৩২টি ready queue আর একটি ৩২-বিটের “ready summary” — যে স্তরে কেউ অপেক্ষায়, সেই বিট ১. সর্বোচ্চ priority-র thread খুঁজতে একটি bit-scan instruction-ই যথেষ্ট, তাই সিদ্ধান্ত O(1).
• Quantum: client Windows-এ ডিফল্ট মোটামুটি ২টি clock tick, server-এ ১২টি — সার্ভারে লম্বা quantum মানে কম context switch, বেশি throughput. Clock tick-এর দৈর্ঘ্য যন্ত্রভেদে আলাদা; অনেক x64 যন্ত্রে প্রায় ১৫.৬ ms (তবে timer resolution প্রোগ্রাম বদলাতে পারে)। Client-এ foreground প্রসেসের quantum লম্বা করার একটি সেটিংও আছে।

নিজের Windows যন্ত্রে প্রসেস, handle আর working set একসাথে দেখতে PowerShell খুলুন (নিচের আউটপুট একটি উদাহরণ — আপনার সংখ্যা ভিন্ন হবে):

PS> Get-Process -Name explorer, notepad

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
   2861     112    80332     169164      45.67   6844   1 explorer
    247      18     5028      22908       0.12  11320   1 notepad

PS> (Get-Process -Id 6844).Threads.Count
98
PS> Get-Process | Sort-Object Handles -Descending | Select-Object -First 3 Name, Id, Handles

Name       Id Handles
----       -- -------
System      4    5412
explorer 6844    2861
lsass     912    2210

কলামগুলোর অর্থ: Handles = এই প্রসেসের handle table-এ খোলা handle; PM(K) = private bytes, অর্থাৎ এই প্রসেসের commit-এর হিসাব; WS(K) = working set, এখন RAM-এ থাকা page; SI = session নম্বর (১ = প্রথম লগইন করা ব্যবহারকারী; service-গুলো session 0-এ)। খেয়াল করুন, System প্রসেসেরও হাজার হাজার handle — kernel আর driver-এর নিজের খোলা object.

৫ · IRQL, DPC আর APC — CPU-র অগ্রাধিকারের সিঁড়ি

Thread-এর priority বলে “কোন thread আগে CPU পাবে”। কিন্তু interrupt তো কোনো thread নয় — নেটওয়ার্ক কার্ড যেকোনো মুহূর্তে বাধা দিতে পারে। এজন্য NT-তে দ্বিতীয় একটি সিঁড়ি আছে: প্রতিটি core এই মুহূর্তে কোন IRQL-এ চলছে। পর্ব ৩৯-এ সংজ্ঞা দেখেছেন; এখানে পুরো সিঁড়িটি (x64):

নিয়ম একটাই: একটি core যে IRQL-এ চলছে, তার সমান বা নিচের সব interrupt অপেক্ষা করে। x64-এ বর্তমান IRQL CPU-র CR8 register-এ থাকে। আর scheduler নিজে DISPATCH_LEVEL-এ চলে বলে সেই স্তরে বা ওপরে কোনো thread switch সম্ভব নয় — তাই সেখানে page fault হলে (যার মেটাতে ডিস্কের অপেক্ষা লাগে) Windows এগোতে পারে না, আর IRQL_NOT_LESS_OR_EQUAL বা DRIVER_IRQL_NOT_LESS_OR_EQUAL নামের নীল পর্দা (bugcheck) দেখায়। এটি ভুল driver-এর সবচেয়ে পরিচিত লক্ষণ।

ISR-কে খুব ছোট রাখতে হয়, তাই ভারী কাজ যায় DPC-তে (Linux-এর softirq-এর সমতুল্য, পর্ব ৩৯)। আর কোনো নির্দিষ্ট thread-এর context-এ কাজ করাতে লাগে APC — যেমন I/O শেষে ফলাফল সেই thread-এর address space-এ পৌঁছে দেওয়া। User APC পৌঁছায় কেবল তখন, যখন thread “alertable” অপেক্ষায় (SleepEx, WaitForSingleObjectEx) — Unix signal-এর মতো চলমান কোডে হঠাৎ ঢুকে পড়ে না (পর্ব ১৩)। নিচে একটি নেটওয়ার্ক প্যাকেট আসার পুরো ঘটনা দেখুন (মানগুলো উদাহরণ, প্রবাহটি সরলীকৃত):

৬ · Memory manager — VAD, reserve-commit আর page-এর তালিকা

Address space-এর খাতা — VAD

প্রতিটি প্রসেসের address space-এর কোন অংশ কী কাজে বরাদ্দ, তা memory manager রাখে VAD (virtual address descriptor)-এর একটি self-balancing গাছে — প্রতিটি node একটি টানা এলাকা: কোথা থেকে কোথা, private না ফাইল-ম্যাপ করা, কী অধিকার। Linux-এর VMA-র (পর্ব ৩৮) প্রায় হুবহু সমতুল্য। Page table-এ তখনো কিছু না থাকলেও VAD দেখে page fault-এর সময় বোঝা যায় ঠিকানাটি বৈধ কি না।

Reserve বনাম commit — জায়গা ঠিক করা আর প্রতিশ্রুতি দেওয়া

Windows-এ মেমরি চাওয়ার দুটি আলাদা ধাপ, যা VirtualAlloc-এ স্পষ্ট দেখা যায়:

• Reserve (MEM_RESERVE): শুধু virtual ঠিকানার একটি এলাকা আটকে রাখা — VAD-এ একটি node; কোনো RAM বা pagefile খরচ নেই। ধরুন কমিউনিটি সেন্টারে বিয়ের জন্য তারিখ বুক করলেন, কিন্তু অতিথির সংখ্যা এখনো জানাননি।
• Commit (MEM_COMMIT): OS প্রতিশ্রুতি দেয় যে প্রয়োজনে এই page-গুলোর জন্য RAM বা pagefile-এ জায়গা থাকবে। প্রতিটি commit যোগ হয় সিস্টেমের commit charge-এ, যা commit limit (মোটামুটি RAM + সব pagefile-এর আকার) ছাড়াতে পারে না।
• প্রথম ছোঁয়া: commit করলেও physical page আসে কেবল প্রথম ছোঁয়ায় — demand-zero fault (পর্ব ৩৫-এর zero-fill-on-demand).

Thread-এর stack এর সুন্দর উদাহরণ: ডিফল্টে সাধারণত ১ MiB reserve, শুরুতে শুধু কয়েকটি page commit, আর তার নিচে একটি guard page — stack বাড়তে বাড়তে guard page ছুঁলে আরও commit হয়। Linux-এর সাথে দর্শনের পার্থক্যটি পর্ব ৩৮-এ দেখেছেন: Linux overcommit করে আর সংকটে OOM killer ডাকে; Windows প্রতিশ্রুতির মুহূর্তেই হিসাব মেলায়, সীমা ছাড়ালে VirtualAlloc ব্যর্থ হয় (pagefile নিজে থেকে বাড়ার সুযোগ থাকলে আগে সেটি বাড়ে)।

Working set আর page frame-এর খাতা

পর্ব ৩৭-এ দেখেছেন, Windows প্রতিটি প্রসেসের working set আলাদা রাখে আর working set manager চাপ বাড়লে সেখান থেকে page ছাঁটে। কিন্তু ছাঁটা page যায় কোথায়? উত্তর: PFN database — RAM-এর প্রতিটি physical page frame-এর জন্য একটি entry, যাতে লেখা frame-টি এখন কোন অবস্থায়। অবস্থা অনুযায়ী frame-গুলো কয়েকটি তালিকায় সাজানো:

ছাঁটা page-এর page table entry “invalid” হয়, কিন্তু তখনো frame-টিকে চিনে রাখে — একে বলে transition অবস্থা। তাই প্রসেস আবার চাইলে ডিস্ক না ছুঁয়েই page ফেরত আসে: soft fault. Standby তালিকা আসলে Vista থেকে ৮টি priority-ভিত্তিক তালিকা, আর SysMain (আগের SuperFetch) service আগেভাগে প্রায়ই-ব্যবহৃত ডেটা ডিস্ক থেকে Standby-তে এনে রাখে। এজন্যই Windows-এ “free” মেমরি কম দেখালেও ভয়ের কিছু নেই — Standby হলো ঝুঁকিহীন cache, Linux-এর page cache-এর মতো। এবার একটি frame-এর পুরো জীবনচক্র দেখুন:

একই নিয়ম এবার চারটি frame আর দুটি প্রসেসে চালিয়ে দেখুন। এখানে A-এর একটি code page C-ও আছে, যা app.exe ফাইল থেকে আসে — ফাইল-ব্যাকড পরিষ্কার page, তাই ছাঁটা হলে সোজা Standby-তে যায়।

// Simplified Windows page lists: 4 physical frames, processes A and B
const L = { Free: ["F0", "F1", "F2", "F3"], Zeroed: [], Standby: [], Modified: [] };
const ws = { A: {}, B: {} }, owner = {}, onDisk = new Set(), dirty = new Set();
const pop = (...ls) => { for (const l of ls) if (L[l].length) return [L[l].shift(), l]; };
function give(p, pg, f) { ws[p][pg] = f; owner[f] = p + ":" + pg; }
function touch(p, pg) {                       // page not in working set -> fault
  const id = p + ":" + pg;
  for (const l of ["Standby", "Modified"]) {
    const i = L[l].findIndex(f => owner[f] === id);
    if (i >= 0) { give(p, pg, L[l].splice(i, 1)[0]); return "SOFT fault, back from " + l; }
  }
  if (onDisk.has(id)) { const [f, l] = pop("Free", "Zeroed", "Standby");
    give(p, pg, f); return "HARD fault, disk read into " + f + " (from " + l + ")"; }
  const [f, l] = pop("Zeroed", "Free", "Standby"), old = owner[f]; give(p, pg, f); dirty.add(id);
  return "demand-zero: " + f + " from " + l + (l === "Standby" ? " (was " + old + ")" : "")
    + (l === "Zeroed" ? "" : ", zeroed first");
}
function trim(p) {                            // working set manager removes all pages
  for (const pg in ws[p]) { const f = ws[p][pg]; L[dirty.has(p + ":" + pg) ? "Modified" : "Standby"].push(f); }
  ws[p] = {}; return "clean -> Standby, dirty -> Modified";
}
function writer() { for (const f of L.Modified) { onDisk.add(owner[f]); dirty.delete(owner[f]); }
  L.Standby.push(...L.Modified.splice(0)); return "written to pagefile, now Standby"; }
function exit(p) { for (const pg in ws[p]) { L.Free.push(ws[p][pg]); delete owner[ws[p][pg]]; }
  ws[p] = {}; return "private pages -> Free"; }
const lst = l => l + "[" + L[l].map(f => l === "Standby" || l === "Modified" ? f + "=" + owner[f] : f) + "]";
const wsS = p => p + "{" + Object.entries(ws[p]).map(e => e.join("=")) + "}";
const show = (s, r) => console.log(s + ": " + r + "\n   " + ["Free", "Zeroed", "Standby", "Modified"].map(lst).join(" ") + "  WS " + wsS("A") + " " + wsS("B"));
show("1 zero page thread", (L.Zeroed.push(...L.Free.splice(0, 2)), "F0,F1 zeroed"));
show("2 A touches heap H", touch("A", "H"));
onDisk.add("A:C"); show("3 A runs code page C", touch("A", "C"));
show("4 trim A", trim("A")); show("5 A touches C", touch("A", "C")); show("6 modified page writer", writer());
show("7 B touches X", touch("B", "X")); show("8 B touches Y", touch("B", "Y"));
show("9 B touches Z", touch("B", "Z")); show("10 B exits", exit("B"));
show("11 A touches H", touch("A", "H"));

1 zero page thread: F0,F1 zeroed
   Free[F2,F3] Zeroed[F0,F1] Standby[] Modified[]  WS A{} B{}
2 A touches heap H: demand-zero: F0 from Zeroed
   Free[F2,F3] Zeroed[F1] Standby[] Modified[]  WS A{H=F0} B{}
3 A runs code page C: HARD fault, disk read into F2 (from Free)
   Free[F3] Zeroed[F1] Standby[] Modified[]  WS A{H=F0,C=F2} B{}
4 trim A: clean -> Standby, dirty -> Modified
   Free[F3] Zeroed[F1] Standby[F2=A:C] Modified[F0=A:H]  WS A{} B{}
5 A touches C: SOFT fault, back from Standby
   Free[F3] Zeroed[F1] Standby[] Modified[F0=A:H]  WS A{C=F2} B{}
6 modified page writer: written to pagefile, now Standby
   Free[F3] Zeroed[F1] Standby[F0=A:H] Modified[]  WS A{C=F2} B{}
7 B touches X: demand-zero: F1 from Zeroed
   Free[F3] Zeroed[] Standby[F0=A:H] Modified[]  WS A{C=F2} B{X=F1}
8 B touches Y: demand-zero: F3 from Free, zeroed first
   Free[] Zeroed[] Standby[F0=A:H] Modified[]  WS A{C=F2} B{X=F1,Y=F3}
9 B touches Z: demand-zero: F0 from Standby (was A:H), zeroed first
   Free[] Zeroed[] Standby[] Modified[]  WS A{C=F2} B{X=F1,Y=F3,Z=F0}
10 B exits: private pages -> Free
   Free[F1,F3,F0] Zeroed[] Standby[] Modified[]  WS A{C=F2} B{}
11 A touches H: HARD fault, disk read into F1 (from Free)
   Free[F3,F0] Zeroed[] Standby[] Modified[]  WS A{C=F2,H=F1} B{}

Memory compression আর pagefile

Windows 10-এর একটি প্রথম দিকের বড় আপডেট (২০১৫) থেকে memory compression চালু: Modified তালিকার অনেক page সরাসরি pagefile-এ না লিখে চেপে ছোট করে RAM-এর একটি “compression store”-এ রাখা হয়। এই store থাকে “Memory Compression” নামের একটি বিশেষ প্রসেসের working set-এ; Task Manager-এর Performance → Memory অংশে “In use (Compressed)” লেখায় এর আকার দেখা যায়। চেপে রাখা page ফেরত আনা ডিস্ক-পড়ার চেয়ে সাধারণত অনেক দ্রুত, তবে CPU খরচ হয়। Pagefile তবু দরকারি: commit limit-এর অংশ সে, আর crash dump লিখতেও প্রায়ই লাগে। তাই “pagefile বন্ধ করে দিন” পরামর্শটি সাধারণত ক্ষতিকর — অনেক প্রোগ্রাম commit সীমায় আটকে ব্যর্থ হতে পারে।

৭ · I/O manager, IRP, driver আর NTFS

Windows-এর I/O হলো packet-চালিত। প্রতিটি অনুরোধের জন্য I/O manager একটি IRP (I/O request packet) বানায় — অনুরোধের ধরন (create, read, write, device control…), buffer, ফলাফলের জায়গা, আর stack-এর প্রতিটি driver-এর জন্য একটি করে “stack location”. IRP তারপর driver stack-এর ওপর থেকে নিচে যায়: প্রতিটি driver নিজের অংশ করে, দরকারে নিচে পাঠায়, শেষে কেউ সম্পন্ন করলে ফলাফল ওপরে ফেরে। অফিসের ফাইল-চালানের মতো — একটি ফাইল টেবিল থেকে টেবিলে যায়, প্রত্যেকে নোট লিখে স্বাক্ষর দেন।

অংশ ৩-এর CreateFileW call-টি এবার শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন:

CreateFileW(L"C:\\data\\report.txt", GENERIC_READ, ...)
  // DOS path → NT path (ntdll-এর সহায়ক ফাংশন)
  "\??\C:\data\report.txt"
  NtCreateFile(&h, FILE_GENERIC_READ, &objAttr, &iosb, ...)

mov  r10, rcx
mov  eax, 55h     ; NtCreateFile-এর নম্বর (এই build)
syscall

KiSystemCall64:   kernel stack-এ যাওয়া, register রাখা
  table[0x55] → NtCreateFile → IoCreateFile
  user-এর pointer যাচাই (ProbeForRead) — বিশ্বাস নয়

\??\C:                → symbolic link
  → \Device\HarddiskVolume3   (device object)
বাকি অংশ "\data\report.txt" → device-এর parse routine

FILE_OBJECT  { FileName = "\data\report.txt", ... }
IRP { MajorFunction = IRP_MJ_CREATE,
      StackLocation[filter], StackLocation[ntfs], ... }
IoCallDriver(top of stack, irp)

fltmgr.sys + minifilter (যেমন antivirus)  দেখে, চাইলে আটকায়
ntfs.sys   directory index → MFT record, DACL যাচাই
volmgr → partmgr → disk.sys → storport → NVMe miniport

IRP.IoStatus = STATUS_SUCCESS  → ওপরে ফেরে
অথবা STATUS_OBJECT_NAME_NOT_FOUND → kernelbase → ERROR_FILE_NOT_FOUND (2)

0x00A4 → FILE_OBJECT (report.txt)   granted: FILE_GENERIC_READ
প্রোগ্রাম পেল HANDLE 0xA4; পরের ReadFile-এ আর নাম খোঁজা নেই

Asynchronous I/O Windows-এর শক্তির জায়গা: ফাইল “overlapped” মোডে খুললে ReadFile সাথে সাথে ফেরে, IRP পেছনে চলতে থাকে, আর শেষ হলে খবর আসে event, APC বা I/O completion port-এ। বহু সার্ভার-সফটওয়্যার IOCP-র ওপর দাঁড়ানো; Linux-এর io_uring-এর সাথে তুলনা পর্ব ৩৯-এ।

Driver মডেল — WDM থেকে KMDF/UMDF

WDM (Windows Driver Model, Windows 98/2000-এর যুগ থেকে) হলো IRP-ভিত্তিক মূল মডেল, কিন্তু সঠিকভাবে লেখা কঠিন — Plug and Play, power, বাতিল হওয়া IRP, সবকিছু নিজে সামলাতে হয়। তাই Microsoft পরে Windows Driver Frameworks দেয়: KMDF (kernel-mode, WDM-এর ওপর একটি নিরাপদ কাঠামো) আর UMDF (user-mode — driver crash করলেও kernel পড়ে না; পর্ব ৩৯)। 64-bit Windows-এ kernel-mode driver সই করা (signed) হতে হয়, আর x64 kernel-এ Kernel Patch Protection (“PatchGuard”) kernel-এর গুরুত্বপূর্ণ কাঠামো বদলানো ধরলে সিস্টেম থামিয়ে দেয়। তবু একটি সই করা driver-এর ভুলও পুরো সিস্টেম ফেলে দিতে পারে — ভাবনার প্রশ্ন ৫ দেখুন।

NTFS আর ReFS — সংক্ষেপে

NTFS-এর কেন্দ্র MFT (পর্ব ৪৩) আর metadata journal $LogFile (পর্ব ৪৪)। বাকি বৈশিষ্ট্যগুলো এক নজরে:

• নিরাপত্তা: প্রতিটি ফাইল-ফোল্ডারের security descriptor (DACL/SACL) — অংশ ৩-এর token এখানেই মেলানো হয়।
• Alternate data stream: একটি ফাইলের একাধিক নামওয়ালা ডেটা-ধারা। ইন্টারনেট থেকে নামানো ফাইলে Windows Zone.Identifier নামের একটি stream রাখে — “এটি বাইরে থেকে এসেছে” সতর্কতা এখান থেকেই।
• Compression আর EFS: প্রতি-ফাইল সংকোচন, আর ব্যবহারকারীর certificate-এ বাঁধা প্রতি-ফাইল এনক্রিপশন। পুরো ডিস্কের জন্য আলাদা ব্যবস্থা BitLocker.
• আরও: hard link, reparse point (symbolic link, junction), sparse file, আর USN change journal (কোন ফাইল কবে বদলাল তার খাতা — backup ও search-এর কাজে)।

ReFS (Resilient File System) এসেছে Windows Server 2012-এর সাথে: metadata-র checksum, পুরোনো জায়গায় না লিখে নতুন জায়গায় লেখা (copy-on-write ধাঁচ, পর্ব ৪৪), খুব বড় volume আর Storage Spaces-এর সাথে মিলে নিজে মেরামত। তবে এতে NTFS-এর সব বৈশিষ্ট্য নেই (যেমন EFS), আর সাধারণ Windows সাধারণত ReFS থেকে বুট করে না; Windows 11-এর “Dev Drive” ReFS ব্যবহার করে। সংস্করণভেদে সমর্থন বদলেছে, তাই নির্দিষ্ট সংস্করণের Microsoft ডকুমেন্টেশন দেখে নেওয়া ভালো।

৮ · Registry, service আর বুট

Registry — একটি কেন্দ্রীয় সেটিং-খাতা

Linux-এ সেটিং ছড়িয়ে থাকে /etc-এর শত শত text ফাইলে। Windows রাখে একটি গাছের মতো ডেটাবেসে — registry. গাছের ভেতরের ঘর key (ফোল্ডারের মতো), আর প্রতিটি key-তে নামওয়ালা value — ধরন REG_SZ (লেখা), REG_DWORD (৩২-বিট সংখ্যা), REG_QWORD, REG_BINARY, REG_MULTI_SZ ইত্যাদি। Kernel-এর configuration manager এটি সামলায়, আর এটিও object — \REGISTRY\MACHINE namespace-এ।

ডিস্কের প্রতিটি ফাইলকে বলে hive. Hive-এর পাশে .LOG1, .LOG2 ফাইল থাকে — বদল আগে log-এ লেখা হয়, তারপর hive-এ, যাতে বিদ্যুৎ চলে গেলে hive নষ্ট না হয় (পর্ব ৪৪-এর journaling-এর আরেক রূপ)। Windows Vista-তে transactional registry-ও আসে, তবে Microsoft এখন নতুন প্রোগ্রামে এটি ব্যবহার না করার পরামর্শ দেয়। Windows 10-এর ২০১৮ সালের একটি আপডেট থেকে hive-গুলো “Registry” নামের একটি ছোট প্রসেসের address space-এ map করা থাকে। পড়া নিরাপদ — PowerShell-এ (আউটপুট উদাহরণ):

PS> Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
>>   Select-Object ProductName, DisplayVersion, CurrentBuild, UBR, InstallationType

ProductName      : Windows 10 Pro
DisplayVersion   : 23H2
CurrentBuild     : 22631
UBR              : 4317
InstallationType : Client

PS> Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\hivelist' |
>>   Select-Object '\REGISTRY\MACHINE\SYSTEM', '\REGISTRY\MACHINE\SOFTWARE' | Format-List

\REGISTRY\MACHINE\SYSTEM   : \Device\HarddiskVolume3\Windows\System32\config\SYSTEM
\REGISTRY\MACHINE\SOFTWARE : \Device\HarddiskVolume3\Windows\System32\config\SOFTWARE

দুটি মজার জিনিস চোখে পড়ে। প্রথমত, build 22631 আসলে Windows 11 (23H2), অথচ ProductName এখনো “Windows 10 Pro” — বহু পুরোনো প্রোগ্রামের সামঞ্জস্য রক্ষায় এই value বদলানো হয়নি বলে ব্যাপকভাবে উল্লেখ করা হয়; তাই সংস্করণ বুঝতে build নম্বর দেখুন। দ্বিতীয়ত, hivelist দেখায় hive-এর ঠিকানা object namespace-এর ভাষায় — \Device\HarddiskVolume3, অংশ ৩-এর সেই গাছ।

Service আর Service Control Manager

Service হলো লগইন ছাড়াই পেছনে চলা প্রোগ্রাম — Linux-এর daemon বা systemd unit-এর (পর্ব ০৭) সমতুল্য। প্রতিটি service-এর বিবরণ registry-তে: HKLM\SYSTEM\CurrentControlSet\Services\<নাম> — Start value (0 = boot, 1 = system, 2 = automatic, 3 = manual, 4 = disabled), কোন ফাইল চালাতে হবে, কোন অ্যাকাউন্টে (LocalSystem, LocalService, NetworkService). মজার কথা, driver-এর বিবরণও এই একই key-তে থাকে। services.exe-এর SCM এগুলো চালায়; অনেক service একসাথে থাকে svchost.exe-এর ভেতরে। Vista থেকে service চলে session 0-এ, আর ব্যবহারকারী session 1 বা তার পরে — যাতে service-এর জানালা ব্যবহারকারীর ডেস্কটপে মিশে আক্রমণের পথ না খোলে।

PS> Get-Service -Name EventLog, Spooler, WSearch, wuauserv

Status   Name               DisplayName
------   ----               -----------
Running  EventLog           Windows Event Log
Running  Spooler            Print Spooler
Running  WSearch            Windows Search
Stopped  wuauserv           Windows Update

PS> Get-CimInstance Win32_Service -Filter "Name='Spooler'" |
>>   Select-Object Name, StartMode, StartName, PathName

Name    StartMode StartName   PathName
----    --------- ---------   --------
Spooler Auto      LocalSystem C:\Windows\System32\spoolsv.exe

Windows Update “Stopped” দেখে ঘাবড়াবেন না — এটি প্রয়োজনমতো চালু হয় (trigger-start). আর Print Spooler চলছে LocalSystem-এ, অর্থাৎ সর্বোচ্চ অধিকারে — এজন্যই ২০২১ সালের “PrintNightmare” নামে পরিচিত দুর্বলতাগুলো এত গুরুতর ছিল, আর প্রিন্টার না থাকা সার্ভারে অনেক প্রতিষ্ঠান এই service বন্ধ রাখে। প্রতিরক্ষার সাধারণ নীতি: যে service দরকার নেই, তা নীতিমালা মেনে বন্ধ করা, আর আপডেট নিয়মিত রাখা।

বুট — পর্ব ০৭-এর Windows অংশ

UEFI firmware \EFI\Microsoft\Boot\bootmgfw.efi — Windows Boot Manager — চালায় (পর্ব ০৭)। এটি BCD (boot configuration data — নিজেও registry-র ফরম্যাটের একটি hive) পড়ে কোন Windows চালাবে ঠিক করে, তারপর winload.efi চালায়। Winload মেমরিতে আনে ntoskrnl.exe, HAL, SYSTEM hive আর Start = 0 লেখা boot driver-গুলো (যেমন ডিস্কের driver — নইলে kernel ডিস্কই পড়তে পারত না)। Kernel ধাপে ধাপে executive চালু করে, System প্রসেস বানায়, বাকি driver লোড করে, তারপর প্রথম user-mode প্রসেস smss.exe চালায়। smss session 0-এ csrss আর wininit (→ services, lsass), আর session 1-এ csrss আর winlogon চালায়; লগইনের পর userinit → explorer. Secure Boot এই শিকলের প্রতিটি ধাপের সই যাচাই করে (পর্ব ০৭, ৪৯)। আর “Fast startup” চালু থাকলে Shut down আসলে kernel session-এর একটি hibernate — তাই driver-সমস্যায় “Restart” আর “Shut down”-এর আচরণ আলাদা হতে পারে।

৯ · WSL আর পর্যবেক্ষণের টুল

WSL1 বনাম WSL2 — অনুবাদক বনাম আসল kernel

WSL-এর দুটি প্রজন্ম NT-এর দুটি আলাদা ক্ষমতা দেখায়:

ব্যবহারিক পরামর্শ: WSL2-এ কাজ করলে প্রজেক্টের ফাইল Linux-এর দিকে (~/project) রাখুন, /mnt/c/...-তে নয়। আর মনে রাখুন, এই কোর্সের Linux-কমান্ড WSL2-এ প্রায় হুবহু চলবে, কিন্তু তারা দেখাবে VM-এর ভেতরের Linux kernel — Windows-এর NT kernel নয়।

Windows-কে চোখে দেখার টুল — শুধু নিজের যন্ত্রে, পর্যবেক্ষণের জন্য

Sysinternals-এর টুলগুলো Mark Russinovich ও Bryce Cogswell-এর তৈরি; ২০০৬ সালে Microsoft প্রতিষ্ঠানটি কিনে নেয়, আর টুলগুলো এখন Microsoft-এর সাইট থেকে বিনামূল্যে পাওয়া যায় — শুধু সেখান থেকেই নামাবেন। এগুলো দিয়ে নিজের যন্ত্র বা প্রতিষ্ঠানের অনুমোদিত যন্ত্র পর্যবেক্ষণ করুন; kernel debugging শিখতে একটি আলাদা পরীক্ষামূলক VM ব্যবহার করাই নিরাপদ।

১০ · AI-এর যুগে Windows internals

Windows-এর সমস্যা নিয়ে AI-কে প্রশ্ন করলে উত্তর দ্রুত আসে, কিন্তু Windows-এর বিশেষ কিছু ফাঁদ আছে। এক, সংস্করণের গোলমাল — Windows 7, 10, 11 আর Server-এর আচরণ মিশিয়ে ফেলা, বা অনেক আগে বাদ পড়া ফিচারকে বর্তমান বলা। দুই, ভুল OS — প্রশ্ন Windows নিয়ে, উত্তরে Linux-এর chmod বা sudo. তিন, “performance tweak”-এর নামে ক্ষতিকর পরামর্শ — pagefile বন্ধ, অজানা service বন্ধ, registry cleaner, এমনকি Defender বা UAC বন্ধ করা, বা Set-ExecutionPolicy Unrestricted. চার, kernel-এর আত্মবিশ্বাসী কিন্তু ভুল তথ্য — IRQL-এর নিয়ম, quantum-এর দৈর্ঘ্য, syscall নম্বর।

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• উত্তরটি আমার Windows সংস্করণ আর build-এর জন্য কি না দেখেছি (winver বা CurrentBuild); Linux-এর কমান্ড বা অন্য সংস্করণের পথ এলে বাদ দিয়েছি
• Registry বা service বদলের আগে key export করেছি বা restore point রেখেছি, আর পরিবর্তনটি কীভাবে উল্টাব জানি
• নিরাপত্তা দুর্বল করে এমন কিছু (Defender, UAC, Secure Boot বন্ধ; Unrestricted execution policy; অজানা সাইটের driver) মানিনি
• Kernel-এর দাবি (IRQL, quantum, page list) Microsoft-এর ডকুমেন্টেশন বা Windows Internals বইয়ের সাথে মিলিয়েছি; commit-এর মতো হিসাব হাতে করে দেখেছি
• পরিবর্তনের আগে আর পরে একই টুলে মেপে তুলনা করেছি — শুধু “এখন দ্রুত লাগছে” দেখে নয়, একই কাজের চাপ দিয়ে