Když hovoříte o serveru, proč byste měl vytvářet nové instance Wordu, Excelu, Outlooku, a kdo ví čeho ještě? Prostě si vytvoříte jednu instanci, a tu necháte běžet. V ní provedete, co potřebujete, a necháte jí pak zase ležet do dalšího požadavku. Jestli jste si vytvářel instance objektů pro každý request, tak se nedivím vašim dost nepříjemným pocitům :). Není to zdaleka tak hrozné, jako startovat OpenOffice pro každý request, ale pro ilustraci nesmyslnosti daného postupu takové srovnání postačí.
"Nabourané registry" nejsou problémem. FS nebo DB se mohou "nabourat" úplně stejně. Na rozdíl od Registry ovšem nemáte automaticky zálohu, pořízenou při minulém startu systému. Navíc existuje zálohování (a je důrazně doporučeno jej provádět), a Registry lze obnovit ze zálohy (když na to přijde, klidně spolu se zbytkem systému).
COM byl určen k IPC a dynamickému vytváření objektů. Nebylo účelem mít například COM objekty pro operace nad stringy, práci se sockety a threading. Pro tento účel byly určeny klasické knihovny. Těžko tedy COM vytýkat "chudou základní knihovnu objektů" - nebylo to účelem.
Samozřejmě, že MS generoval obrovskou spoustu objektů. Velká většina věcí od MS totiž COM nějak využívá. Podíl MS na trhu celkem jasně říká, že to bylo moudré rozhodnutí.
Skriptování mi přijde v COM světě celkem slušné (vbscript). Mám tu skripty, které pracují s DB, managují cluster, povídají si s Wordem a Excelem, provádějí dotazy do Active Directory, zapisují do storage i schema MS Exchange. V MS Script Repository najdete tisíce příkladů: http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true
Skoro nulové možnosti skriptování si představuji výrazně odlišně. Samozřejmě by to mohlo být i lepší. Unixy ovšem jako alternativu dodnes nabízejí pouze "spusť aplikaci, parsuj textový výstup". MS má dnes PowerShell, což je zřejmě první pokrok v oblasti skriptování za mnoho let.
Kód postavený na libc je pěkná myšlenka. Bohužel produktivita je pak nulová, a kód je plný bugů (už proto, že jde o C). Dnes stavíme výrazně komplexnější celky, než v šedesátých letech, a stavíme jich každý den veliké spousty. Potřebujeme proto frameworky, které umí daleko více, daleko lépe se používají, a jsou daleko méně náchylné na chyby.
Ano, Sun také zkoušel, co vše může s Javou dělat. Bohužel díky jisté strategické idiocii se toho moc nepovedlo. Embedded zařízení na Javě nikdy neběžela (jakkoliv to bylo první zamýšlené použití Javy). Nebo jste někdy viděl zařízení s formwarem psaným v Javě? Já ani jedno. JavaStations leží v muzeu neúspěchů Sunu, applety se z inetu téměř ztratily, a ani desktopové aplikace v Javě nikdy nebyly zvláště úspěšné. Dnes je Java chudou (ale jedinou realistickou) alternativou .NETu pro unixy. .NET je dnes primárním API Windows, přináší odpovědi na dnešní problémy stability a bezpečnosti (resp. bugy spolené s užíváním jazyka C/C++), a do budoucna v .NETu bude zřejmě i kernel.
Paradoxem je, že Sun mohl být ve velmi dobré pozici, kdyby netrval na Čisté Javě (ve chvíli, kdy neměl ani editor dialogů, Java neuměla tisknout, a přizpůsobení bylo nutně potřeba). Sun hrál poker s vysokými sázkami, a nedal to.
Názor ke zprávičce MS Windows Home Server poškozuje soubory
