- NT, sık sık "çok ileri" bir işletim sistemi olarak değerlendiriliyordu, ancak bunun nedenini pek bilmiyordum
- 2023'ün sonlarında,
Inside Windows NT 1. baskısını okuyup NT ile Unix'i karşılaştırmaya karar verdim
- Bu, NT'nin (Temmuz 1993) tasarımını o dönemin Unix sistemleriyle (4.4BSD, Linux 1.0) karşılaştırıyor
- Bir Unix uzmanı olarak NT'yi iyi bilmediğim için, anlatım daha çok NT'nin farklılıklarına odaklanıyor
- NT'nin Unix'ten hangi yönlerde daha iyi olduğu ve bunun hâlâ geçerli olup olmadığı sorularını ele alıyor
Misyon
- Unix'in tarihi, NT'den çok daha eski
- Unix geliştirmesi 1969'da başladı ve temel hedefi programcılar için kullanışlı bir platform olmaktı
- Unix, Multics'ten ilham aldı ancak sadeliğe odaklanarak Multics'i geride bıraktı
- Taşınabilirlik ve çoklu görev, Unix tasarımının baştaki hedefleri değildi: bu özellikler birkaç yıl sonra Unix'in birçok "fork"unda ve yeniden icadında eklendi
- Microsoft'un tarihi
- MS-DOS'un ilk sürümü Ağustos 1981'de yayımlandı ve "eski Windows"un (DOS tabanlı sürümler) ilk sürümü Kasım 1985'te çıktı
- MS-DOS geniş çapta başarılı oldu, ancak Windows'un gerçekten önemli hâle gelmesi Mayıs 1990'daki Windows 3.0 ile oldu
- Windows NT 1989'da tasarlandı ve Temmuz 1993'teki NT 3.1 sürümüyle dünyaya tanıtıldı
- Microsoft'un avantajı
- NT'nin tasarımı Unix'ten 20 yıl sonra başladığı için Microsoft'a avantaj sağladı
- Microsoft, MS-DOS ve eski Windows sayesinde zaten büyük bir kullanıcı tabanına sahipti
- NT'yi tasarlayan Microsoft ekibi, bu geliştirmelerden gelen içgörülere, başka işletim sistemleri geliştirme deneyimine ve modern teknolojiye erişime sahipti; bu da NT'yi yaparken "aya nişan alma" imkânı verdi
Çekirdek
- Unix, Minix ve GNU Hurd gibi birkaç istisna dışında, işletim sisteminin sunduğu işlevlerle etkileşim kurmak için bir sistem çağrıları kümesi açığa çıkaran monolitik bir çekirdek olarak uygulanır
- Buna karşılık NT, monolitik çekirdek ile mikroçekirdek arasında bir formdur: ayrıcalıklı executive bileşeni kendisini kullanıcı alanındaki subsystems'lere modüler bileşenler topluluğu olarak sunar
- Kullanıcı alanı subsystems, uygulamaların kullandığı API'leri (POSIX, OS/2 vb.) executive sistem çağrılarına "çeviren" özel süreçlerdir
- NT executive'in önemli parçalarından biri HAL'dir; makinenin donanımına erişmek için soyut temel öğeler sağlar ve çekirdeğin geri kalanı için temel görevi görür
- Bu katman, NT'nin i386, Alpha ve PowerPC dâhil çeşitli mimarilerde çalışabilmesinin anahtarıdır
- O dönemde Unix belirli mimarilere bağlıydı: Unix kavramı taşınabilirdi ama uygulamaları öyle değildi
- SunOS başlangıçta yalnızca Motorola 68000'i destekliyordu, 386BSD BSD'nin Intel mimarisine ilk portuydu ve IRIX, Silicon Graphics'in MIPS tabanlı iş istasyonları için bir Unix türeviydi
- NT executive'in bir diğer önemli parçası, çoklu işlemcili sistemler ve preemptive çekirdek desteğidir
- Çekirdekte, neyin başka bir şeyi kesebileceğini belirlemek için çeşitli kesme seviyeleri vardır (BSD terminolojisinde SPL), ama daha da önemlisi çekirdek thread'lerinin başka çekirdek thread'leri tarafından kesilebilmesidir
- Bu, bugün tüm yüksek performanslı Unix sistemlerinin yaptığı şeydir, ancak birçok Unix'in başlangıçta çalışma şekli bu değildi
- Bu sistemler, preemption veya çoklu işlem desteği olmayan çekirdeklerle başlayıp önce kullanıcı alanında çoklu işlem desteği ekledi, ardından çekirdek preemption'ını ekledi
- Son adım en zor olanıdır ve FreeBSD 5.0 destanı bu zorluğu açıklar
- Bu nedenle NT'nin en baştan doğru temellerle başlamış olması ilginçtir
Nesneler
- NT, nesne yönelimli bir çekirdektir
- Unix'in de öyle olduğu düşünülebilir: süreçler
struct ile tanımlanır ve dosya sistemi uygulamaları vnode ("sanal düğüm", inode ile karıştırılmamalı) ile çalışır
- Ancak bu, NT'nin yaptığıyla tam olarak aynı şey değildir: NT, tüm bu farklı nesnelerin sistemde ortak bir temsile sahip olmasını zorunlu kılar
- Süreçler ve dosya handle'ları gibi heterojen şeyler için anlamlı bir soyutlama nasıl sağlanabileceği sorgulanabilir
- Aslında bu mümkün değildir, ancak NT bunların hepsinin ortak bir nesne türünden türemesini zorunlu kıldı ve şaşırtıcı biçimde bunun bazı iyi özellikleri vardır
- Merkezi erişim kontrolü
- Nesneler yalnızca object manager tarafından oluşturulduğu için, politika uygulayan kod için tek bir yer vardır
- İzin kontrolü gibi anlamlar yalnızca tek bir yerde tanımlanıp tüm sisteme tutarlı biçimde uygulanabildiğinden bu güçlü bir yaklaşımdır
- NetBSD de bunun iyi bir fikir olduğu sonucuna vardı, ancak ancak 2001'de Kernel Authorization (
kauth) çatısını edindi
- Ortak kimlik
- Nesnelerin bir kimliği vardır ve hepsi tek bir ağaç içinde temsil edilir
- Bu, süreç, dosya handle'ı veya pipe fark etmeksizin tüm nesneler için benzersiz bir ad alanı olduğu anlamına gelir
- Ağaçtaki nesneler adla (yol) adreslenebilir ve ağacın farklı bölümleri farklı alt sistemlere ait olabilir
- Örneğin ağacın bir bölümü bağlanmış bir dosya sistemini temsil edebilir; dolayısıyla bu alt ağacın kök düğümüne gidildiğinde dosya sistemi yolun geri kalanını çözer
- Bu, Unix sistemlerindeki VFS katmanına benzer, ancak VFS yalnızca dosya sistemleriyle ilgilenirken nesne ağacı her bir çekirdek nesnesi için geçerlidir
- Unix,
/proc/, /sys/ vb. üzerinden dosya olmayan nesne türlerini dosya sistemine sıkıştırmaya çalıştı, ancak bu, NT'nin sunduğuna kıyasla sonradan eklenmiş gibi hissettiriyor
- Birleşik olay işleme
- Her nesne türünün bir signaled durumu vardır ve bunun anlamı nesne türüne göre değişir
- Örneğin süreç nesnesi, süreç sonlandığında signaled durumuna geçer; dosya handle'ı nesnesi ise bir G/Ç isteği tamamlandığında signaled durumuna geçer
- Bu, tek bir wait tarzı sistem çağrısının bir grup nesnenin durum değiştirmesini bekleyebilmesi sayesinde kullanıcı alanında olay tabanlı kod (async kod) yazmayı çok kolaylaştırır
- Unix sistemlerinde G/Ç ve süreç tamamlanmasını aynı anda beklemek zahmetlidir
- Nesneler NT'ye özgü bir bileşendir ve NT'nin desteklemeyi amaçladığı tüm API'lere iyi şekilde genellenmez
- Örneğin POSIX alt sistemi: POSIX'te NT'deki gibi bir nesne kavramı yoktur, ancak NT'nin POSIX uygulamalarıyla bir tür uyumluluk sağlaması gerekir
- Bu nedenle POSIX alt sistemi, executive üzerinde nesneler tahsis ederken bu POSIX varlıklarını temsil etmek için kendi kayıt düzenini de tutmak ve iki varlık arasında anında mantıksal dönüşüm yapmak zorundadır
- Buna karşılık Win32 alt sistemi, aracı olmadan istemcilere doğrudan nesneleri verir
Süreçler
- Süreçler, NT ve Unix’in ortak nesneleridir, ancak tamamen aynı değildir
- Unix’te süreçler bir ağaç olarak ifade edilir; her sürecin bir ebeveyni vardır ve bir süreç 0 veya daha fazla çocuğa sahip olabilir
- Ancak NT’de böyle bir ilişki yoktur: süreçler oluşturucularından kaynakları "miras alabilir", fakat oluşturulduktan sonra bağımsız varlıklardır
- NT tasarlandığı dönemde thread’ler yaygın değildi:
- Mach, 1985’te thread’leri entegre eden ilk Unix benzeri çekirdekti
- Bu, diğer Unix’lerin bu kavramı daha sonra benimsemek ve mevcut tasarımlarına uyarlamak zorunda kaldığı anlamına geliyordu
- Linux, 2 Haziran 1996’daki 2.0 sürümünde thread’leri her biri kendine özgü bir PID’ye sahip süreçler olarak temsil etmeyi seçti; NetBSD ise 2004’teki 2.0 sürümüne kadar süreçlerden ayrı varlıklar olarak temsil edilen thread’lere sahip olmadı
- Unix’ten farklı olarak NT, SMP makinelerde yüksek performanslı hesaplama için thread’lerin kritik önemde olduğunu biliyordu ve en baştan thread desteği sunmayı seçti
- NT’de geleneksel Unix anlamında sinyal yoktur
- Bunun yerine alerts vardır ve bunlar çekirdek modu ya da kullanıcı modu olabilir
- Kullanıcı modu bildirimleri, diğer nesneler gibi beklenmelidir; çekirdek modu bildirimleri ise süreç tarafından görünmez
- POSIX alt sistemi, sinyalleri taklit etmek için çekirdek modu bildirimlerini kullanır
- Sinyaller, süreç yürütmesini kesintiye uğratma biçimleri nedeniyle Unix’te sık sık bir kusur olarak görülmüştür: sinyalleri doğru şekilde işlemek gerçekten zordur, bu yüzden NT’nin alternatifi daha zarif görünüyor
- NT’de yakın dönemdeki ilginç gelişmelerden biri pikosüreçlerin tanıtılmasıydı
- Bu özellik eklenene kadar NT’deki süreçler oldukça ağırdı: yeni bir süreç, başlatılırken adres alanına eşlenmiş bir NT çalışma zamanı kütüphaneleri paketi alırdı
- Pikosüreçlerde süreç, Windows mimarisiyle asgari düzeyde ilişkilidir; bu da WSL 1’de Linux uyumlu süreçleri uygulamak için kullanıldı
- Bazı açılardan pikosüreçler, yerel Windows süreçlerinden çok Unix süreçlerine daha yakındır; ancak WSL 2’ye geçiş nedeniyle, Ağustos 2016’dan beri var olmalarına rağmen artık pek kullanılmıyorlar
- Windows’un güvenlik sorunlarını ne kadar eleştirsek de NT, sistemin temelde yetenek tabanlı bir sistem gibi çalışması bakımından erken internet standartlarına göre ileri seviye bir güvenlik tasarımıyla başladı
- Oturum açıldıktan sonra başlayan ilk kullanıcı süreci, kullanıcı oturumunun yetkilerini temsil eden bir erişim belirtecini çekirdekten alır ve süreç ile alt süreçleri, yetki talep etmek için bu belirteci çekirdeğe sunmak zorundadır
- Bu, süreçlerin yalnızca bir tanımlayıcıya sahip olduğu ve çekirdeğin süreç tablosunda her sürecin ne yapabildiğini takip etmek zorunda olduğu Unix’ten farklıdır
Uyumluluk
- NT’nin başlıca hedeflerinden biri, legacy Windows, DOS, OS/2 ve POSIX için yazılmış uygulamalarla uyumlu olmaktı
- Bunun bir nedeni teknikti; çünkü bu, sistemi zarif bir tasarıma sahip olmaya zorluyordu
- Diğer neden siyasiydi; NT IBM ile birlikte geliştiriliyordu ve NT sonunda Windows’a dönüşmüş olsa da OS/2 uygulamalarını mutlaka desteklemek zorundaydı
- Bu uyumluluk ihtiyacı nedeniyle NT’nin tasarımı Unix’ten ciddi biçimde farklılaştı
- Unix’te kullanıcı alanı uygulamaları, sistem çağrısı arayüzü üzerinden doğrudan çekirdekle iletişim kurar ve bu arayüz Unix arayüzüdür
- C kütüphanesi, çekirdeği çağırmak için gerekli yapıştırıcıyı sağlar ve uygulamalar sistem çağrılarını doğrudan yürütmez, ancak bu önemsiz bir ayrıntıdır
- NT’de uygulamalar executive (çekirdek) ile doğrudan iletişim kurmaz
- Bunun yerine her uygulama, belirli bir korumalı alt sistem ile iletişim kurar; bu alt sistemler, NT’nin uyumlu olmak istediği çeşitli işletim sistemlerinin API’lerini uygular
- Bu alt sistemler kullanıcı alanı sunucuları olarak uygulanır (NT "mikroçekirdeği" içinde değildir)
- Windows uygulamalarına destek Win32 sunucusu tarafından sağlanır; bu, kullanıcının doğrudan görebildiği tek sunucu olduğu için özeldir: konsol programlarını ve DOS terminallerini yönetir ve performans nedenleriyle belirli ayrıcalıklara sahiptir
- Geleneksel Unix ile karşılaştırıldığında BSD ve Linux monolitik çekirdeklere sahip olduğundan, NT’nin tasarımı oldukça farklıdır
- Bu çekirdekler, kullanıcı alanı uygulamalarının sistemle doğrudan etkileşime girmek için kullandığı bir sistem çağrısı arayüzü sunar
- Ancak BSD, monolitik çekirdek içinde uzun süredir alternatif ikili çalıştırmayı desteklemektedir: bu, çalışan ikiliye göre kullanıcı alanına farklı sistem çağrısı tabloları sunup ardından bu "harici" sistem çağrılarını çekirdeğin anlayacağı biçime dönüştürerek çalışır
- Linux da personalities aracılığıyla buna sınırlı destek sağlar
- BSD yaklaşımı, NT’nin diğer sistemleri destekleme biçiminden çok farklı olsa da WSL 1 oldukça benzerdir ve özgün tanımlanan anlamıyla bir alt sistem değildir
- WSL 1’de NT çekirdeği Linux süreçlerini pikosüreçler olarak işaretler ve buradan farklı bir sistem çağrısı arayüzü sunar
- NT çekirdeği içinde ilgili Linux sistem çağrıları NT işlemlerine dönüştürülür; böylece tıpkı BSD’nin Linux uyumluluğunda olduğu gibi aynı çekirdek içinde sağlanır
- Tek sorun, NT Unix olmadığı için Linux "emülasyonu"nun zahmetli olması ve BSD’nin sunabileceğinden çok daha yavaş olmasıdır
- WSL 2’nin bu tasarımın özünü kaybedip tam bir VM tasarımına geçmesi üzücüdür
- NT tasarımının ilginç ayrıntıları
- NT tasarımının hedeflerinden biri, tek bir kabuk içinde alt sistemler arasında sorunsuz I/O yönlendirmesine izin vermekti
- Alt sistemler, uygulamalara portlar aracılığıyla sunulur; bunlar NT nesneleridir ve Mach’ın süreçler ile sunucuların iletişim kurma biçimine benzer
Sanal bellek
- NT, Unix gibi, süreçler arasında koruma sağlamak ve sanal bellek sunmak için sayfalama özellikli bir Memory Management Unit(MMU)’ye dayanır
- Kullanıcı alanı süreçlerinin sayfalanması, makinenin fiziksel bellek miktarından daha büyük bir adres alanı sağlamanın genel mekanizmasıdır
- Ancak NT’yi döneminin Unix sistemlerinin önüne geçiren özelliklerden biri, çekirdeğin kendisinin de diske sayfalanabilmesiydi
- Elbette çekirdeğin tamamı sayfalanabilir olsaydı, sayfalanmış bir dosya sistemi sürücüsünün kodunu gerektiren çekirdek sayfa hatalarını çözmek gibi bir durum ortaya çıkardı; yine de çekirdeğin önemli bir bölümü sayfalanabilir durumdadır
- Günümüzde çekirdekler, makinelere takılan tipik belleğe kıyasla küçük olduğundan bu özellikle ilgi çekici değil; ancak geçmişte her bayt değerliydi ve bu büyük fark yaratıyordu
- Günümüzde sanal bellek ile sayfalamanın nasıl çalıştığını doğal kabul ediyoruz, ancak NT tasarlandığında bu büyük bir araştırma alanıydı
- Daha önceki Unix uygulamalarında dosya sistemi ile sanal bellek için ayrı bellek önbellekleri vardı ve SunOS’un önceki tasarımların ek yükünü azaltmak için birleşik sanal bellek mimarisini uygulaması ancak 1987’de gerçekleşti
- Buna karşılık NT, en baştan birleşik bir bellek mimarisiyle başladı
- Unix’te görülen verimsizliklere dair içgörüler bulunduğu ve NT tasarımı başlamadan önce SunOS’un uyguladığı çözümü görmek mümkün olduğu için bunu yapmak kolaydı denebilir
- Yine de bunun NT’yi o dönemdeki pek çok işletim sisteminden "daha gelişmiş" hale getirdiğini ve diğer sistemlerin ancak NetBSD 1.6’daki Unified Buffer Cache(UBC) uygulamasıyla 2002’ye kadar yetişebildiğini not etmek gerekir
- NT ile Unix arasındaki ilginç farklardan biri, paylaşımlı belleği yönetme ve ifade etme biçimleridir
- NT’de paylaşımlı bellek bölümleri birer nesnedir; bu nedenle diğer tüm nesnelerle tamamen aynı erişim doğrulamasına tabidir
- Ayrıca tek bir nesne ağacının parçasıdırlar; dolayısıyla diğer tüm nesnelerle aynı şekilde adreslenebilirler
- Unix’te bu özellik sonradan eklenmiştir: paylaşımlı bellek nesneleri farklı bir ad alanına ve diğer tüm varlıklardan farklı bir API’ye sahiptir, bu yüzden genel izinler uygulanmaz
I/O alt sistemi
- Unix’in ilk sürümleri yalnızca tek bir dosya sistemini destekliyordu
- Örneğin BSD’nin, UFS’nin ötesini desteklemek için Virtual File System(VFS) soyutlamasını edinmesi ancak Nisan 1990’daki 4.3BSD ile mümkün oldu
- Buna karşılık NT, birden fazla dosya sistemine izin veren bir tasarımla başladı
- Birden fazla dosya sistemini desteklemek için çekirdeğin, bir şekilde ilgili ad alanını dışa açması gerekir
- Unix, bağlama noktaları aracılığıyla dosya sistemlerini tek bir dosya hiyerarşisinde birleştirir: VFS katmanı, dosya sisteminin köküne karşılık gelen düğümü tanımlayan ve yol üzerinde gezinirken istekleri ilgili dosya sistemi sürücüsüne yönlendiren bir mekanizma sağlar
- NT ise standart kullanıcı arayüzünde dosya sistemleri ayrı sürücüler olarak görünse de benzer bir tasarıma sahiptir: dahili olarak executive, dosya sistemlerini nesne ağacındaki nesneler olarak temsil eder ve her nesne yolun geri kalanını ayrıştırmaktan sorumludur
- İlgili dosya sistemi nesneleri, kullanıcı alanından erişilebilmeleri için yeniden DOS sürücülerine eşlenir
- DOS sürücüleri de, başvurdukları dosya sistemine I/O’yu yönlendiren ayrı bir alt ağacın altındaki nesnelerdir
- NT sonunda NTFS ile birlikte piyasaya çıktı
- NTFS, kötü performans gösterdiği iddiasıyla eleştirilmeyi sevse de (yanlış bir iddia), dönemine göre gerçekten gelişmiş bir dosya sistemiydi
- NT’nin I/O alt sistemi, NTFS ile birleşerek 64 bit adresleme, journaling ve hatta Unicode dosya adları sundu
- Linux, 64 bit dosya desteğini ancak 1990’ların sonlarında aldı ve journaling ancak 2001’de ext3 çıktığında geldi
- Alternatif hata toleransı mekanizması olan Soft updates, FreeBSD’de ancak 1998’de ortaya çıktı
- Unix, dosya adlarını Unicode yerine null ile sonlandırılan bayt dizileri olarak gösterir
- NT’nin çıkışıyla birlikte sunulan diğer özellikler arasında disk striping ve mirroring (bugün RAID olarak biliniyor) ile aygıt hot-plug desteği vardı
- SunOS, 1990’ların başından itibaren RAID desteği içerdiği için bu özellikler yeni değildi, ancak ilginç olan bunların hepsinin özgün tasarımın parçası olarak düşünülmüş olmasıydı
- Daha üst düzeyde, NT’nin I/O alt sistemini Unix’tekinden çok daha gelişmiş kılan şey, arayüzünün özünde asenkron olması ve en başından beri böyle tasarlanmış olmasıdır
- Bunu bağlama oturtmak gerekirse, FreeBSD aio(7) desteğini ancak 1998’de FreeBSD 3.0 ile gördü; Linux ise bunu ancak 2002’de Linux 2.5 ile gördü
- Asenkron I/O desteği 20 yıldan uzun süredir Unix sistemlerinde bulunmasına rağmen hâlâ yaygın olarak kullanılmıyor: bu API’leri bilen çok az kişi var, uygulamaların büyük çoğunluğu bunları kullanmıyor ve performansları iyi değil
- Linux’un io_uring’i, asenkron I/O’yu iyileştiren görece yeni bir eklentidir, ancak önemli bir güvenlik açığı kaynağı oldu ve yaygın biçimde kullanılmıyor
Ağ
- Bugün internet her yerde, ancak NT tasarlanırken durum böyle değildi
- Microsoft ekosistemine bakarsak, DOS 3.1 (1987) FAT dosya sisteminde dosya paylaşımı için temel içeriyordu, ancak “OS”un kendisi ağ yetenekleri sunmuyordu: bunu Microsoft Networks(MS-NET) adlı ayrı bir ürün sağlıyordu
- Windows 3.0 (1990), yerel ağda temel yazıcı ve dosya paylaşımına izin veren NetBIOS desteğini içeriyordu, ancak TCP/IP desteği yoktu
- Buna karşılık Unix adeta internetin kendisiydi: tüm temel internet protokolleri Unix üzerinde ve Unix ile birlikte yazıldı
- NT tasarlanırken güçlü ağ desteğinin düşünülmesi önemliydi ve gerçekten de NT ağ özellikleriyle birlikte piyasaya çıktı
- Sonuç olarak NT, hem internet protokollerini hem de geleneksel Microsoft ortamlarında kullanılan klasik LAN protokollerini destekledi; bu da kurumsal ortamlarda NT’yi Unix’in önüne taşıdı
- Buna örnek olarak NT’nin ağ etki alanları verilebilir
- Unix’te ağ yöneticileri genellikle kullanıcı hesaplarını makineler arasında elle senkronize ediyordu
- SunOS gibi sistemlerin uyguladığı X.500 dizin protokolü (1988) ve Kerberos (1980’ler) kullanıcı kimlik doğrulaması için kullanılabiliyordu, ancak bu teknolojiler özellikle basit değildi
- Bunun yerine NT, en baştan dizin ve kimlik doğrulama yeteneklerini bütünleştiren etki alanları sundu; bunlar çok daha kolay kurulabildiği ve sisteme gömülü olduğu için şirket ağlarında “kazanan” çözüm gibi göründü
- Senkronize kullanıcı hesaplarının amacı, makineler arasında kaynakları, başta dosyaları, paylaşmaktır; bunu yaparken izinlerin nasıl ifade edildiği önemlidir
- Unix uzun süre boyunca her dosya için yalnızca basit bir okuma/yazma/çalıştırma izin kümesi sundu
- Buna karşılık NT, baştan itibaren gelişmiş ACL’lerle geldi; bu konu hâlâ Unix’te sancılı bir alan
- Linux ve BSD’de artık ACL’ler var, ancak sistemler arasındaki arayüzler tutarlı değil ve sistem tasarımına sonradan eklenmiş yabancı bir özellik gibi hissettiriyor
- NT’de ACL’ler nesne düzeyinde çalışır, bu yüzden tüm çekirdek işlevlerine tutarlı biçimde uygulanır
- Dosya paylaşımından söz ederken ağ dosya sistemlerinden de söz etmek gerekir
- Unix’te fiilî dosya sistemi NFS iken NT’de SMB idi
- SMB, MS-NET ve LAN Manager’dan miras alındı ve redirector adlı bir bileşen aracılığıyla çekirdekte uygulandı
- Özünde redirector, tıpkı NFS’nin Unix’te olduğu gibi, dosya işlemlerini yakalayıp ağ üzerinden ileten “basit” bir başka dosya sistemidir
- protobuf ve gRPC yaygın kullanıldığı için yeni fikirler gibi görünebilir, ancak eski fikirlere dayanırlar
- Unix’te, esas olarak NFS’yi desteklemek için 1980’lerin başından beri Sun RPC kullanılıyordu
- Benzer şekilde NT, kendi DSL’siyle (arayüz tanımlarını belirtmek ve uzak yordamlar için kod üretmek amacıyla MIDL olarak bilinir) ve RPC istemci ile sunucularını uygulamaya yönelik kendi yetenekleriyle yerleşik RPC desteği sundu
- Unix sistemleri keyfi sürücü desteğine çok fazla odaklanmıyordu: Unix sistemleri genellikle belirli makineler ve üreticilerle sıkı biçimde bağlantılıydı
- Buna karşılık NT, “her” makine için bir OS olmaya çalışıyordu ve bir yazılım şirketi tarafından satılıyordu; bu nedenle başkaları tarafından yazılan sürücülere destek önemliydi
- Sonuç olarak NT, ağ kartı sürücülerini kolayca desteklemek için bir soyutlama olan Network Driver Interface Specification(NDIS) ile geldi
- Bugün bile üretici tarafından sağlanan sürücüler Linux’ta çok yaygın değildir; bunun sonucu olarak 2000’lerin başında Linux’ta WiFi kartları için Windows sürücülerinin yeniden kullanılmasını sağlayan ve oldukça popüler olan ndiswrapper gibi ilginç çözümler ortaya çıktı
- Son olarak, NT ile Unix arasındaki bir diğer fark adlandırılmış pipe’ların uygulanışındadır
- Adlandırılmış pipe’lar Unix’te yerel bir bileşendir: aynı makinedeki iki sürecin, diskte kalıcı bir dosya adı üzerinden birbiriyle iletişim kurmasına imkân veren bir mekanizma sağlar
- NT’de de aynı işlev vardır, ancak adlandırılmış pipe’lar ağ üzerinden çalışabilir
- Adlandırılmış pipe’lar paylaşılan bir dosya sistemine yerleştirilirse, farklı bilgisayarlardaki iki uygulama ağ ayrıntılarıyla uğraşmadan birbiriyle iletişim kurabilir
User-Space
- Yapılandırma:
- NT, sistem ve uygulama yapılandırmasını Registry adlı bir veritabanında merkezileştirerek eski Windows'ta kullanılan eski CONFIG.SYS, AUTOEXEC.BAT ve sayısız INI dosyasından uzaklaştı
- Bu bazı insanları çok kızdırdı, ancak sonuçta birleşik yapılandırma arayüzü herkes için faydalı oldu: uygulama yazmak daha kolay hale geldi çünkü desteklenecek tek bir temel vardı ve kullanıcılar da bakacak tek bir yer olduğu için sistemi daha kolay ayarlayabildi
- Buna karşılık Unix, hâlâ onlarca DSL ve tutarsız dosya konumları nedeniyle sıkıntı çekiyor
- Yapılandırma dosyalarını destekleyen her programın kendi sözdizimi var ve programın bunları hangi konumdan okuduğunu bilmek zor; ayrıca bu her zaman iyi belgelenmiş olmuyor
- Linux ekosistemi, XDG ve dconf (önceden GConf) aracılığıyla NT'ye benzer bir yaklaşımı ilerletmeye çalıştı, ancak masaüstü bileşenleri bu teknolojileri yalnızca kendi alanlarında kullanırken sistemin temel bileşenleri bunları benimsemedi ve geriye tutarsız bir karmaşa kaldı
- Uluslararasılaştırma:
- Microsoft, Windows 3.x'i zaten tüm dünyada dağıtan büyük bir şirket olarak yerelleştirmenin önemli olduğunu anladı ve NT'yi en baştan bu yetenekleri destekleyecek şekilde tasarladı
- Bunu, UTF desteğinin ancak 1990'ların sonlarına doğru ortaya çıkmaya başladığı ve diğer dillerin isteğe bağlı gettext eklentileriyle desteklendiği Unix ile karşılaştırın
- C dili:
- FreeBSD ve NetBSD gibi Unix sistemlerinin bir süredir hayalini kurduğu şeylerden biri, çekirdeği daha güvenli bir şekilde uygulamak için kendi C lehçelerini geliştirmekti
- Bu, GCC'ye özgü eklentilere bağımlı olan Linux dışında hiçbir yerde bir sonuca ulaşmadı
- Buna karşılık Microsoft, C derleyicisine sahip olma ayrıcalığına sahipti; bu yüzden bunu Microsoft C ile yazılmış NT'de gerçekleştirdi
- Örneğin NT, yazılım ve donanım istisnalarını ele almak için
try/except ifadeleri ekleme yeteneği olan Structured Exception Handling (SEH)'e dayanır
- Bunun büyük bir avantaj olduğunu söylemeyeceğim, ama gerçekten bir farktır
Sonuç
- NT, yayımlandığı dönemde çığır açan bir teknolojiydi
- Yukarıda açıklandığı gibi, bugün sistem tasarımında doğal kabul ettiğimiz birçok özellik NT'de baştan beri vardı; buna karşın diğer Unix sistemlerinin neredeyse tamamı bu özellikleri zaman içinde yavaş yavaş edinmek zorunda kaldı
- Sonuç olarak bu özellikler Unix felsefesiyle her zaman sorunsuz biçimde bütünleşmedi
- Ancak bugün NT'nin Linux veya FreeBSD'den gerçekten "daha gelişmiş" olup olmadığı açık değil
- NT başlangıçtan itibaren daha sağlam tasarım ilkelerine ve çağdaşı işletim sistemlerinden daha fazla özelliğe sahipti, ancak bugünlerde fark belirsizleşmiş durumda
- Yani NT gelişti, ama modern Unix kadar belirgin biçimde daha ileri hale gelmedi
- NT tüm bu sağlam tasarım ilkelerine sahip olsa da, kullanıcı arayüzündeki şişkinlik yüzünden tasarımın parlayamaması hayal kırıklığı yaratıyor
- Çok güçlü makinelerde bile işletim sisteminin yavaşlığına tanık olmak can sıkıcı olabilir ve bu durum hatta bu işletim sisteminin sonunu bile getirebilir
GN⁺ Özeti
- Bu yazı, NT ile Unix arasındaki tasarım farklarını karşılaştırarak NT'nin ilk tasarımının ne kadar ileri görüşlü olduğunu açıklıyor
- NT en baştan taşınabilirlik, çoklu işlem desteği ve uyumluluk hedefleriyle tasarlandı; bu da Unix ile arasındaki temel farklardan biri
- NT'nin nesne yönelimli çekirdeği, birleşik bellek mimarisi ve asenkron I/O arayüzü gibi öğeleri, Unix'e kıyasla daha gelişmiş özellikler sunuyor
- Ancak bugün NT ile Unix sistemleri arasındaki fark büyük değil ve NT'nin şişkin kullanıcı arayüzü performans düşüşüne yol açıyor
1 yorum
Hacker News görüşü
NT çekirdeği harika, ancak eski bir tasarım
NT ile Unix arasındaki en büyük fark, sürücülere yaklaşım biçimi
Modern WinNT'de Direct3D, çekirdeğin zorunlu bir parçası
NT çekirdeği süreçleri değil, thread'leri çalıştırır
WindowsNT, ilk dönemlerinde Linux'tan çok daha iyi tasarlanmış bir sistemdi
NT, üçüncü sistem olarak ikinci sistem sendromundan kaçındı
Geliştirici bakış açısından Windows ile Linux arasında farklar var
wchar_tkullanımı sorunluNT çekirdeği zarafete sahip, ancak açık kaynak değil
Linux'ta FUSE gibi bir birleşim vardı