Windows NT vs. Unix: डिज़ाइन तुलना

 (blogsystem5.substack.com)
20 पॉइंट द्वारा GN⁺ 2024-09-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • NT को अक्सर एक "बहुत उन्नत" operating system माना जाता था, लेकिन इसके कारण अच्छी तरह समझ में नहीं आते थे
    • 2023 के अंत में, 'Inside Windows NT' का पहला संस्करण पढ़ने के बाद NT और Unix की तुलना करने का फैसला किया गया
    • यह NT (जुलाई 1993) और उस समय के Unix सिस्टमों (4.4BSD, Linux 1.0) के डिज़ाइन की तुलना है
    • Unix विशेषज्ञ होने के कारण NT के बारे में जानकारी सीमित है, इसलिए मुख्यतः NT के अंतर पर ध्यान दिया गया है
    • इसमें यह सवाल लिया गया है कि NT, Unix से किस मायने में बेहतर था, और क्या आज भी ऐसा है

मिशन

  • Unix का इतिहास NT से कहीं पुराना है
    • Unix का विकास 1969 में शुरू हुआ था और इसका मुख्य लक्ष्य programmers के लिए एक सुविधाजनक platform बनना था
    • Unix, Multics से प्रेरित था, लेकिन simplicity पर ध्यान देकर उसने Multics को पीछे छोड़ दिया
    • portability और multitasking, Unix डिज़ाइन के मूल लक्ष्य नहीं थे: ये क्षमताएँ कुछ साल बाद Unix के कई "forks" और पुनर्निर्माणों में जोड़ी गईं
  • Microsoft का इतिहास
    • MS-DOS का पहला release अगस्त 1981 में आया था, और "legacy Windows" (DOS-आधारित versions) का पहला release नवंबर 1985 में आया
    • MS-DOS व्यापक रूप से सफल रहा, लेकिन Windows वास्तव में महत्वपूर्ण मई 1990 में Windows 3.0 से बना
    • Windows NT की परिकल्पना 1989 में की गई और जुलाई 1993 में NT 3.1 release के साथ दुनिया के सामने आया
  • Microsoft का लाभ
    • NT का डिज़ाइन Unix से 20 साल बाद शुरू हुआ, जिससे Microsoft को बढ़त मिली
    • MS-DOS और legacy Windows की वजह से Microsoft के पास पहले से बड़ा user base था
    • NT डिज़ाइन करने वाली Microsoft टीम के पास इन विकासों से मिली समझ, दूसरे operating systems पर काम करने का अनुभव, और नई technologies तक पहुँच थी, इसलिए वे NT बनाते समय सचमुच "चाँद पर निशाना" लगा सकते थे

कर्नेल

  • Unix को, Minix या GNU Hurd जैसे कुछ अपवादों को छोड़कर, monolithic kernel के रूप में लागू किया गया, जो operating system द्वारा दी जाने वाली सुविधाओं के साथ इंटरैक्ट करने के लिए system calls का एक सेट उजागर करता है
  • दूसरी ओर NT, monolithic kernel और microkernel के बीच का एक रूप है: विशेषाधिकार प्राप्त component executive अपने आपको user-space subsystems के सामने modular components के एक समूह के रूप में प्रस्तुत करता है
  • user-space subsystems वे विशेष processes हैं जो applications द्वारा उपयोग किए जाने वाले APIs (POSIX, OS/2 आदि) को executive system calls में "अनुवाद" करते हैं
  • NT executive का एक महत्वपूर्ण हिस्सा HAL है, जो मशीन के hardware तक पहुँचने के लिए abstract primitives देता है और बाकी kernel के लिए आधार का काम करता है
    • यही layer NT को i386, Alpha और PowerPC सहित कई architectures पर चलाने की कुंजी है
    • उस समय Unix आम तौर पर किसी खास architecture से बँधा होता था: Unix की अवधारणा portable थी, लेकिन उसके implementations नहीं
    • SunOS मूल रूप से केवल Motorola 68000 को support करता था, 386BSD Intel architecture पर BSD का पहला port था, और IRIX Silicon Graphics के MIPS-आधारित workstations के लिए Unix variant था
  • NT executive का एक और महत्वपूर्ण हिस्सा multiprocessing systems और preemptive kernel के लिए support है
    • kernel में कई interrupt levels होते हैं (BSD शब्दावली में SPL) जो तय करते हैं कि क्या किसे interrupt कर सकता है, लेकिन इससे भी ज़्यादा महत्वपूर्ण यह है कि kernel thread को दूसरे kernel thread द्वारा preempt किया जा सकता है
    • आज सभी high-performance Unix systems ऐसा करते हैं, लेकिन कई Unix की शुरुआत इस तरह नहीं हुई थी
    • इन systems की शुरुआत ऐसे kernels से हुई थी जो preemption या multiprocessing को support नहीं करते थे, फिर user-space multiprocessing support जोड़ा गया, और उसके बाद kernel preemption
    • आखिरी चरण सबसे कठिन होता है, और FreeBSD 5.0 saga इस मुश्किल को अच्छी तरह दिखाती है
    • इसलिए यह दिलचस्प है कि NT ने शुरुआत से ही सही नींव पर काम शुरू किया

ऑब्जेक्ट्स

  • NT एक object-oriented kernel है
    • कोई यह सोच सकता है कि Unix भी ऐसा ही है: processes को struct से परिभाषित किया जाता है और file system implementations vnode ("virtual node", इसे inode से भ्रमित न करें) को संभालती हैं
    • लेकिन यह ठीक वैसा नहीं है जैसा NT करता है: NT यह अनिवार्य करता है कि ये सभी अलग-अलग objects सिस्टम में एक समान representation रखें
  • यह सवाल उठ सकता है कि process और file handle जैसी भिन्न चीज़ों के लिए अर्थपूर्ण abstraction कैसे दिया जा सकता है
  • व्यवहार में यह संभव नहीं है, लेकिन NT यह ज़रूर अनिवार्य करता है कि ये सभी एक common object type से inherit करें, और आश्चर्यजनक रूप से इससे कुछ अच्छे गुण मिलते हैं
  • केंद्रीकृत access control
    • objects केवल object manager द्वारा बनाए जाते हैं, इसलिए policy लागू करने वाले code के लिए एक ही केंद्रीय स्थान होता है
    • permission checks जैसी semantics केवल एक जगह पर परिभाषित की जा सकती हैं और पूरे सिस्टम में एकसमान लागू हो सकती हैं, जो काफ़ी शक्तिशाली है
    • NetBSD ने भी निष्कर्ष निकाला कि यह अच्छा विचार है, लेकिन उसे 2001 में जाकर ही Kernel Authorization (kauth) framework मिला
  • सामान्य ID
    • objects के पास ID होती है और सभी को एक ही tree में प्रस्तुत किया जाता है
    • इसका मतलब है कि process, file handle या pipe किसी भी object के लिए एक unique namespace होता है
    • tree के objects को नाम (path) से address किया जा सकता है, और tree के अलग-अलग हिस्से अलग subsystems के स्वामित्व में हो सकते हैं
    • उदाहरण के लिए tree का कोई हिस्सा mounted file system को दर्शा सकता है, इसलिए उस subtree के root node तक पहुँचने पर file system path के बाकी हिस्से को resolve करेगा
    • यह Unix systems की VFS layer जैसा है, लेकिन VFS केवल file systems तक सीमित है, जबकि object tree हर एक kernel object को कवर करता है
    • Unix ने /proc/, /sys/ आदि के ज़रिए non-file object types को file system में फिट करने की कोशिश की, लेकिन यह NT की व्यवस्था की तुलना में बाद में जोड़ी गई चीज़ जैसा लगता है
  • एकीकृत event handling
    • हर object type के पास signaled state होती है, और उसका अर्थ object type के अनुसार बदलता है
    • उदाहरण के लिए process object, process के समाप्त होने पर signaled state में चला जाता है, और file handle object, I/O request पूरी होने पर signaled state में जाता है
    • इससे user space में event-driven code (async code) लिखना बहुत आसान हो जाता है, क्योंकि एक ही wait-style system call objects के किसी समूह के state बदलने का इंतज़ार कर सकती है
    • Unix systems में I/O और process completion का एक साथ इंतज़ार करना काफ़ी मुश्किल होता है
  • objects, NT का विशिष्ट घटक हैं, और NT जिन सभी APIs को support करना चाहता है उनके लिए ये अच्छी तरह generalize नहीं होते
    • उदाहरण के लिए POSIX subsystem: POSIX में NT जैसी object अवधारणा नहीं है, लेकिन NT को POSIX applications के साथ किसी न किसी स्तर की compatibility देनी होती है
    • इसी कारण, POSIX subsystem को executive में objects allocate करते समय उन POSIX entities को दर्शाने के लिए अपनी अलग bookkeeping रखनी पड़ती है और दोनों entities के बीच तुरंत logical conversion करना पड़ता है
    • दूसरी ओर Win32 subsystem बिना किसी मध्यस्थ के clients को objects दे देता है

प्रोसेस

  • प्रोसेस NT और Unix, दोनों में एक सामान्य ऑब्जेक्ट है, लेकिन यह पूरी तरह एक जैसा नहीं है
    • Unix में प्रोसेस को एक tree के रूप में दर्शाया जाता है, जहाँ हर प्रोसेस का एक parent होता है और उसके 0 या अधिक child हो सकते हैं
    • लेकिन NT में ऐसा संबंध नहीं होता: प्रोसेस अपने creator से resource "inherit" कर सकता है, लेकिन बन जाने के बाद वह एक स्वतंत्र entity होता है
  • जब NT डिज़ाइन किया गया था, तब thread आम नहीं थे:
    • Mach 1985 में thread को एकीकृत करने वाला पहला Unix-सदृश kernel था
    • इसका मतलब यह था कि दूसरे Unix ने इस concept को बाद में अपनाया और उसे अपने मौजूदा डिज़ाइन के अनुरूप ढालना पड़ा
    • Linux ने जून 1996 की 2.0 release में thread को अलग-अलग unique PID वाले process के रूप में दर्शाने का विकल्प चुना, और NetBSD को 2004 की 2.0 release तक process से अलग entity के रूप में दर्शाए जाने वाले thread नहीं मिले
    • Unix के विपरीत, NT ने शुरू से thread support देने का विकल्प चुना क्योंकि उसे पता था कि SMP machine पर high-performance computing के लिए thread आवश्यक हैं
  • NT में पारंपरिक Unix अर्थों में signal नहीं हैं
    • इसकी जगह alerts हैं, जो kernel mode और user mode दोनों हो सकते हैं
    • user mode alerts का इंतज़ार अन्य object की तरह करना पड़ता है, और kernel mode alerts process को दिखाई नहीं देते
    • POSIX subsystem kernel mode alerts का उपयोग करके signal को emulate करता है
    • Unix में signal को अक्सर एक खामी माना गया, क्योंकि वे process execution में दखल देते हैं: signal को सही ढंग से handle करना वास्तव में कठिन काम है, इसलिए NT का विकल्प अधिक सुरुचिपूर्ण लगता है
  • NT में हाल का एक रोचक विकास Pico Process का परिचय था
    • यह सुविधा जुड़ने तक NT के process काफ़ी भारी थे: एक नए process को startup पर उसके address space में mapped NT runtime libraries का एक bundle मिलता था
    • Pico Process में process का Windows architecture से न्यूनतम संबंध होता है, और इसका उपयोग WSL 1 में Linux-compatible process लागू करने के लिए किया गया
    • कुछ मायनों में Pico Process मूल Windows process की तुलना में Unix process के ज़्यादा करीब है, लेकिन WSL 2 में स्थानांतरण के कारण, अगस्त 2016 से मौजूद होने के बावजूद अब इसका ज़्यादा उपयोग नहीं होता
  • Windows की security समस्याओं की जितनी भी आलोचना की जाए, NT ने शुरुआत से उन्नत security design अपनाया था, क्योंकि system मूल रूप से capability-based system की तरह काम करता है
    • logon के बाद शुरू होने वाली पहली user process को kernel से एक access token मिलता है, जो user session के privileges का प्रतिनिधित्व करता है, और process तथा उसके child process को privileges जताने के लिए यह token kernel को देना पड़ता है
    • यह Unix से अलग है, जहाँ process के पास केवल एक identifier होता है और kernel को process table में यह ट्रैक करना पड़ता है कि हर process क्या कर सकता है

संगतता

  • NT का एक मुख्य लक्ष्य legacy Windows, DOS, OS/2 और POSIX के लिए लिखे गए application के साथ compatible होना था
    • इसका एक कारण तकनीकी था, क्योंकि इससे system को एक सुरुचिपूर्ण design अपनाने के लिए मजबूर होना पड़ा
    • दूसरा कारण राजनीतिक था: NT का विकास IBM के साथ मिलकर हुआ था, और भले ही NT अंततः Windows बन गया, उसे OS/2 application को ज़रूर support करना था
  • इस compatibility की आवश्यकता के कारण NT का design Unix से काफ़ी अलग हो गया
    • Unix में user-space application system call interface के ज़रिए सीधे kernel से communicate करते हैं, और यही interface Unix interface है
    • C library kernel को call करने के लिए glue प्रदान करती है, और application सीधे system call execute नहीं करते, लेकिन यह एक मामूली विवरण है
  • NT में application सीधे executive (kernel) से communicate नहीं करते
    • इसके बजाय, हर application किसी विशेष protected subsystem से communicate करता है, और ये subsystem उन अलग-अलग operating system के API लागू करते हैं जिनके साथ NT compatible होना चाहता है
    • ये subsystem user-space server के रूप में implement किए जाते हैं (NT "microkernel" के अंदर नहीं)
    • Windows application के लिए support Win32 server देता है, और यह इसलिए विशेष है क्योंकि यही एकमात्र server है जिसे user सीधे देख सकता है: यह console program और DOS terminal को नियंत्रित करता है तथा performance कारणों से कुछ विशेष privileges रखता है
  • पारंपरिक Unix की तुलना में BSD और Linux में monolithic kernel होते हैं, इसलिए NT का design बहुत अलग है
    • ऐसे kernel एक system call interface expose करते हैं, जिसका उपयोग user-space application system के साथ सीधे interact करने के लिए करते हैं
    • लेकिन BSD लंबे समय से monolithic kernel के भीतर वैकल्पिक binary execution का समर्थन करता आया है: यह चल रहे binary के आधार पर user space को अलग system call table expose करता है, और फिर उन "external" system call को kernel की समझ में आने वाले call में translate करता है
    • Linux personalities के माध्यम से इसका सीमित support भी देता है
  • BSD का approach, दूसरे system को support करने के NT के तरीके से काफ़ी अलग है, लेकिन WSL 1 बहुत समान है और मूल परिभाषा के अनुसार subsystem नहीं है
    • WSL 1 में NT kernel Linux process को Pico Process के रूप में चिह्नित करता है और वहाँ से एक अलग system call interface expose करता है
    • NT kernel के भीतर, Linux-संबंधित उन system call को NT operation में translate किया जाता है, और BSD की Linux compatibility की तरह वे उसी kernel के भीतर उपलब्ध कराए जाते हैं
    • एकमात्र समस्या यह है कि NT, Unix नहीं है, इसलिए Linux "emulation" जटिल है और BSD जो दे सकता है उससे बहुत धीमी है
    • यह अफ़सोस की बात है कि WSL 2 इस design के सार को खोकर पूर्ण VM design की ओर चला गया
  • NT design का एक दिलचस्प विवरण
    • NT design का लक्ष्य एक ही shell के भीतर subsystem के बीच निर्बाध I/O redirection की अनुमति देना था
    • subsystem application के सामने port के माध्यम से expose किए जाते हैं, जो NT object हैं, और यह Mach में process और server के communicate करने के तरीके जैसा है

वर्चुअल मेमोरी

  • NT, Unix की तरह, process के बीच protection देने और virtual memory उपलब्ध कराने के लिए paging वाली Memory Management Unit(MMU) पर निर्भर करता है
    • user-space process की paging एक सामान्य mechanism है, जो machine की physical memory की मात्रा से बड़ा address space उपलब्ध कराती है
    • लेकिन एक चीज़ जिसने NT को उस समय के Unix system से आगे रखा, वह यह थी कि kernel स्वयं भी disk पर page out किया जा सकता था
    • अगर पूरा kernel pageable हो, तो ऐसी स्थिति आ सकती है जहाँ page out किए गए file system driver के code की ज़रूरत वाले kernel page fault को resolve करना पड़े, लेकिन kernel का काफ़ी बड़ा हिस्सा pageable है
    • आज यह विशेष रूप से रोचक नहीं लगता, क्योंकि machine में स्थापित सामान्य memory की तुलना में kernel छोटा होता है, लेकिन पहले हर byte की क़ीमत थी, इसलिए इससे बड़ा फ़र्क पड़ता था
  • आज हम virtual memory और paging के काम करने के तरीके को स्वाभाविक मान लेते हैं, लेकिन जब NT डिज़ाइन किया गया था तब यह बड़ा शोध क्षेत्र था
    • पहले के Unix implementation में file system और virtual memory के लिए अलग memory cache थे, और SunOS ने पुराने design के overhead को कम करने के लिए unified virtual memory architecture 1987 में लागू किया
    • इसके विपरीत, NT ने शुरुआत से unified memory architecture अपनाया
    • यह कहा जा सकता है कि Unix में पाई गई inefficiency की समझ पहले से मौजूद थी, और NT design शुरू होने से पहले SunOS द्वारा implement किए गए solution को देखा जा चुका था, इसलिए यह करना आसान था
    • फिर भी, इसने NT को उस समय के कई अन्य operating system की तुलना में "अधिक उन्नत" बना दिया, और यह ध्यान देने योग्य है कि अन्य system 2002 में NetBSD 1.6 की Unified Buffer Cache(UBC) implementation तक इसकी बराबरी नहीं कर पाए
  • NT और Unix के बीच एक दिलचस्प अंतर shared memory को manage और represent करने के तरीके में है
    • NT में shared memory section object होते हैं, इसलिए उन पर वही access validation लागू होती है जो सभी अन्य object पर होती है
    • वे एकल object tree का हिस्सा भी होते हैं, इसलिए उन्हें सभी अन्य object की तरह ही address किया जा सकता है
    • Unix में यह सुविधा बाद में जोड़ी गई लगती है: shared memory object का अलग namespace होता है, अन्य सभी entity से अलग API होती है, इसलिए सामान्य permissions लागू नहीं होतीं

I/O subsystem

  • Unix के शुरुआती versions केवल एक file system को support करते थे
    • उदाहरण के लिए, BSD को UFS से आगे support देने के लिए Virtual File System(VFS) abstraction 1990 के 4.3BSD तक जाकर मिला
    • इसके विपरीत, NT की शुरुआत ही कई file systems को अनुमति देने वाले design के साथ हुई थी
  • कई file systems को support करने के लिए kernel को किसी न किसी तरीके से उस namespace को expose करना पड़ता है
    • Unix mount points के ज़रिए एक single file hierarchy में file systems को जोड़ता है: VFS layer file system के root से मेल खाने वाले node की पहचान करने और path को traverse करते समय request को संबंधित file system driver की ओर redirect करने का mechanism देती है
    • NT में भी मिलता-जुलता design है, भले ही standard user interface में file systems अलग-अलग drives के रूप में दिखते हों: internally executive file systems को object tree के objects के रूप में represent करता है और हर object path के बाकी हिस्से को parse करने के लिए ज़िम्मेदार होता है
    • उन file system objects को user space से access योग्य बनाने के लिए फिर से DOS drives में remap किया जाता है
    • DOS drives भी एक अलग subtree के नीचे मौजूद objects हैं, जो जिस file system को refer करते हैं उसी की ओर I/O को redirect करते हैं
  • NT आखिरकार NTFS के साथ release हुआ
    • NTFS को खराब performance के लिए आलोचना झेलनी पसंद हो सकती है (यह गलत दावा है), लेकिन उस समय के हिसाब से यह वास्तव में एक उन्नत file system था
    • NT का I/O subsystem, NTFS के साथ मिलकर, 64-bit addressing, journaling, और यहाँ तक कि Unicode file names भी देता था
    • Linux को 1990 के दशक के आखिर तक 64-bit file support नहीं मिला था, और 2001 में ext3 के आने तक journaling भी नहीं मिली थी
    • वैकल्पिक fault-tolerance mechanism, Soft updates, 1998 तक FreeBSD में दिखाई नहीं दिया था
    • Unix file names को Unicode के बजाय null-terminated byte arrays के रूप में represent करता है
  • NT release के समय शामिल अन्य features में disk striping और mirroring (आज जिसे RAID कहा जाता है) और device hot-plugging शामिल थे
    • SunOS ने 1990 के शुरुआती वर्षों से RAID support शामिल किया था, इसलिए ये features नए नहीं थे, लेकिन दिलचस्प बात यह है कि इन सबको मूल design के हिस्से के रूप में सोचा गया था
    • ऊँचे स्तर पर, NT के I/O subsystem को Unix से कहीं अधिक उन्नत बनाने वाली बात यह है कि उसका interface मूल रूप से asynchronous है, और शुरू से ऐसा ही था
    • इसे संदर्भ में रखने के लिए, FreeBSD में aio(7) support 1998 के FreeBSD 3.0 तक नहीं आया था, और Linux में यह 2002 के Linux 2.5 तक नहीं आया
    • Unix systems में asynchronous I/O के लिए support 20 साल से अधिक समय से मौजूद होने के बावजूद आज भी इसका व्यापक उपयोग नहीं है: बहुत कम लोग इन APIs को जानते हैं, अधिकांश applications इनका उपयोग नहीं करते, और performance भी अच्छी नहीं है
    • Linux का io_uring asynchronous I/O को बेहतर बनाने के लिए अपेक्षाकृत हाल का addition है, लेकिन यह security vulnerabilities का एक बड़ा कारण रहा है और इसका भी व्यापक उपयोग नहीं है

नेटवर्किंग

  • आज इंटरनेट हर जगह है, लेकिन जब NT design किया जा रहा था तब ऐसा नहीं था
    • Microsoft ecosystem को देखें तो DOS 3.1 (1987) में FAT file system पर file sharing के लिए आधार शामिल था, लेकिन "OS" खुद networking features नहीं देता था: यह काम Microsoft Networks(MS-NET) नाम का अलग product करता था
    • Windows 3.0 (1990) में NetBIOS support शामिल था, जो local network पर basic printer और file sharing की अनुमति देता था, लेकिन TCP/IP support कहीं नहीं दिखता था
  • इसके विपरीत, Unix खुद इंटरनेट था: सभी बुनियादी internet protocols Unix पर और Unix के साथ लिखे गए थे
    • NT के design के दौरान बेहतर network support पर विचार करना महत्वपूर्ण था, और वास्तव में NT networking capabilities के साथ ही release हुआ
    • नतीजतन, NT ने internet protocols और पारंपरिक LAN protocols, जो मौजूदा Microsoft environment में इस्तेमाल होते थे, दोनों को support किया, और इससे enterprise environments में NT को Unix पर बढ़त मिली
  • उदाहरण के लिए, NT के network domain को देखें
    • Unix में network administrators आमतौर पर अलग-अलग machines के बीच user accounts को manually synchronize करते थे
    • SunOS जैसे systems द्वारा implement किए गए X.500 directory protocol (1988) और user authentication के लिए Kerberos (1980s) का उपयोग किया जा सकता था, लेकिन ये technologies खास तौर पर सरल नहीं थीं
    • इसके बजाय, NT ने शुरुआत से ही domains दिए, जिनमें directory और authentication capabilities integrated थीं, और लगता है कि company networks में यह इसलिए "जीत" गया क्योंकि इसे setup करना कहीं आसान था और यह system में built-in था
  • synchronized user accounts का लक्ष्य machines के बीच resources, मुख्य रूप से files, share करना है, और ऐसा करते समय permissions को represent करने का तरीका महत्वपूर्ण होता है
    • लंबे समय तक Unix हर file के लिए केवल read/write/execute permissions का एक साधारण set देता था
    • इसके विपरीत, NT शुरुआत से ही advanced ACLs के साथ आया, जो आज भी Unix के लिए एक pain point है
    • Linux और BSD में अब ACLs हैं, लेकिन systems के बीच interface consistent नहीं हैं और वे system design में किसी बाहरी add-on जैसे लगते हैं
    • NT में ACLs object level पर काम करते हैं, इसलिए वे सभी kernel features पर एकसमान तरीके से लागू होते हैं
  • file sharing की बात करें तो network file systems की बात करनी ही होगी
    • Unix में de facto file system NFS था और NT में SMB
    • SMB, MS-NET और LAN Manager से inherited था, और इसे kernel में redirector नाम के component के माध्यम से implement किया गया था
    • मूल रूप से, redirector एक "सरल" दूसरा file system है, जो ठीक वैसे ही file operations को trap करके network पर भेजता है जैसे Unix में NFS करता है
  • protobuf और gRPC आज व्यापक रूप से इस्तेमाल होते हैं, इसलिए वे नए ideas जैसे लग सकते हैं, लेकिन वे पुराने विचारों पर आधारित हैं
    • Unix में, मुख्यतः NFS को support करने के लिए, 1980 के शुरुआती वर्षों से Sun RPC का उपयोग किया जाता था
    • इसी तरह, NT built-in RPC support के साथ आया, अपनी खुद की DSL के ज़रिए (interface definitions specify करने और remote procedures के लिए code generate करने हेतु, जिसे MIDL के नाम से जाना जाता है) और RPC clients तथा servers implement करने की अपनी capabilities के साथ
  • Unix systems arbitrary driver support पर ज़्यादा केंद्रित नहीं थे: Unix systems आमतौर पर specific machines और vendors से बंधे होते थे
    • इसके विपरीत, NT "हर" machine के लिए OS बनना चाहता था, और चूँकि इसे एक software company बेचती थी, इसलिए दूसरे लोगों द्वारा लिखे गए drivers का support महत्वपूर्ण था
    • नतीजतन, NT में Network Driver Interface Specification(NDIS) दिया गया, जो network card drivers को आसानी से support करने के लिए एक abstraction है
    • आज तक भी manufacturers द्वारा दिए गए drivers Linux में उतने आम नहीं हैं, और इसी वजह से 2000 के शुरुआती वर्षों में Linux पर WiFi cards के लिए Windows drivers को reuse करने वाला बेहद लोकप्रिय workaround ndiswrapper जैसी दिलचस्प चीज़ सामने आई
  • अंत में, NT और Unix के बीच एक और अंतर named pipes के implementation में है
    • Unix में named pipes local component हैं: वे एक ही machine पर चल रहे दो processes को disk पर persistent file name के ज़रिए एक-दूसरे से communicate करने का mechanism देते हैं
    • NT में भी यही feature है, लेकिन named pipes network पर भी काम कर सकते हैं
    • shared file system पर named pipes रखने से अलग-अलग computers के दो applications networking details की चिंता किए बिना एक-दूसरे से communicate कर सकते हैं

User-Space

  • Configuration:
    • NT ने registry नाम के database में system और application configuration को centralize किया, जिससे legacy Windows में इस्तेमाल होने वाले पुराने CONFIG.SYS, AUTOEXEC.BAT और अनेक INI files से छुटकारा मिला
    • इससे कुछ लोग बहुत नाराज़ हुए, लेकिन अंततः unified configuration interface सभी के लिए फायदेमंद रहा: application लिखना आसान हो जाता है क्योंकि support के लिए एक ही आधार होता है, और users के लिए system को tweak करना आसान होता है क्योंकि देखने के लिए एक ही जगह होती है
    • दूसरी ओर, Unix अब भी दर्जनों DSLs और असंगत file locations के कारण जूझ रहा है
    • configuration files को support करने वाले हर program का अपना syntax होता है, और program किस location से पढ़ता है यह जानना मुश्किल होता है और हमेशा अच्छी तरह document भी नहीं किया जाता
    • Linux ecosystem ने XDG और dconf (पहले GConf) के माध्यम से NT जैसी approach को आगे बढ़ाया, लेकिन desktop components इन technologies का exclusive उपयोग करते हैं जबकि system के मूल components ने इन्हें अपनाया नहीं, जिससे एक असंगत अव्यवस्था बनी रहती है
  • Internationalization:
    • Microsoft, जो पहले से दुनिया भर में Windows 3.x जारी कर रही एक बड़ी company थी, समझती थी कि localization महत्वपूर्ण है, इसलिए उसने NT को शुरू से ही इन सुविधाओं का support देने के लिए बनाया
    • इसकी तुलना Unix से की जा सकती है, जहाँ UTF support 1990 के दशक के उत्तरार्ध तक दिखना शुरू नहीं हुआ था और दूसरी भाषाओं का support optional gettext add-on के ज़रिए दिया गया
  • C भाषा:
    • FreeBSD और NetBSD जैसे Unix systems लंबे समय से एक ऐसी चीज़ का सपना देखते रहे हैं जिसमें kernel को अधिक सुरक्षित तरीके से implement करने के लिए अपनी खुद की C dialect बनाई जाए
    • Linux को छोड़कर, जो GCC-specific extensions पर निर्भर करता है, यह कहीं नहीं पहुँचा
    • दूसरी ओर, Microsoft के पास अपना C compiler होने का विशेष लाभ था, इसलिए उसने Microsoft C में लिखे गए NT पर यह किया
    • उदाहरण के लिए, NT Structured Exception Handling(SEH) पर निर्भर करता है, जो software और hardware exceptions को handle करने के लिए try/except clauses जोड़ने की सुविधा है
    • मैं यह नहीं कहूँगा कि यह कोई बड़ा लाभ है, लेकिन यह वास्तव में एक अंतर है

निष्कर्ष

  • NT अपने release के समय groundbreaking technology था
  • जैसा कि ऊपर बताया गया है, आज system design में जिन कई सुविधाओं को हम स्वाभाविक मानते हैं वे NT में शुरुआत से मौजूद थीं, जबकि लगभग सभी अन्य Unix systems को समय के साथ ऐसी सुविधाएँ धीरे-धीरे हासिल करनी पड़ीं
  • नतीजतन, ये सुविधाएँ हमेशा Unix philosophy के साथ सहज रूप से integrate नहीं होतीं
  • हालांकि, आज यह स्पष्ट नहीं है कि NT सच में Linux या FreeBSD से "ज़्यादा advanced" है या नहीं
    • NT के पास शुरुआत से ही अधिक ठोस design principles और अपने समकालीन operating systems की तुलना में अधिक features थे, लेकिन आजकल यह अंतर धुंधला हो गया है
    • यानी, NT ने प्रगति की, लेकिन वह modern Unix की तुलना में इतना अधिक advanced नहीं रह गया
  • यह निराशाजनक है कि NT में ये सभी मज़बूत design principles होने के बावजूद UI bloat के कारण उसका design पूरी तरह चमक नहीं पाता
    • बेहद शक्तिशाली machines पर भी OS की धीमी गति देखना पीड़ादायक हो सकता है, और यह इस OS के अंत का कारण भी बन सकता है

GN⁺ की संक्षिप्त प्रस्तुति

  • यह लेख NT और Unix के design differences की तुलना करके बताता है कि NT का शुरुआती design कितना प्रगतिशील था
  • NT को शुरुआत से portability, multiprocessing support, और compatibility को लक्ष्य बनाकर design किया गया था, और यही Unix से उसका प्रमुख अंतर है
  • NT का object-oriented kernel, unified memory architecture, और asynchronous I/O interface, Unix की तुलना में अधिक advanced features प्रदान करते हैं
  • हालांकि, आज NT और Unix systems के बीच का अंतर बड़ा नहीं है, और NT का भारी-भरकम UI performance degradation का कारण बनता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-10
Hacker News राय

  • NT kernel बेहतरीन है, लेकिन इसका डिज़ाइन पुराना है

    • Windows OS में NT kernel के ऊपर कई पुराने elements चढ़े हुए हैं, जिससे समस्याएँ पैदा होती हैं
    • Microsoft को Win32 और MS-DOS paradigm से बाहर निकलकर NT-आधारित नए OS डिज़ाइन पर विचार करना चाहिए

  • NT और Unix के बीच सबसे बड़ा अंतर driver approach का है

    • NT को Windows 3.x/95/98 की driver समस्याओं को हल करने के लिए डिज़ाइन किया गया था
    • Unix drivers को high-reliability components मानता है और उन्हें kernel developers लिखते हैं

  • आधुनिक WinNT में Direct3D kernel का एक आवश्यक हिस्सा है

    • D3D11 को GPU के बिना भी इस्तेमाल किया जा सकता है, और यह WARP नाम का software fallback देता है
    • Linux में इसके जैसा फीचर नहीं है

  • NT kernel process नहीं बल्कि thread चलाता है

    • thread कुछ milliseconds में बनाए जा सकते हैं, जबकि process भारी तरीके से काम करता है
    • NT का इतिहास VMS के मूल सिद्धांतों में जड़ें रखता है

  • शुरुआती दौर में WindowsNT, Linux की तुलना में कहीं बेहतर डिज़ाइन किया गया system था

    • NT Win32, OS/2, और POSIX चला सकता था
    • POSIX को अमेरिकी सरकार के बड़े software contracts के लिए जोड़ा गया था, लेकिन बाद में उसमें रुचि खत्म हो गई

  • तीसरे system के रूप में NT ने second-system syndrome से बचाव किया

    • OS/2 ने तकनीकी रूप से गलत समस्याओं को हल किया, और संगठनात्मक रूप से भी विफल रहा
    • NT का व्यापक उपयोग Windows XP तक नहीं हुआ

  • developer के नज़रिए से Windows और Linux में अंतर है

    • command line और globbing के मामले में Windows बेहतर है
    • Win32 में wchar_t का उपयोग एक समस्या है

  • NT kernel में elegance है, लेकिन यह open source नहीं है

    • अलग user space और desktop environment वाला Windows दिलचस्प होगा

  • Linux में FUSE जैसी convergence थी

    • Win NT का file system approach कई file system operations को बहुत धीमा बना देता है
    • Microsoft ने WSL1 को छोड़ दिया, और SQLLite या ZIP file जैसे containers का उपयोग किया