OPERAČNÍ SYSTÉMY

My FreeOS Theme logo - U_Must_C_It!

FreeDOS logo   Micro$oft sice zastavil vývoj MS-DOSu, ale nadšenci pod názvem 'The FreeDOS project' vyvíjí DOS jako GNU, takže máte možnost se pohrabat ve zdrojácích, případně se i podílet na jeho vývoji. Další spřízněná grupa dělá GUI s názvem Seal/BadSeal v DJGPP. FreeDOS podporuje nativně FAT16 i FAT32. Postupem času vznikly free alternativy ke všem externím příkazům MS-DOS, vychytaly se závažné chyby a FreeDOS se tak stal docela použitelným. FreeCOM nabízí pokročilé funkce editace příkazového řádku, jako např. historii a doplňování jmen souborů tabulátorem (pro MS-DOS lze použít utilitu CmdEdit jako náhradu zastaralého doskey.com). Více viz. homepage FreeDOSu: http://www.freedos.org a Sealu: http://sealsystem.sourceforge.net
Poslední testovací verze FreeDOS kernelu: http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others
Novinky o systémových utilitách, driverech a vývojových nástrojích se dozvíte na fóru: http://www.bttr-software.de/forum
Archiv starších, některých až legendárních dosovských programů najdete na této české stránce: http://www.osdos.net
Zajímavý pohled do historie mapující vznik a vývoj DOSu na platformě IBM PC: zde.
      7.2.2012 vyšel nový FreeDOS kernel 2041.

FreeDOS bootující z ROM!
Ano, FreeDOS je možné nabootovat přímo z ROM (umístěné na externí ISA kartě nebo přímo spolu se systémovým BIOSem ve FlashROM) i na PC bez disků. To nyní umožňuje můj projekt ROMOS.


DR-DOS logo   Nyní jsem se dozvěděl o dalším pokračovateli DOSu. Novell dříve dělal taky svou verzi DOSu (posl. Novell DOS 7.0). Ten převzala Caldera a pod názvem OpenDOS 7.01 ho dala volně k dispozici (Caldera DOS je nyní používán i v Novell Netware). Nějaký čas to už vypadalo, že Caldera uveřejní i zdrojáky, ale nakonec je prodala firmě Lineo. Tím také OpenDOS ze stránek Caldery zmizel, a našel jsem ho na http://www.lineo.com jako Lineo DR-DOS 7.03 (zatím poslední verze). Pro nekomerční účely byl nabízen zdarma, ale Lineo si to rozmyslelo a image disket z webu stáhlo. Nyní si ho můžete stáhnout zde: .../download/dr-dos.703/drdos.htm (local) nebo tady http://www.drdos.net/download.htm
Vývoj jádra DR-DOSu v současnosti pokračuje jako německý opensource projekt EDR-DOS, který v sobě už zahrnuje nativní podporu FAT32. Navštivte jeho domovskou stránku na: http://www.drdosprojects.de

Novinky oproti M$-DOS 6.22:
+ Vylepšená správa paměti, vystačíte si v pohodě s dodávaným EMM386.
+ Podpora DPMI a DPMS.
+ Můžete ho provozovat na stejném disku s W95 nebo jiným DOSem. systémové soubory potřebné v rootu se jmenují ibmbio.com a ibmdos.com, konfigurační soubory se mohou jmenovat dconfig.sys a *.bat)
+ Obsahuje jednoduchý bootmanager, který se instaluje do MBR.
+ Obsahuje kvalitní taskswitcher/manager, mě se povedlo spustit např. 2 x Quake a přepínat se, nebo lze na pozadí nechat běžet přehrávač mp3.
+ Obsahuje Novell Personal NetWare server/klient, umožňuje propojení počítačů protokolem IPX (hodí se na hraní starších her po síti).
Tak, abych jen nechválil:
- Není 100% kompatabilní s MS-DOS, takže pár programů (her) tam neběží, ale pokud vyřadíte agresivní EMM386, tak by to mohlo jít.
- Nefunguje Quarterdeck QuickBoot.

      Také vám doporučuji si stáhnout nejlepší souborový manažer DOS Navigator 6.4.0 Open Source z http://www.dnosp.com nebo starší verzi 1.51.11 z lokálního downloadu.
      Zdá se, že tým DN-OSP konečně vychytal mouchy, jako třeba crash realmode verze pod QEMMem a pod. Asi největší novinkou je podpora dlouhých názvů (pokud běží pod W9X), taky je zde užitečné hledání a záměna hexa řetězců v editoru, přibyla spousta tabulek XLT a pár dalších drobností. Zatím jsem na žádnou chybu nenarazil, takže můžete zkusit upgradovat.
      Pokud naopak potřebujete nějaký malý, nenáročný souborový manažer, který na disketě nezabere mnoho místa a poběží dobře i na 286, můžete vyzkoušet DOSZIP Commander. Je to opensource, napsaný převážně v assembleru a autor ho stále vylepšuje. Nechybí podpora komprimovaných formátů 7ZIP a ARJ.

      29.3.2004 vydala firma DeviceLogics DR-DOS verze 8.0. Hlavní novinkou má být podpora velkých disků a FAT32, dále možnost bootovat z ROM/FlashDisku. Bohužel není volně k dispozici, jednouživatelská licence stojí 25$.
      Aktuální verzi DR-DOSu 8.1 od DeviceLogics si můžete nyní stáhnout zde a plnou 8.0 zde. Jak se ale ukázalo, žádné velké překvapení se nekoná. Jádro zůstalo skoro stejné, akorát do něj byly aplikovány patche z opensource EDR-DOSu (což není moc férovka to pak nabízet za 45$) a podpora FAT32. DR-DOS přiřazuje písmena diskovým oddílům jinak, než je zvykem u MS-DOSu a FreeDOSu, což se mi moc nelíbí (všechny FAT32 oddíly dostaly přednost a obsadili písmena hned za boodiskem C:). Další velkou nevýhodou je, že zde nefunguje task manažer známý z DR-DOSu 7.0x, který byl asi ta nejzajímavější věc na DR-DOSu.


Datalight logo ROM-DOS   je dalším klonem DOSu, který vznikl už v roce 1989 se zaměřením hlavně na průmyslové a embedded systémy. Např. firma Canon ho používala ve svých digitálních fotoaparátech. ROM-DOS je tedy uzpůsoben pro běh z ROM/FlashDisků a podporuje formát spustitelných souborů RXE, který nevyžaduje nahrávání celého programu do RAM, ale pouze datového segmentu. Datalight vychvaluje kompatabilitu s MS-DOSem, že prý kdo objeví program, který poběží v MS-DOSu, ale nepoběží v ROM-DOSu, tak se to po zaslání programu vynasnaží v další verzi napravit. Před nedávnem Datalight uvolnil zdarma ke stažení ROM-DOS verze 6.22 a 7.1 (je potřeba se napřed zaregistrovat) s podporou FAT32, dlouhých názvů, TCP/IP stackem a jednoduchým WWW serverem. Existuje i SDK, kde si lze nakonfigurovat vlastní kernel na míru (např. vyřadit podporu LFN, FAT32 atd...) za účelem zmenšení velikosti, bohužel však kernel nelze zkomprimovat jako v případě FreeDOSu, kde jsem se dostal až na nějakých 36 kB. Na druhou stranu komprimovaný kernel by nemohl běžet přímo z ROM. SDK ale není zatím volně k dispozici.


LZ-DOS logo  LZ-DOS 7.1   je přímá free náhrada MS-DOSu 7.1, který je součástí Windows 98. Podporuje tedy FAT16 a FAT32, používá stejné příkazy v config.sys a zpracovává konfigurační soubor windows msdos.sys. Umožňuje tedy spouštět Windows 9x ale také Windws 3.x. Navíc systémové soubory jsou o dost menší, což se může hodit v případě bootdiskety, kde se šetří každý kB. Ke stažení je pouze jádro systému: http://dos.nm.ru, programy externích příkazů lze použít z MS-DOSu, FreeDOSu atd. LZ-DOS jsem vyzkoušel úspěšně s Windows 98SE, ale bohužel mi z nějakého důvodu nefungovalo spuštění minulé verze DOSu (poslední položka ve start-up menu), zobrazilo se jen Loading previous LZ-DOS version... a kouslo se to. Takže na boot HDD nadále nechávám MS-DOS 7.1 a 6.22.
      Později se na BTTR fóru vedly dost plamenné diskuse, zda-li LZ-DOS není jen ukradený MS-DOS 7.1 s přepsanými copyrighty a zakódovaný neznámou kompresí. Některé shodné části kódu nalezené v paměti a loader tomu silně nasvědčují, ale celý soubor zatím nikdo nedekomprimoval a neporovnal.


TeraByte logo  TBOS 1.01b   je miniaturní 16-bit DOS-like kernel (podporuje určitou podmnožinu standardních DOSových služeb), který firma TeraByte, Inc. uvolnila jako součást TeraByte OS Deployment Tool Suite. Systém se skládá z loaderu (tbosldr, 1,8 kB), jádra (tbos.sys, 18 kB) a dvou shellů (tbcmd.exe, 60 kB a tbosdt.exe, 312 kB). Samotné jádro umožňuje spustit některé DOSovské programy .COM / .EXE, avšak díky neúplné implementaci služeb většinou skončí chybou upozorňující na číslo chybějící funkce. Nepodařilo se mi např. spustit command.com z FreeDOSu nebo MS-DOSu 6.22. Také nepodporuje přístup na HDD / FAT16, ale běží jen z diskety. Při startu jádro spouští automaticky programy zapsané v souboru tbos.str (obdoba autoexec.bat).
      Shell tbcmd.exe funguje hlavně jako jednoduchý interpret skriptů, které se asi nejvíce podobají jazyku BASIC. Z příkazové řádky lze zadat jen minimum příkazů, nezná ani takové základní příkazy jako DIR, ale můžete si ho napsat jako skript s využitím funkcí findfirst, findnext. Také můžete spouštět externí DOSové programy. Při startu provádí skript ze souboru startup.tbs.
      Druhý shell tbosdt.exe obsahuje sadu výkonných příkazů, které můžou přijít vhod např. při opravě nefunkční instalace Windows XP. Umožňuje přimountovat různé souborové systémy (na fyzickém oddílu nebo v image souboru): FAT16 / 32 včetně LFN, NTFS (částečná podpora), ISO9660 a MS Virtual PC disk image, lze vytvářet image z oddílů nebo obsah z image obnovit. Také jsou zde příkazy pro editaci registrů Windows. Součástí je i ukázkový skript xp_ide_install.run, pomocí něhož lze do neběžícího systému doinstalovat potřebný ovladač řadiče.
      Dále mě na stránce TeraByte zaujala utilita Image for DOS na zálohování a obnovu oddílů či celých disků (obdoba Norton Ghost). Zálohovat lze na jiné diskové oddíly, na USB Mass Storage zařízení, FireWire disky a dokonce má i přímou podporu pro vypalování na ATAPI CD/DVD mechanikách. Nemá však podporu sítě.


DOS a EMS/XMS paměť
      V dřevních dobách DOSu na 16-bitovém procesoru intel 8086/8088 byla maximální velikost fyzické paměti limitována počtem 20ti adresních vodičů procesoru na 1 MB (220). Z toho byla horní oblast (A0000 - FFFFFh) vyhrazena pro mapování ROM pamětí a bufferů přídavných karet, takže v reálu bylo k dispozici jen 640 kB tzv. základní, nízké nebo konvenční paměti (00000 - 9FFFFh). Ano, jak kdysi prohlásil velký Bill: "640 kB should be enough for everyone!" (a dnes nám nestačí ani 640 MB :).
      Na tento limit se ale začalo narážet překvapivě brzy a tak už na 8086 se hledaly různé obezličky, jak do systému dostat více paměti. Protože adresová sběrnice stávajícího CPU se nedá jen tak jednoduše nafouknout, byla vymyšlena přídavná paměť (v podobě veliké zásuvné ISA karty se spoustou DRAM čipů DIP) EMS (Expanded Memory Specification), jejíž softwarové rozhraní standardizoval Lotus, Intel a Microsoft (odtud název LIM-EMS). Princip byl jednoduchý, v rezervované oblasti 640 - 1024 kB se vyhradila část paměti (až 64 kB) jako EMS rámec (EMS frame) do kterého se mapovalo několik 16kB EMS stránek, které pak byly přístupné. Mapování stránek řídil ovladač EMS, který poskytoval programům služby INT 67h. Maximální velikost EMS je 32 MB (2048 stránek). Tuto paměť bylo možno používat pouze pro data a jak je zřejmé, rychlost byla negativně poznamenaná neustálou potřebou přemapovávání stránek v rámci.
      S příchodem procesoru intel 80286 se problém adresace fyzické paměti vyřešil, neb intel přidal další 4 adresní linky a tak bylo možno naadresovat až 16 MB (224) fyzické paměti. Později u 32-bitového 80386 to je až 4 GB (232). Tato plná adresace funguje pouze v nově zavedeném chráněném módu (a u 386 a výše ve virtuálním módu 86) do kterého se musí CPU nejdříve přepnout určitou sekvencí instrukcí. DOS však z důvodu kompatability nadále využívá jen reálný mód, kde je adresace stejná jako u 8086. Aby se zpřístupnila rozšířená paměť XMS (eXtended Memory Specification) i pro DOSové programy pracující v reálném módu, je potřeba ovladač rozšířené paměti XMM (eXtended Memory Manager), který programům poskytuje služby přes INT 2Fh. XMM se pak sám stará o přepínání reálného a chráněného módu a přesun dat mezi konvenční pamětí a XMS. Maximální velikost paměti XMS 2.0 je 64 MB a 4 GB u XMS 3.0. DOSové programy běžící v chráněném módu si paměť spravovaly samy nebo přes extender, později prostřednictvím DPMI (DOS Protected Mode Interface) serveru/služeb.
      V MS-DOSu od verze 5.0 byl přítomen správce rozšířené paměti himem.sys. Jeho použití je velmi jednoduché, stačí do config.sys přidat řádek:
DEVICE=C:\DOS\HIMEM.SYS
XMS paměť využívá pro data např. disková cache SmartDrive, která je taktéž standardní součástí DOSu. Pro programy, které potřebují EMS paměť je tu ovladač emm386.exe, který jednak emuluje EMS ve virtuálním módu 86 a dále zpřístupňuje paměť UMB, viz níže. Do config.sys přidáme další řádek:
DEVICE=C:\DOS\EMM386.EXE RAM HIGHSCAN AUTO
HIMEM a EMM386 má celou řadu parametrů, doporučuju prostudovat help.
      Tyto standardní ovladače paměti v MS-DOSu nebyly provedeny zrovna precizně, a tak se řada firem snažila vyvinout svoje vlastní správce paměti, které budou rychlejší, požerou méně konvenční paměti a nabídnou rozšířené funkce. Mezi nejznámější alternativy patří Qualitas 386MAX a Quarterdeck QEMM386. Já jsem dlouho primárně používal QEMMa a příde mi nejpropracovanější. Integruje v sobě správce XMS, EMS, UMB, VCPI a DPMI server (ten ale obsahuje některé chyby a moc si nerozumí s DJGPP programy, takže používám raději CWSDPMI). S jeho rozsáhlými nástroji na optimalizaci config.sys a autoexec.bat jsem dosáhl vždy dostatek volné konvenční paměti (obvykle přes 600 kB) i při velkém množství natažených ovladačů a TSR. Velice příjemnou funkcí je QuickBoot, kdy při stisku CTRL+ALT+DEL počítač neprovádí klasický restart s POSTem, ale ihned začne zavádět OS z disku nebo diskety. QEMM také obsahuje podporu pro Windows95, kde umožňoval takové šílenosti jako kompresi dat v RAM. Hlavní nevýhoda QEMMa je v jeho zastaralosti (poslední verze 9.01 je z roku 1998) a nefunguje mi pod ním víc jak 256 MB XMS. Občas se také vyskytla nekompatabilita s některými programy, které bylo potřeba pustit pod EMM386, ale těch bylo minimum.
      O tom, že DOS is not dead, svědčí i nově vyvíjený OpenSource správce paměti JEMM386 od Japhetha z Německa. JEMM vznikl ze zdrojových kódů EMM386 FreeDOSu. Zahrnuje v sobě správce EMS, UMB, VCPI a VDS API. Jsou k dispozici dvě verze: jemm386.exe jenž potřebuje externí XMM (např. himem.sys nebo himemx.exe) a jemmex.exe, který v sobě zahrnuje i XMM. Podpora DPMI zde záměrně není, neboť na to se zaměřuje další Japhethův projekt HX DOS extender. JEMM umožňuje rozšiřovat funkčnost zaváděním 32-bit modulů/driverů v chráněném módu, tzv. JLM (JEMM Loadable Module) pomocí jload.exe. V současnosti jsou k dispozici 2 moduly - xdma32.dll (ovladač UltraDMA) a xcdrom32.dll (ovladač CD/DVDROM). Výhoda použití těchto modulů je zejména v šetření konvenční paměti. Novější verze JEMM též obsahuje přepínač FASTBOOT, který je ekvivalentem QuickBootu u QEMMa. JEMM nemá žádné limity ve velikosti XMS jako QEMM. Začal jsem ho primárně používat od verze 5.65 a zatím jsem s ním velmi spokojen, těch pár výjimek, co nechodily s QEMMem tak s JEMMem fungují. Můj řádek v config.sys vypadá takto:
DEVICE=C:\DOS\JEMMEX.EXE A20METHOD:FAST XMSHANDLES=64 FRAME=NONE I=D000-EFFF SPLIT SB FASTBOOT VERBOSE
JEMM má spousty parametrů, takže doporučuju pročíst readme.

DOS a UMB paměť
      MS-DOS sám o sobě umí pracovat pouze s tzv. konvenční pamětí - prvních 640 kB. V rámci reálného módu by však mohl dosáhnout na celý první megabajt. K tomu potřebuje ovladač horní paměti UMB (Upper Memory Blocks). V oblasti UMB 640-1024 kB se nacházejí namapované paměti ROM systémového BIOSu, VGA BIOSu a případně dalších adaptérů, okno videopaměti VGA a případně okno pro mapování paměti EMS (Expanded Memory Specification). Zbylou UMB paměť, která by jinak ležela ladem, lze s výhodou použít pro zavedení DOSových ovladačů a rezidentů, čímž se uvolní tolik potřebná konvenční paměť. Novější verze MS-DOSu se také částečně umožňují nahrát do UMB. U systémů s více jak 1 MB paměti je možné pro zavádění TSR použít i HMA (High Memory Area) - prvních 64 kB rozšířené paměti XMS (eXtended Memory Specification) začínající nad hranicí 1 MB. Standardně podporu UMB a EMS zajišťuje ovladač emm386.exe, který je ale poněkud mastodontí a sám zabere hodně paměti. Pokud nepotřebujeme EMS (kterou využívají jen hodně staré nebo obskurní programy, novější používají XMS nebo DPMI), lze nároky na paměť poněkud snížit přepínačem NOEMS. Příslušné řádky v config.sys pak mohou vypadat takto:
DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS /V
DEVICE=C:\DOS\EMM386.EXE NOEMS
Pokud ale chceme ušetřit ještě více paměti a nepotřebujeme EMS, pak se nabízí alternativa v podobě freeware ovladače UMBPCI, který je menší a rychlejší a je stále aktualizován s příchodem nových chipsetů. Řádky v config.sys se pak změní takto:
DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS /V
DEVICE=C:\DOS\UMBPCI.SYS /I=D400-E3FF
kde parametr I=a1-a2 udává rozsah paměti, který smí UMBPCI použít (normálně by měla fungovat autodetekce, pouze pokud jsou problémy, omezíme rozsah ručně). Pokud potřebujeme i EMS paměť, můžeme zavést umbpci.sys před emm386.exe a tím se taky pár kB konvenční paměti ušetří. Já osobně radši používám inteligentní all-in-one správce paměti QEMM386, který ze systému vyždímá opravdu maximum konvenční paměti, ale občas se s některými programy nesnáší a pak je UMBPCI dobrá alternativa.

DOS a více jak 64 MB paměti
      Nedávno jsem si koupil 128 MB DIMM, ale ať jsem ďál, co jsem ďál, víc jak 64 MB paměti se mi v DOSu nevypsalo. A to jsem vyzkoušel asi 5 různých verzí DOSu. Nakonec mě napadlo pročíst dokumentaci ke QEMMu a kápnul jsem na prográmek scanmem.com, který projede celou paměť a vrátí vám rozsah platných fyzických adres. Ten pak předáte QEMMovi jako parametr USERAM. Např. u mně to vypadá takto:
DEVICE=C:\QEMM\QEMM386.SYS RAM USERAM=0040F000-00800000 ST:F RF
Tento problém patrně vzniká tím, že ve CMOS jsou na velikost RAM vyhrazeny 2 Byte, takže max. vyčíslitelná velikost je právě 65536 kB (podobnost s problémem Y2K je čistě náhodná, že). Záleží pak na tvůrci BIOSu, kde si jistá funkce velikost RAM najde.
      Skutečně, po update BIOSu na mojí desce najednou funguje detekce paměti bez problémů a QEMM si paměť najde sám. Zdá se ale, že je zde další limit - 256 MB. Víc asi QEMM nezvládne ani s parametrem USERAM. S himem.sys z WIN98 funguje klidně 2048 MB. Další možností je použít Japhethův HimemX.sys (zde je moje upravená verze 3.33, která korektně funguje i na Am386SX) nebo JemmEx.exe.

DOS a UltraDMA
      S rozmachem nových velkokapacitních harddisků a s tím, jak stoupá jejich rychlost, se vyvíjí i jejich rozhraní. Na první pohled je to stále též IDE, ale přenosové protokoly pokročily z PIO mode 0 až na UltraDMA 133. To, že disk nabízí takovou (byť jen papírově) vysokou rychlost je sice hezké, ale samo o sobě to nestačí. Je třeba mít i odpovídající řadič (což může být trochu problém na stále ještě oblíbených deskách s čipsety BX). Ale ani tak nemáme vyhráno, pokud operační systém nových funkcí nepoužívá. I když v BIOSu a na disku povolíte nejrychlejší přenosový mód, DOS bude číst přinejlepším v režimu PIO4. Dříve se proto k řadičům dodávaly ovladače i pro DOS v podobě souboru *.sys. Nyní se již DOSem žádný výrobce HW nevzrušuje, takže máme smůlu.
      Naštěstí je tu projekt UDMA driver, který tvoří Jack R. Ellis a Luchezar Iliev Georgiev. Tento driver (zatím stále ve vývoji) podporující některé chipsety intel, VIA, SiS, Ali, zapne UDMA pod DOSem. Nárůst rychlosti je docela znát. Na mojem WD 40 GB v režimu UDMA33 jsem zaznamenal nárůst rychlosti čtení z asi 9 MB/s na asi 14 MB/s. Autor uvádí nárůst dokonce 2,2 -> 24,9 MB/s na VIA chipsetu a UDMA66. Pro měření přenosové rychlosti můžete použít můj prográmek RAWSPEED.
      V současnosti je trochu problém sehnat poslední verzi ovladače UDMA/UIDE Jacka R. Ellise, oficiální linky byly staženy z webu a proto jsem je umístil na lokální download. Pokud používáte správce paměti JEMM386, můžete použít JLM modul xdma32.dll, který je součástí balíčku.

DOS a SATA mechaniky
      Poté, co intel vydal chipset ICH8, zmizela z PC nadobro nativní podpora klasického rozhraní PATA (IDE), které bylo železným standardem přes 20 let. Přitom zejména u optických mechanik je nabídka zatím dosti omezená, i když už se pár vypalovaček objevilo. Někteří výrobci na tyto základní desky lepí jakési parodie na IDE řadič typu Jmicron, které ale nepodporují ATAPI mechaniky (týká se jen některých starších typů), zbývá tedy koupit buď IDE-SATA redukci nebo PCI řadič, který ATAPI podporuje. Já sem si základní desku vybíral podle toho, aby měla PATA kanálů dostatek. Pokud už ale máme SATA mechaniky, jaká je funkce v DOSu? U HDD stačí přepnout v SETUPu SATA kanál do režimu compatible IDE nebo legacy a o obsluhu se postará rozšíření BIOSu INT 13h. U CD/DVD SATA mechanik jsem se setkal s tím, že je stávající dosovské ovladače nerozpoznají. Existuje však OpenSource ovladač GCDROM.SYS [4 kB], který na běžných chipsetech SATA mechaniky rozpozná (nepodporuje PATA). Zavádí se z config.sys jako každý jiný CD ovladač, parametrem /Cx lze vybrat SATA kanál (x=1..n). Také jsem na stránkách HP našel DOSový ovladač CD/DVD SATA mechanik pro řadiče v režimu AHCI: AHCICD.SYS [12 kB]. Doporučuji přidat i na záchranné boot CD a diskety.
      Nyní můžu potvrdit bezproblémovost SATA HDD v DOSu z vlastní zkušenosti. Koupil jsem si Western Digital RE WD5000ABYS 500 GB a připojil ho na SATA řadič ICH7R. Druhý PATA disk Seagate Barracuda 120 GB, který používám v šuplíku, jsem připojil pomocí IDE/SATA redukce Kouwell KW-5562 s převodníkem Sunplus SATALink SPIF3811A. V SETUPu jsem nastavil režim IDE, combined mode a zvolil, aby se SATA porty emulovaly jako primární IDE kanál a PATA (kde mám připojenou CD a DVD mechaniku) jako sekundární kanál. Systém normálně nabootoval a vše fungovalo správně, dokonce jsem viděl i celou kapacitu 500GB disku. Zde je log z programu EDDINFO. Při měření rychlosti čtení/zápisu jsem se dostal na bídných 7 MB/s, ale po zavedení ovladače UDMA.SYS se rychlost vyhoupla na slušných 55 MB/s. Kombinovaný IDE-SATA řadič se choval jako standardní dvoukanálový IDE s I/O porty klasicky na 1F0h a 170h, tedy zcela transparentně. Zkoušel jsem na redukci připojit i ATAPI DVD-RW mechaniku, ta se sice v BIOSu detekovala správně, ale nefungovala korektně (buď PC zatuhlo při čtení nebo už při startu systému. Zjistil jsem, že DOS je schopen fungovat i v Enhanced mode (2x PATA + 4x SATA zařízení), RAID mode a AHCI mode. Vše je řízeno rozšířením služeb BIOSu INT 13h. V Enhanced režimu mají ale SATA kanály jinou I/O adresu a některé low-level diskové utility nemusí HDD najít - to je ale stejný problém jako v případě přídavného IDE řadiče. Také Windows 98 mají s Enhanced módem problém a zatuhnou při bootu, funguje jen nouzový režim, kdy se používá přístup přes BIOS. Pro Windows 9x je také velice důležité nainstalovat aktualizaci diskového ovladače ESDI_506.PDR s podporou LBA48 (48-bitové adresování sektorů) pro zpřístupnění plné kapacity disků > 128 GB. Jinak může dojít k poškození dat, pokud se Windows pokusí zapisovat za hranici 128 GB. Na FAT32 však zůstává omezení max. 4 GB velkých souborů. Není ale problém se z Windows 98 dostat i na NTFS oddíl za pomocí (nyní volně dostupného) programu Paragon NTFS for Win98/ME 1.7.
      Zde je přehled dosažených přenosových rychlostí disku WD5000ABYS v různých režimech SATA řadiče ICH7R a s použitím UDMA driveru v MS-DOSu 6.22 (měřeno programem RAWSPEED).

režim  R/W bez UDMA.SYS [MB/s]   R/W s UDMA.SYS [MB/s] 
 IDE (combined/enhanced):  6,8 / 6,3 56,1 / 47,5  
 RAID: 31,3 / 14,0 31,3 / 14,0 *
 AHCI: 6,8 / 6,3 6,8 / 6,3 *
* UDMA.SYS nerozpoznal připojené jednotky, nemá vliv na rychlost

DOS a disková cache
      Samotné jádro DOSu (vyjma miniaturních buffers=1-99 v config.sys) neobsahuje žádný systém cachování přístupu na disk. Přitom bez alespoň minimální cache o pár MB je práce se soubory čistým masochismem. Od toho je zde spousta externích programů, jako třeba SmartDrive v MS-DOSu, NWCache v DR-DOSu, LBACache ve FreeDOSu a další programy třetích stram. Disková cache napomáhá zejména při práci s velkým množstvím malých souborů, které mají šanci se do cache vejít celé a tak je snížen počet přístupů na disk. Co když ale pracujeme naopak s velkými soubory? Jak jsem zjistil, v řadě případů naopak disková cache snižuje propustnost systému (než by měl bez cache). Udělal jsem proto malé porovnání různých cache programů na testovacím bloku 256 MB dat a cache velikosti 16 MB pod MS-DOS 6.22:

cache  záspis [MB/s]   čtení [MB/s] 
bez cache (buffers=30) 24,9 41,6
Microsoft SmartDrive 5.02 16,8 38,5
Datalight ROMDOS 7.1 SmartDrive 20,4 30,1
IBM SmartDrive 5.10 22,7 39,1
FreeDOS LBACache 2006 (TUNA) 19,4 29,9
FreeDOS LBACache 2006 (TUNW) 24,5 35,3
QCache 5.7 26,2 39,8
DR-DOS NWCache 1.02 (max 7,6 MB) 26,9 40,9
Norton Speedrive 4.07 26,2 44,8

Jak je vidět, nejvyšší propustnost má nejstarší program Norton Speedrive 4.07, což může být dáno třeba jednodušími algoritmy které budou méně efektivní pro cachování malých souborů, nebo je to prostě kvalitní kód ze staré školy :) ale to by bylo zas na jiný test. U chache programů ale hrajou roli i další faktory jako třeba snášenlivost s různými správci paměti nebo velikost obsazené konvenční paměti. V tom zase vynikala QCache a LBA Cache z FreeDOSu, které jí zabraly nejméně.

DOS a USB
      Houf USB periferií se neustále rozšiřuje a vytlačuje stará zařízení na sériový či paralelní port. Někteří iniciativní výrobci základních desek už dokonce přestaly tyto porty osazovat. Sehnat tak třeba novou myš či tiskárnu na klasický port začíná být pomalu problém (sám mám M$ IntelliMouse Optical, ke které jsem naštěstí ještě dostal USB -> PS/2 redukci). Pro BFU je tento vývoj jedině ku spokojenosti, protože jim postačí si místo 5-ti konektorů pamatovat jen jeden a když tam něco zastrčí tak to hned samo začne fungovat. Trochu méně šťastní jsou pak bastlíři, kteří stavěli různá udělátka na COM/LPT porty z důvodu snadné komunikace (např. běžný terminál) a programového obsloužení (tou dobou jim ještě operační systém neházel klacky pod nohy v podobě zákazu přímého přístupu na port jako je to dnes v systémech NT). Ano, existují USB -> COM převodníky, ale zatím nejsou nejlevnější.
      Na druhou stranu USB (2.0) poskytuje výrazně vyšší rychlost, tolik potřebnou pro tiskárny, scannery a paměťová zařízení. Naštěstí některé firmy na nás, uživatele DOSu, úplně nezapomněli a objevilo se tak pár ovladačů různých USB zařízení pro DOS. Všechny, které jsem našel (ext. Iomega ZIP, ext. CD-ROM, Ninja flashdisk a další Mass-Storage driver) jsou ke stažení v tomto balíčku: USBDRV.ZIP [124 kB]. Jako další alternativu jsem objevil program USBMASS/386 4.05 [87 kB] s podporou rychlého USB 2.0, který není třeba instalovat do config.sys, ale zavede ovladač a přiřadí písmeno za běhu. První podmínkou úspěchu je, aby ovladač rozpoznal váš chipset, resp. UHCI/EHCI řadič a poté i dané zařízení. Chce to trochu experimentovat. Osobně jsem to zkoušel se svojí USB 2.0 čtečkou paměťových karet 8 v 1 a podařilo se. Satčilo v config.sys zavést tyto dva ovladače:
REM DOS USB driver
DEVICE=C:\USBDRV\USBASPI.SYS
DEVICE=C:\USBDRV\DI1000DD.SYS
Po restartu mi přibyly 4 nové diskové jednotky, po zastrčení CompactFlash karty jsem ji mohl bez problémů číst a zapisovat a dokonce použít i low-level nástroje jako DiskEdit, ScanDisk, Defreg a pod., zkrátka karta se chovala jako úplně standardní disková jednotka. BTW moderní BIOSy stále častěji nabízí funkci USB Legacy, která zpřístupní USB Mass-Storage zařízení přímo bez jakýchkoliv ovladačů a dokonce z nich umožní i bootovat (takto to aspoň funguje na mé nové desce Asus P5LD2).


C:\DOS\PLUS>device USBASPI.SYS

ASPI Manager for USB mass-storage  Version 2.06
 (C)Copyright Panasonic Communications Co., Ltd. 2000-2003

ID:0 LUN:0 = OTi CF CARD Reader 2.00

C:\DOS\PLUS>devload DI1000DD.SYS
DEVLOAD v3.15 (C) 1992 - 1996 David Woodhouse <Dave@imladris.demon.co.uk>
 Patches for v3.12-3.15 by Eric Auer 2004/2005 <Eric*CoLi.uni-sb.de>
 Loads device drivers from the command line. Needs DOS 3 or newer.
Filename C:\DOS\PLUS\DI1000DD.SYS

DI1000 ASPI DISK Driver Ver 2.00
Copyright(C)2001 NOVAC Co.,Ltd.

Available ID = 0
ID 0 = HD .. OTi CF CARD Reader
 #1 : PRI DOS 16MB drive = L:
1 drives installed.
Driver staying resident.

      2.7.2009 jsem objevil nové OpenSource USB ovladače DOS USB drivers 0.08 od Breta Johnsona. Jedná se o testovací verzi, která zatím podporuje pouze UHCI řadiče intel a VIA (pomalejší režim USB 1.1). Do budoucna však autor slibuje i podporu OHCI a EHCI (USB 2.0) a dalších. Ovladače jsou koncipovány jako TSR programy, takže není třeba je natahovat hned v config.sys ale kdykoliv podle potřeby. Ovladač je rozdělen na dvě části: low-level driver pro UHCI řadič (usbuhci.com) a high-level drivery pro konkrétní periferie jako jsou klávesnice (usbkeyb.com), myši (usbmouse.com), joysticky (usbjstik.com), tiskárny (usbprint.com) a Mass-Storage zařízení (usbdrive.com). Dále jsou v balíčku i další podpůrné utility pro diagnostiku a ladění. Např. program usbhosts.com vypíše informace o nalezených USB řadičích v systému (můj ICH7):

USBHOSTS 0.06, (C) 2007-2009, Bret E. Johnson.
       PCI BUS
      ----------			     BASE	    USB DRIVER
      I   B  D F		      BASE   PHYSICAL	-------------------
HOST  d   u  v n	      USB IRQ I/O    MEMORY	HST		BW
TYPE  x   s  c c  VENDR PROD  VER NUM ADDR   ADDRESS	IDX   STATUS   USED
----  - --- -- -  ----- ----- --- --- ----- ----------	--- ---------- ----
UHCI  0   0 29 0  8086h 27C8h 1.0  11 E300h ----------	  0 Running	 0%
		  Intel Corp
UHCI  1   0 29 1  8086h 27C9h 1.0  11 E000h ----------	--- ---------- ----
		  Intel Corp
UHCI  2   0 29 2  8086h 27CAh 1.0   3 E100h ----------	--- ---------- ----
		  Intel Corp
UHCI  3   0 29 3  8086h 27CBh 1.0  10 E200h ----------	--- ---------- ----
		  Intel Corp
----  - --- -- -  ----- ----- --- --- ----- ----------	--- ---------- ----
EHCI  0   0 29 7  8086h 27CCh 2.0  11 ----- F910_0000h	--- ---------- ----
		  Intel Corp

program usbdevic.com vypíše informace o připojených USB zařízeních (zde je vidět USB klávesnice Dell):

USBDEVIC 0.05, (C) 2008, Bret E. Johnson.
Program to display information about Devices attached to the USB Host(s).

			       DEVICE ADDRESSES
-------------------------------------------------------------------------------
 Host Index:  0  Host Type: UHCI  Bus Type: PCI   IRQ#: 11  Root Hub Ports: 2
 Vendor: 8086h = Intel Corp				    Product: 27C8h
-------------------------------------------------------------------------------
		DEVICES 				  INTERFACES
---------------------------------------------  --------------------------------
			   L		    C  I A		  O
ADRS			   o	     P	    o  n l		  w
----   (hex)		   S	     o BUS  n  t t		  n
Test VEND PROD	   Sub Pro p USB HUB r POWR f  f I		  e	Sub Pro
RWak  ID   ID  Cls Cls col d VER ADR t (mA) g  c n  DESCRIPTION   d Cls Cls col
---- ---- ---- --- --- --- - --- --- - ---- -  - - -------------- - --- --- ---
  1  8086 27C8	 9   0	 0 . 1.0 ... . s  0 1  0 0*Root Hub	  Y   9   0   0
     Intel Corp
---- ---- ---- --- --- --- - --- --- - ---- -  - - -------------- - --- --- ---
  2R 413C 2003	 0   0	 0 Y 1.1   1 2	 70 1  0 0*Keyboard	  .   3   1   1
     Dell Computer Corp

program drives.com vypíše informace DOSových discích, irq.com vypíše přehled obsazených-volných přerušení, vendorid.com je databáze výrobců PCI a USB zařízení, scantest.com zobrazí scankódy kláves, atd... Samotné high-level drivery také poskytnou spoustu velice detailních informací o daných zařízeních (viz. např. usbkeyb.txt).
      Pokud máte novější chipset s podporou USB 2.0 je potřeba daná zařízení připojit na porty UHCI řadiče (USB 1.1) nikoliv EHCI. Já jsem to prostě vyzkoušel metodou pokus/omyl, jinak viz manuál k základní desce. Úspěšně jsem otestoval USB klávesnici (lze připojit až 4 naráz + 1 PS/2), USB myš (lze připojit až 8 naráz + 1 PS/2) a USB čtečku paměťových karet. Rychlost kopírování je ale nízká, takže radši doporučuji USBMASS/386 4.05 s podporou USB 2.0. Ovladač USB myši funguje jako emulátor PS/2 myši, takže po něm je potřeba ještě zavést klasický myší ovladač (např. CuteMouse nebo Microsoft Mouse). Ovladače fungují i v PMode programech jako třeba 3D Studio, zatím jsem se nesetkal s žádnou nestabilitou. Je skvělé, že vznikla tato sada ovladačů, která se nezaměřuje jen na Mass-Storage ale i na HID zařízení, což doposud v DOSu chybělo (USB legacy podpora v BIOSu totiž nemusí být vždy samozřejmostí, viz např. thin client Compaq EVO T20, bohužel zatím chybí podpora OHCI).

      27.12.2010 se na BTTR fóru objevila zmínka o zbrusu novém USB Mass-Storage Class ovladači USBexFAT 1.00 [27 kB] pro DOS (původem z čínské stránky China DOS Union). Tento driver je výjimečný tím, že kromě standardních souborových systémů FAT16 a FAT32 podporuje také nový 64-bitový souborový systém ExFAT, který je nativně podporován v Micro$oft Windows CE 6.0, Windows Vista SP1, Windows 7 a Windows Server 2008. Do Windows XP je potřeba nainstalovat hotfix KB955704. Pro DOS je k dispozici zatím jen alfa verze ExFAT knihovny, která se možná časem integruje do jádra FreeDOSu. USBexFAT driver také podporuje rychlý přenos USB 2.0 high-speed, přičemž u mě na ICH7 EHCI je rychlost zhruba srovnatelná jako ve Windows. Bohužel nepodporuje USB Composite Devices, takže mi nefungoval s mojí novou čtečkou paměťových + ISO Smart karet od MSI, ale jen s USB klíčenkou. Balíček obsahuje soubory usbaspi.sys, což je USB ASPI driver, který lze zavádět z config.sys nebo dynamicky a rezidentní část usbexfat.com, která se zavede z autoexec.bat nebo dynamicky po zavedení usbaspi.sys. Pomocí parametru /D lze přiřadit první písmeno USB jednotky, jinak je určeno automaticky.
      5.1.2011 Do nové verze 1.0a z 2.1.2011 byla přidána podpora USB floppy. Testoval jsem s mechanikou SONY MPF820U, která sice byla rozpoznána, ale jednotce nebylo přiřazeno písmeno s chybou:

USBexFAT ASPI DISK DRIVER Ver 1.0a. FANJIANYE create in 2011/01/02	     
									     
ID:LUN=0:0= HD .. SONY	  USB-FDU					     
Read error in partition read.						     
...
Not found installable device.

DOS a WIN32 aplikace
      Hodilo by se vám občas v DOSu spustit nějakou Win32 aplikaci? S HX DOS Extenderem není nic nemožné! Projekt je určen primárně pro podporu konzolových aplikací, ale poradí si i s některými grafickými programy využívající GDI/DirectDraw/SDL/OpenGL. Grafika je softwarově emulovaná a vykresluje přes VESA 2.0+ LFB (autorovi jsem poradil, aby nastavil MTRR registry - od verze 1.40). Samozřejmostí je podpora myši a byla přidána i podpora zvuku (zvuková karta musí být SB16 kompatabilní s DPS 4.0 a výše).
      Zprovoznění HX DOS Extenderu je celkem snadné. Po vybalení binárek do nějakého adresáře stačí doplnit systémovou proměnnou PATH, případně ještě přidat cestu k windousím DLLkám, aby je program našel. Pak už se jen spustí hxldr32.exe, což je rezident, který hlídá zda-li spouštíte DOSové programy nebo windowsové. Pokud spustíte windowsový program, rezident to rozpozná a použije dpmild32.exe pro načtení Win32 PE exe souboru nebo dpmild16.exe pro načtení Win16 NE exe. O další se už postará HX runtime. V případě, že program vyžaduje zatím nepodporované API funkce, tak skončí s výpisem. Další možností jak programy spouštět je použít utility pestub.exe, která nahradí stub windowsího programu za nový, který umožní jak běh ve Windows, tak s HX DOS Extenderem a to bez rezidentu. Ještě dodám, že HX DOS Extender se nemá rád s QEMM386, ale s EMM386 běží.
      Zatím se mi podařilo rozběhnout třeba LAME 3.97 MP3 enkodér nebo některé části AVR-GCC a MinGW32. Jako třešničku na dortu bych zmínil 3D střílečku Quake II, která běží se zvukem (na mojí SB Live 1024) a přes software render v 800x600 při nějakých 55 FPS.

DOS a sítě
      DOS neměl nikdy ambice stát se plnohodnotným síťovým OS jako např. Linux, ale celkem často se používal jako klient sítí Micro$oft Network a Novell Netware. Starší sítě Novellu fungovaly na protokolu IPX, který adoptovaly i DOSové programy, např. řada her tak umožňovala hru po síti. Stále mám v paměti primitivní, ale velice zábavnou střílečku NetWars, kterou jsme hrávali na SPŠE na 386-tkách. Pokud si chcete zahrát s kamarádem u druhého počítače, bohatě vám postačí křížený kabel a Novell Personal Netware, jenž je součástí DR-DOSu (funguje i pod jinou verzí DOSu). Personal Netware dále umožňuje sdílet disky a tisknout na vzdáleném počítači. Nutnou podmínkou pro běh je ODI ovladač pro vaši síťovou kartu. Pokud máte jiný typ DOSového ovladače, např. Packet Driver, lze si pomoci některým z wrapperů, který překládá volání jednoho API na jiné.
      Pokud se potřebujete dostat i na Internet, musíte mít podporu pro TCP/IP protokol, tzv. TCP/IP stack. Existuje několik verzí, zde: http://www.netbootdisk.com je volně ke stažení velice kompaktní (na jednu 1,44MB disketu) verze založená na M$ Network. Obsahuje řadu NDIS ovladačů i pro moderní síťové karty (byl tam i pro můj 1 GBit Marvell Yukon) a dokonce systém autodetekce PCI síťových karet alá Plug and Pray :). Po nabootování DOSu (není součástí distribuce) a rozbalení souborů do ramdisku se spustí program pciscan.exe, který prozkoumá všechny adaptéry na PCI sběrnici a podle seznamu PCI vendor ID a device ID v souboru ndis.map určí o jaký typ síťovky jde a nastaví systémovou proměnnou PCI0. Pokud byla nalezena známá karta, modifikuje se konfigurační soubor protocol.ini, do nějž se vloží jméno síťovky (DriverName = yuknd$). Následně se zavede odpovídající NDIS ovladač a jádro sítě (net.exe, tcptsr.exe), viz startnet.bat a nakonec se síť automaticky nakonfiguruje přes DHCP (je možno zadat i pevné IP adresy).
      Od této chvíle lze spustit jakýkoliv program s vestavěnou podporou TCP/IP. Jen upozorňuju, že rezidentní síť zblajzne kvanta konvenční paměti, což může některým programům způsobit problémy a bude to chtít poladit správce paměti. Na prohlížení webu a poštu můžete použít grafický 16-bitový prohlížeč Arachne (zde je moje aktualizovaná verze 1.95a s podporou HiColor videomódů 1280x1024 a 1600x1200, včetně zdrojových kódů - tento hotfix byl též zahrnut do nově vydané verze 1.97 a zde je pro něj spousta plug-inů) nebo 32-bitový DR-WebSpyder, popř. textový DosLynx či vylepšený Links 2.8 známý z Linuxu, který umí textový i grafický režim.
      15.11.2011 Georg Potthast a Benjamin Johnson vypustili první testovací verzi DOSového portu malého portabilního webového prohlížeče Dillo založeného na knihovně FLTK. Zde je ke stažení verze pro DOS a Windows. DOSová verze je kompilovaná v DJGPP a používá TCP/IP knihovnu WatTCP32. V dávkovém souboru dillo.bat je třeba upravit cesty, aby odpovídaly aktuálnímu umístění adresáře. Nenechte se zmást přenastavením proměnné prostředí TEMP do adresáře programu - v současnosti je to potřeba pro korektní funkci. Doporučuji na konec dávkového souboru přidat řádek, který nastaví proměnnou TEMP zpět na původní cestu. Prohlížeč mi fungoval na první pokus, lze s ním prohlížet i složitější weby, ale jsou zde jistá omezení, jako že nejde otevřít lokální soubor, nejde stahovat soubory na disk, není zatím podpora skrolování okna kolečkem myši a také mi program občas náhle spadnul. Ale je potřeba brát ohled na to, že je to zatím první testovací verze, která přinesla mezi 10 let staré DOSové prohlížeče tolik potřebné oživení.
      Další verze Dillo pro DOS z 28.11.2011 už umožňuje stahování souborů na disk a otvírání offline souborů. Akorát dialog pro otevření souboru ještě nefunguje správně, takže je potřeba zapsat cestu k souboru buď při spuštění jako parametr do příkazové řádky nebo po spuštění do adresního řádku prohlížeče. Také přibyla podpora české diakritiky.
      5.5.2012 Georg Potthast vydal ke stažení DOSový port grafického textového editoru FlWriter 1.1, který využívá taktéž knihoven FLTK jako Dillo. Umožňuje export dokumentů do PDF a tisk na některých postscriptových tiskárnách.
      Další verze Dillo 3.0.2 pro DOS z 17.3.2013 opravuje dialog procházení lokálních souborů, takže už je možné bez problémů prohlížet html soubory offline. Dále přináší podporu SSL, stahování souborů z FTP a tisk webových stránek do postskriptu.
      16.8.2013 Georg Potthast vydal první verzi grafického e-mailového klienta FlMail s podporou SSL/TLS pro SMTP a POP servery. Lze nakonfigurovat více e-mailových účtů. Maily se zobrazují textově či v jednoduchém HTML a na disk se ukládají v obou formátech.
      Na online pokec poslouží klienti LSICQ a Toffee IRC. Počítač můžete ovládat na dálku skrze DOSVNC nebo z něj udělat WWW server - projekt EZ-NOS. Dále existuje řada portů standardních linuxových utilit jako třeba WGET 1.8.2, TELNET, SSH, SCP, SFTP. Určitě taky příde vhod síťová podpora v programu Norton Ghost, když si chcete uložit nebo natáhnout image disku ze sítě. Pokud chcete naprogramovat vlastní síťovou aplikaci, pak je tu 16/32-bitová knihovna Waterloo WatTCP (použitelná i pro DJGPP). V současnosti je už zastaralá a tak raději doporučím moderní 16/32-bitovou knihovnu SwsSock pro Open Watcom, MSVC, DJGPP, MinGW32 a Linux. V současnosti ji využívá např. přehrávač MPXPlay.

Arachne screenshot

Links screenshot

Dillo screenshot

DOS a multimédia
      Pro DOS existují tuny multimediálního software, bohužel v drtivé většině jde o zastaralý, dávno zapomenutý software, kterému chybí podpora nových formátů a nebo nového hardware. Proto bych zde zmínil pár projektů, které jsou dosud živoucí a snad ještě dlouho budou.
      Pro přehrávání hudebních souborů je dnes bezkonkurenčně nejlepší opensource (Open Watcom C) program MPXPlay od maďarů PDSoft, který jsem už zmiňoval na stránce o mojem hardwarovém přehrávači. Poradí si s hudebními formáty: AAC, AC3, APE, FLAC, MP2/MP3, MPC, OGG/VORBIS, OGG/OPUS, WAV, WMA, WV, pomocí pluginu IN_MOD.DLL také MOD, XM, S3M, IT a také zvukovou stopou video souborů: ASF, WMA, WMV, AVI, MP4 (M4A) a samozřejmě několika formáty playlistů. Také umí přehrávat CDDA digitální cestou - grabbuje s posílá vzorky přes IDE. Díky ruční optimalizaci kritických částí v assembleru má velmi malé nároky na systém, na méně složité formáty postačí i 486DX/4-100 se 4 MB RAM. Ovládání je plně konfigurovatelné a lze využívat kromě klávesnice, myši a joysticku také IR přijímač dálkového ovládání. Výstup lze nasměrovat také na alfanumerický LCD displej připojený k LPT. Nechybí podpora dlouhých názvů (při čtení z disku), pokud je zaveden příslušný ovladač, např. DOSLFN. Velmi důležitá je podpora zvukových karet. MPXPlay obsahuje několik vestavěných ovladačů, které podporují kromě klasiky SB16/Pro, ESS, WSS a GUSe také moderní zvukovky SB Live!, Audigy 1/2/4, CMI, VIA a Intel HDA (High Definition Audio). Jinak spolupracuje i se staršími DOSovými ovladači. V novější verzi je též podpora sítě, takže lze přehrávat i soubory z FTP serveru. Ve verzi 1.60 alpha 2 přibyla navíc podpora HTTP streamingu, tedy možnost poslouchat internetová rádia. MP3 pro přehrávání si můžete vyrobit pomocí DOSového portu enkodéru LAME.
      Programátory by mohla zaujmout opensource zvuková knihovna JUDAS 2.10a Apocalyptic Softwaremixing Soundsystem určená pro 32-bitové překladače DJGPP a Watcom C / Open Watcom. Zajímavá je zejména podporou nových zvukovek standardu AC'97 a HDA (intel High Definition Audio), což bylo v DOSu potřeba jako sůl. Knihovna umí přehrávat zvukové soubory XM, S3M, MOD a WAV. Součástí balíčku je i jednoduchý přehrávač výše zmíněných souborů Judas Player. Pokud se má inicializovat zvukovka typu AC'97 nebo HDA, nesmí být nastavená proměnná prostředí BLASTER, jinak se pokusí inicializovat Sound Blaster. Já jsem provedl drobnou úpravu zdrojových kódů a makefile tak, aby byla možná kompilace poslední verzí GCC 4.6.2., ke stažení zde. Úspěšně jsem otestoval zvuk na své desce s integrovaným HDA intel ICH7 + ALC888.
      Pro přehrávání videa existuje komerční program QuickView Pro od MultiMediaWare, který zvládne i MOV, MPEG2 a MPEG4. Umí také běžné hudební soubory MPx, OGG, WAV a obrázky. Pro grafický výstup podporuje VESA VBE 2.0 a pro zvukovky používá buď DOSové ovladače nebo nativní plug-iny, kde nechybí podpora SB Live! Ovládá se přes textové rozhraní s menu.
      Před nedávnem se také objevila opensource alternativa v podobě DOS/DJGPP portu multimediálního přehrávače MPlayer známého především z Linuxu od Michaela Kostyleva. MPlayer obsahuje spoustu vlastních kodeků pro audio a video soubory. Pro grafický výstup podporuje VESA VBE 2.0 a CVidix. Vidix umí využít HW akcelerace pro YUV-RGB transformace a používá DMA pro kopírování framebufferu, takže přehrávání je naprosto plynulé. Bohužel nové VGA nVidie (např. GF7600GS) i ATI už CVidix nepodporují (chybí overlay). Úspěšně jsem CVidix otestoval na svojem postarším notebooku vybaveným ATI Radeon Mobility 32 MB AGP a Pentium III 1,2 GHz. Zatím co VESA driver dost cukal, přes CVidix to jelo krásně plynule. Zvukový výstup bohužel spoléhá jen na knihovnu Allegro, takže zvuk na SB Live! mi nefunguje (ani s DOSovými drivery - problém MB / chipsetu). Zde je novější verze od Khusrawa.
      22.1.2012 Khusraw zkompiloval novou verzi MPlayeru 1.0rc4 SVN-r34587 pro DOS s podporou zvukového výstupu také přes kodeky AC'97 a HD Audio. HDA driver byl přenesen z výše zmiňované knihovny JUDAS 2.10d do knihovny WSS použité v MPlayeru. Také je zakompilovaná podpora pro externí binární kodeky a síť přes WatTCP32. MPlayer je pro maximální úsporu místa zkomprimovaný UPX s parametrem --lzma, pokud se na pomalejším PC dlouho spouští, doporučuji soubor dekomprimovat příkazem upx -d mplayer.exe a znovu zkomprimovat příkazem upx --best mplayer.exe. Velikost se zvětší asi o 1 MB, ale rychlost runtime dekomprese se zvýší asi 5x. Při prvním spuštění vytvoří MPlayer ve svém adresáři podadresář mplayer s prázdným souborem config. Zde si můžete stáhnout můj konfigurák.
      Pro kompresi a mux/demux video souborů si můžete stáhnout mé DOSové porty programů FFMPEG 0.9.1 a x264 0.120. Kvůli problémům při překladu jsem vypnul optimalizace SSE a vyšší, takže se využívají pouze instrukce FPU a MMX. Kompletní balík upravených a zkonfigurovaných zdrojáků s knihovnami a binárkami jsem uploadnul na SourceForge.
      Pro prohlížení obrázků bych ještě zmínil dva staré, ale hodně kvalitní programy SEA 1.3 a QPV/386 1.7c. Oba podporují VESA VBE 2.0 a mají pěkné grafické rozhraní. V současnosti nevím o žádném podobném živém projektu. PDFka a PS/EPS lze prohlížet v portu Ghostscriptu od Michaela Kostyleva, ale nečekejte žádný komfort ovládání. Nicméně na rychlé prolistování to stačí.

(nejen) DOS a diskety
      Diskety byly na počátku historie IBM PC jediným cenově dostupným trvalým úložištěm dat. A to nejen pro přenosy, ale i jako primární médium pro OS a aplikace. Pevné disky byly velmi drahé a měly kapacitu jen pár desítek MB, takže se neosazovaly běžně do každého PC. Diskety pak sloužily na PC pro přenos dat min. dalších 25 let. Už od počátku se jednalo o médium poměrně nespolehlivé a netrvanlivé, což se za celou éru moc nezlepšilo. Komu z vás se někdy nestalo, že by při dekompresi či kopírování archivu z více disket nenarazil na chybu čtení (nejlépe až na té poslední disketě)?
      Diskety už dnes používá málo kdo (nové základní desky ani nemají FDC), přesto se občas může odněkud vynořit zapomenutá a nezálohovaná disketa, kterou bychom rádi přečetli. Magnetický záznam však časem chátrá a tak pokus o čtení dost často končí neúspěchem. Nedávno jsem objevil zajímavé udělátko Project Kryoflux, které může být schopno přečíst i běžně nečitelné diskety. Jedná se v podstatě o softwarovou implementaci FDC s USB rozhraním, ke kterému se připojí běžná disketová mechanika (je dobré, pokud máte k dispozici, vyzkoušet více mechanik, která nejlépe čte) a umožňuje vzorkovat průběh magnetického toku z hlav. Navzorkovaný záznam se pak softwarově dekóduje podle pravidel specifického formátu a modulace. Díky tomu si poradí i s disketami z Apple, Amigy, Atari, atd., či s různými ochranami proti kopírování. Některé by nebylo možné kvůli jinému typu modulace vůbec standardním HW FDC přečíst. Také je možné s některými mechanikami číst data ze skrytých stop (80 a výše), kde se typicky nalézají různá tovární data z duplikačních mašin včetně timestampu formátování, která nejsou při běžném používání v PC nijak dotčena. Avšak není to zrovna levná sranda pro občasné použití, základní varianta vyjde na 95 euro, spíše vhodné pro nějaký historický computer klub, kde se na to složí a využije více lidí. Nicméně velmi oceňuju snahu o záchranu digitálního dědictví...
      Pokud máte stále v provozu nějaký stroj s disketovou jednotkou, kde není možno přidat třeba USB řadič na flash disky, existuje dnes řešení v podobě floppy disk emulátorů. Ten se zapojí na kabel místo klasické disketovky a strčí se do něj USB klíčenka nebo paměťová karta. Na flešku lze uložit desítky až stovky image disket, mezi nimiž lze snadno přepínat tlačítky. V PC lze pak všechny image najednou přečíst nebo zapsat. Ale pozor na kompatabilitu, některé emulátory podporují pouze 1,44MB HD nebo 720kB DD formáty.

Tux   DOS Navigator pro Linux
      Ne, nejsem ignorant Linuxu, jen si myslím, že psaní na toto téma by bylo jen nošení dříví do lesa, navíc by mě měla linuxová L33t za n00ba a l00$3ra /etc... Jen dodám, že jsem za ňákých 12 let vyzkoušel desítky různých distribucí (od všelijakých jedno [či dvou] disketovek, přes mini-distribuce a live CD až po několik velkých systémů), začínal jsem s Monkey Linuxem na UMSDOS FS a skončil u Debian GNU/Linux, který se tak nějak blíží mým představám. Linux nepoužívám na běžnou práci (nedostatek alternativ k řadě windowsích aplikací), ale jen občas, spíše na různé experimenty.
      Docela mě překvapilo, že pro Linux existuje v podstatě jen jediný souborový NC-like manažer (nepočítám tedy ty "průzkumníky" pro Xka) - Midnight Commander, zatím co pro DOS jich jsou mraky - od minimalistického Mikro Manažeru [12 kB] pro komplexní DOS Navigator. MC mi k srdci zrovna moc nepřirostl, i když pořád lepší než drátem do oka. Říkal jsem si už dávno, kdyby tak někdo naportoval DOS Navigátora do Linuxu, a ono se tak stalo - Necromancer's DOS Navigator 2.15. Bude ještě potřebovat hodně věcí vychytat, nicméně je celkem použitelný. Stačí stáhnout, rozbalit někam binárky a vyzkoušet. V mojem systému šel spustit normálně, dokonce žádná knihovna nechyběla. A takhle to vypadá:

Necromancer's DOS Navigator 2.15

      15.2.2012 Pro X-Windows jsem objevil celkem použitelný 2-panelový manažer Double Commander, který je k dispozici pro Linux a Windows 2000/XP/Vista/7. Je zajímavý tím, že podporuje plug-iny populárního Total Commanderu. Graficky není tak vychytaný jako třeba český Servant Salamander (chybí např. automatické nastavení šířky sloupců v panelech nebo příliš plýtvá místem v horních toolbarech). Více si o něm můžete přečíst v seriálu na rootu. Jak jsem zjistil, není to jediný dvoupanelový manažer pro Linux, viz další díly seriálu.

Spouštění Linuxu z DOSu (pro nová jádra >2.6.22)
      Dlouhá léta jsem spokojeně používal ke spouštění Linuxu DOSový program LoadLin, protože DOS mám na disku stále a není tak potřeba zasahovat do MBR či bootsektoru a lze snadno měnit konfiguraci jádra. Avšak když jsem chtěl přejít na nové jádro 2.6.26, došlo při bootu k havárii. LoadLin (včetně poslední verze 1.6d) stihl vypsat pouze průběh dekomprese image jádra a ramdisku (běžící tečky) a pak hned následoval restart PC. Napřed jsem myslel, že se jádro špatně zkompilovalo, ale binární balík z webu Debianu dělal totéž. Pak jsem vygooglil, že se jedná o chybu LoadLinu, který má problémy s novými jádry >2.6.22. Řešení je použít alternativní program linld.com, který se volá podobně, např.:
linld image=VMLINUZ2.632 initrd=INITRD2.632 "cl=root=/dev/sda3 ro vga=4 pci=nomsi"
do parametru cl= se zapisují startovací parametry jádra.
      Později jsem se dozvěděl, že chyba LoadLinu byla odstraněna v nové verzi 1.6e, ke stažení zde. Jak jsem ale následně vyzkoušel, nová verze funguje jen s jádry 2.6.xx a u 3.x.x byl problém s restartem zpět. Takže doporučuji zůstat u linld.

Debian Wheezy a binární ovladače od nVidie
      1.7.2012 Po delší době jsem se odhodlal upgradovat svoji instalaci Debian Linuxu. Aby to na nějakou dobu zas vydrželo, přešel jsem od Lennyho (v té době testing) rovnou k Wheezy (aktuální testing). Protože apt-get dist-upgrade to moc nerozchodil, zazálohoval jsem data a pustil se do čisté instalace z NetInst CDčka debian-wheezy-DI-a1-i386-netinst.iso. Instalace proběhla sice hladce, ale po restartu jsem zjistil drobné poškození partition tabulky, které způsobilo nepřístupnost oddílů v extended partition, protože instalátor nějakou záhadou rozmrdal CHS adresy oddílů, zatímco LBA hodnoty zůstaly v pořádku. To jsem celkem snadno s pomocí PQMagicu opravil a o žádná data nepřišel. Přitom jsem při instalaci neprováděl žádnou manipulaci s oddíly, pouze jsem přiřadil existujícímu oddílu /dev/sda4 mountpoint na root bez formátování oddílu (předchozí instalaci jsem předem ručně odklidil do jiného adresáře) a swap oddíl jsem nechal tak jak byl. No budiž, jedeme dál, na takovéhle legrácky jsem už zvyklý od nenechavých instalátorů Windows.
      To nejhorší mě ale teprve čekalo. Po instalaci aplikací, Xorg a kompilaci vlastního jádra 3.4.4 (bez nouveau) přišla na řadu instalace binárního ovladače nVidie NVIDIA-Linux-x86-295.59.run. Doposud jsem byl s ovladači od nVidie maximálně spokojený a považoval proto nVidia karty pro Linux za jediné rozumné řešení, takže jsem to bral za rutinu. Instalace s kompilací jaderného modulu proběhla v pořádku a nechal jsem vytvořit nový xorg.conf. Avšak po startx mě čekalo nemilé překvapení v podobě černé obrazovky, kdy systém nereagoval na klávesy. Jedinou rozumnou možností bylo zkusit zmáčknout ATX power tlačítko, na které systém zareagoval standardní vypínací sekvencí a po pár vteřinách chroupání disku se korektně vypnul. V logu /var/log/Xorg.0.log jsem pak našel poslední řádek "Initializing extension GLX". Myslel jsem, že problém bude nejspíš v mojem customicovaném kernelu, takže jsem se vrátil zpět k distribuční verzi 3.2.0, přeinstaloval ovladač ale pořád to nefungovalo. Zkusil jsem pro jistotu ještě starší verzi NVIDIA-Linux-x86-173.14.35-pkg1.run a nejnovější verzi NVIDIA-Linux-x86-302.17.run, ale bez úspěchu. Začal jsem tedy hledat na Internetu a zjistil, že stejný problém má na Wheezy řada lidí. V diskuzích bylo většinou odkazováno na instalaci driverů z DEB balíčků hlavního repozitáře a někomu to snad zabralo, ale mě ne.
      Když už jsem ztrácel naději, našel jsem vysvětlení na českém Debian fóru. Uživatel Antonín Mička popisuje, že se mu funkční nVidia ovladače rozbily až po upgradu libc6 z verze 2.13-27 na 2.13-30. V mojí instalaci Wheezy byla přitom verze 2.13-33, takže konečně relevantní stopa. Stáhl jsem si tedy balíčky:
libc6_2.13-27_i386.deb
libc6-dev_2.13-27_i386.deb
libc6-i686_2.13-27_i386.deb
libc-bin_2.13-27_i386.deb
libc-dev-bin_2.13-27_i386.deb
z archivu a nainstaloval je natvrdo pomocí dpkg --force-all -i *.deb a sláva, Xorg se spustil v plné kráse, 3D akcelerace valí jako drak. Zkusil jsem schválně ještě nejnovější libc6 verze 2.13-34, ale nefungovalo to. Opětovnou instalací verze 2.13-27 zas OK. Abych zabránil automatické aktualizaci libc6, přidal jsem pro tyto balíky výjimku. Nejprve jsem si uložil pravidla pro všechny balíčky do souboru příkazem dpkg --get-selections \* >/pklist, pak jsem v textovém souboru u výše zmíněných balíku přepsal hodnotu "install" na "hold":

libc-bin               hold
libc-dev-bin           hold
libc6:i386             hold
libc6-dev              hold
libc6-i686:i386        hold

a nakonec importoval zpět příkazem dpkg --set-selections </pklist. Není to zrovna ideální způsob, protože aktualizace libc můžou být docela důležité, ale aspoň že to funguje a časem se to snad nějak vyřeší.
      23.12.2013 Jak jsem později zjistil, instalace binárního balíčku ovladače od nVidie do Debianu není zrovna moudrá volba a je lepší nainstalovat debianí balíčky využívající systém DKMS (kernel modul se dynamicky kompiluje při aktualizaci jádra i s potřebnými úpravami pro adaptaci na rozdíly v hlavičkových souborech jádra): apt-get install dkms, apt-get install nvidia-legacy-304xx-driver. Pokud by se to při aktualizaci jádra nechytlo korektně, zkus vynutit přeložení kernel modulu pomocí dpkg-reconfigure nvidia-legacy-304xx-kernel-dkms. Mezitím jsem upgradoval svoji distribuci Debian Wheezy na Jessie (testing) s vlastním přeloženým jádrem 3.12.6 z debianího zdrojového balíčku a spolu s balíčky nVidia ovladače verze 304.116 vše funguje jak má.
      Další věc, kterou jsem musel poladit, bylo pořadí detekce zvukových karet v systému ALSA. Jako primární kartu jsem chtěl mít SB Audigy 2 a jako sekundární intel HDA. Jelikož ve Wheezy z nějakého důvodu chybí konfigurační nástroj alsaconf, musel jsem to nastavit ručně editací souboru /etc/modprobe.d/alsa-base.conf, kam jsem přidal řádky:
# Set SB Audigy as default soundcard (index 0)
options snd-emu10k1 index=0
options snd_hda_intel index=1
Změna se projeví až po restartu, výsledek po výpisu cat /proc/asound/cards by měl nyní vypadat takto:

0 [Audigy2]: Audigy2 - SB Audigy 2 Platinum [SB0240P]
             SB Audigy 2 Platinum [SB0240P] (rev.4, serial:0x10021102) at 0xd000, irq 18
1 [Intel  ]: HDA-Intel - HDA Intel
             HDA Intel at 0xf9100000 irq 44
2 [SAA7134]: SAA7134 - SAA7134
             saa7133[0] at 0xf9005000 irq 20

Takže po příjemně prožitém bezesném instalačním víkendu je systém zas celkem v provozuschopném stavu. Místo těžkopádného KDE 4, které hýřící grafikou a pomalostí předčí snad i Windows Vista, jsem přešel na lehčí Xfce a zatím spokojenost. Ještě zbývá vyřešit menší problém s hodinami (ačkoliv jsem při instalaci vybral, že RTC neběží v UTC, jdou mi o 2 hodiny napřed) a s instalací VMware, kde to bude chtít asi upgrade kvůli 3.x.x jádru...
      Problém s kompilací kernel modulů VMware jsem celkem snadno vyřešil pomocí tohoto patche pro 3.4.x jádro (zde je verze pro 3.2.x jádro). V souboru patch-modules_3.4.0.sh je akorát potřeba přepsat správnou verzi instalovaného VMware (řádky vmreqver=8.0.4 a plreqver=4.0.4). Problém s časovým posunem jsem spravil úpravou souboru etc/adjtime, kde jsem na 3. řádku přepsal "UTC" na "LOCAL". Nastavení v etc/default/rcS nemá efekt (je zastaralé). Při upgrade na VMware 10.0.1 jsem potřeboval do konfigurace jádra zahrnout všechny moduly týkající se VMware, jinak si je sám nepřeložil a nenačetl:

Networking support > Networking options: <M> VMware VMCI transport for Virtual Sockets (CONFIG_VMWARE_VMCI_VSOCKETS=m)
Device Drivers > Misc devices: <M> VMware VMCI Driver (CONFIG_VMWARE_VMCI=m)
Device Drivers > Network device support: <M> VMware VMXNET3 ethernet driver (CONFIG_VMXNET3=m)


QNX logo   A teď systém z trochu jiného soudku. QNX je realtime 32-bitový operační systém na bázi Unixu, splňuje normu Posix. Poprvé jsem se s ním setkal už někdy před třemi lety, kdy mi kamarád Zdeněk nahrál QNX demodisk. Jedná se o minidistribuci QNX na jednu 1.44MB disketu určenou pro rychlé připojení k Internetu na počítačích nejen bez odpovídajícího softwaru ale i bez operačního systému. Jednoduše vložíte disketu do mechaniky a resetujete, loader načte image do RAM a rozbalí - dále už nebude disketa potřeba. Po detekci/ručním vybrání modemu/síťové karty (jedna varianta demodisku je pro modemy, druhá pro síťovky) naběhne pěkně zpracované Photon micro GUI (okenní systém podobný W95 či Xkám). Nakonec je ještě třeba spustit Internet connection wizarda, kde zadáte číslo ISP, DNS adresy, typ logování a můžete se připojit. Systém obsahuje Voyager web browser, telnet, textový editor, prohlížeč souborů a pár jednoduchých her.
Pokud jste připojeni, můžete si z domovské stránky QNXu stáhnout i různé pluginy. Jedinou a to podstatnou nevýhodou je absence nějakého diskového filesystému a tak nelze data ukládat. Po vypnutí se všechna data a nastavení ztratí.
      Nicméně je to sqelá věc když vám lehnou wokna a nemáte chuť do instalace, ale potřebujete vybrat/poslat nějakou poštu. Nejvíc mě však fascinuje, jak dostali takový systém na jedinou disketu. Systémové nároky také nejsou nijak velké, bohatě by měla stačit 486 s 8 MB RAM. To je panečku jiná efektivita programování, o tom si můžou windows nechat zdát.
      QNX byl dříve poměrně drahý OS, avšak letos v zimě vyšla první verze celého systému zdarma. Nyní je již ke stažení třetí free verze. Na http://www.getqnx.com je ke stažení buď kompletní ISO image bootovacího CD (asi 400 MB) nebo okrouhaná verze pro instalaci z windows (25MB exáč). Instaluje se buď na vlastní partition se svým filesystémem, nebo na FAT oddíl, jako jeden veliký soubor - ten se pak bootuje driverem z config.sys. Systém dále podporuje filesystémy FAT, VFAT, EXT2. Plná verze obsahuje systém QNX 4, GUI, browser, mailer, filemanager, media player, texťák, překladač gcc a spoustu vývojářských utilit. Dokonce už je i port DOOMa pro QNX.
      Co se týče ovladačů, tak jsem neměl problémy. Systém v pohodě našel zvukovku SB-Live! a poradil si i s nVidia TNT2. Systém však nepodporuje 3D akceleraci, ale čekám že bude implementováno OpenGL nebo MesaGL.


AtheOS logo   Včera se mi dostal pod ruku další zajímavý systém o kterém byla zmínka v časopise Computer. Jedná se o GNU OpenSource operační systém na bázi Unixu splňující z větší části normu Posix, silně inspirovaný multimediálním systémem BeOS, který napsal mladý norský programátor Kurt Skauen v letech 1994 - 2002. Ve své době revoluční BeOS byl vytvořen v 90. letech malou firmou Be (tým odpadlíků od Apple), jenž později koupil Palm a projekt BeOS zlikvidoval. Dodnes však pokračuje jako OS HAIKU (dříve OpenBeOS). AtheOS má vlastní, od začátku naprogramované jádro s podporou SMP, vlastní jednoduché GUI a 64-bitový souborový systém. Umí pracovat i se souborovými systémy FAT+LFN, FAT32, Minix a EXT2.
      Problém je ovšem s programy a hardwarovou podporou. Systém je psán přímo pro pentium, takže na nižších stojích nelze vůbec spustit. Z grafických karet je podporována 2D akcelerace u Matroxů, nVidií a S3Virge, ostatní běží v režimu VESA 2.0. Disk je zatím ovládán přes BIOS. Síťové karty jedině NE2000 či RealTek RTL8129/8139. Podpora zvukových karet zatím žádná. Základní software tvoří klasické unixové utility, shell BASH, jednoduchý editor JED, EMACS, webový browser a pár drobností. Dále jsou k dispozici balíčky s upravenými GNU programy, jako GCC, NASM, binutils, Apache Server či Midnight Commander. Některé linuxové programy lze přeložit i bez modifikace.
      Instalace není zatím úplně jednoduchá. Zhruba se to stává z vytvoření 3 bootovacích disket, vytvoření a naformátování vlastního oddílu, rozbalení *.tgz, a konfigurace bootloaderu. Podrobnější popis zde. Avšak neměl jsem s tím problém. Více informací a download na: atheos.syllable.org

Syllable logo   AtheOS je už přes 10 let mrtvý systém, nicméně celá Kurtova práce nezmizela v propadlišti dějin. Už v roce 2002 skupina nadšenců do AtheOSu vytvořila fork Syllable, který existuje ve 2 verzích: Syllable Desktop s GUI a konzolový Syllable Server (ten je založený na Linuxu). Systém by měl být na dnešních PC velice hbitý, minimální požadavky pro Desktop jsou CPU Pentium s 32 MB RAM a pro Server CPU 486 s 16 MB RAM. Ke stažení jsou k dispozici ISO image live CD, instalačního CD a image pro VMware, poslední verze 0.6.7 je z 11.4.2012.


ReactOS logo   Projekt ReactOS si klade velice ambiciózní cíl - vytvořit OpenSource klon Windows NT/2k/XP, resp. být s nimi co nejvíce kompatabilní. Avšak cesta k tomuto cíli je dlouhá a trnitá, neboť WinAPI a další součásti Windows nejsou kompletně veřejně zdokumentované a některé části jsou chráněné patenty. Navíc Windows jsou uvnitř velmi složitý a nekonzistentní systém. Mnohem jednodušší FreeDOS není dodnes 100% kompatabilní s MS-DOSem, takže si troufám tvrdit, že ani ReactOS nikdy 100% nebude, pokud M$ neuvolní všechny specifikace či zdrojáky. I tak by to trvalo mnoho člověkolet a přitom vývoj Windows jde stále dál, vznikají nová API a technologie, staré postupně odumírají. Prostě pár desítek free programátorů nemůže udržet krok s tak velikou firmou s většinovým podílem na trhu. ReactOS tým též spolupracuje s linuxovým (ne)emulátorem Wine, se kterým sdílí většinu knihoven pro WinAPI.
      Pro běžnou použitelnost pro nenáročné uživatele nemusí být ReactOS 100% klonem. Někomu postačí, když v něm spustí M$ Office či účetnictví. Díky kompatabilitě ReactOS čerpá obrovskou výhodu z existující široké základny aplikací a ovladačů pro všemožný hardware. V něčem zas může být dodržování kompatability omezující. Během let jsem si uvědomil, že sebelepší OS (na klasickém PC pro univerzální použití) je jen nepoužitelná hračka, pokud nemá dostatečnou podporu HW a SW.
      Vývoj ReactOSu sleduju po očku už přes 10 let (historie zde). Poprvé jsem se setkal s verzí 0.0.21 v roce 2002, která se ještě startovala z DOSu a zabírala cca 10 MB, ale nenaběhla mi. Pak jsem si občas stáhl novou verzi (ISO image) na vyzkoušení, avšak též se mi ji nikdy nepodařilo spustit na reálném HW, pouze ve VMWare. Poslední alfa verze 0.3.15 vyšla v květnu 2013 (čerstvé SVN buildy zde). ReactOS nyní podporuje platformy x86-32, částečně x86-64 a ARM. Právě verze pro ARM by mohla být zajímavá, protože Windows RT pro ARM neumožňují spouštět klasické aplikace pro Windows x86. Konečně se mi podařilo nabootovat live CD (po odpojení USB čtečky karet, která zasekla USB driver). Spustil jsem i pár programů z disku jako třeba filemanager Servant Salamander nebo Quake II, fungovala i moje utilita CPUID včetně automatické instalace driveru. Hry využívající DirectX nebo HW OpenGL se mi spustit nepodařilo, protože na live CD je pouze neakcelerovaný VESA driver. NTVDM subsystém pro spouštění 16-bitových Windowsových a DOSových aplikací bohužel stále nefunguje.
      Dále jsem zkusil nabootovat instalační CD. Spustil se klasický modrý textový instalátor podobný Windows, kde jsem zvolil typ PC "ACPI PC Uniprocessor", rozložení klávesnice české QWERTY a videomód 1600 x 1200 / 32 bpp. Pak jsem vybral pro instalaci první primární FAT16 oddíl (bez formátování), kde mám DOS, Windows 98 SE a Windows NT 4.0. ReactOS lze nainstalovat i na oddíly FAT32 nebo EXT2, naopak chybí podpora NTFS. Pak proběhlo poměrně rychlé kopírování souborů z CD na disk, celkem 180 MB. Na závěr instalátor ohlásil, že nemůže nainstalovat zavaděč pro tento disk a že mám vložit naformátovanou disketu. To jsem udělal a instalátor tam cosi zapsal (DOS ani Windows na disketě nevidí validní souborový systém). Po restartu jsem zkoušel nabootovat z diskety, ale dostal jsem jen suchou hlášku, že systém nelze spustit. Instalace ve VMWare jako obvykle fungovala a tak jsem si zkopíroval bootloader freeldr.sys a konfigurák freeldr.ini, jenže mám jiný formát VM disku, takže image bootsektoru bootsect.ros jsem nemohl použít. Zkusil jsem tedy freeldr.sys načíst (po přejmenování na ntldr) standardním bootsektorem Windows XP a poté GRUBem (metodou chainloader), ale bez úspěchu (jen blikající kurzor). Na instalačním CD jsem v adresáři /loader našel jakousi šablonu bootsektoru fat.bin, kterou jsem se pokusil v hexaeditoru upravit po vzoru svého bootsektoru a načíst přes NT loader (přidán řádek C:\fat.bin="ReactOS" do boot.ini), ale ani tak se nezadařilo.
      Na ReactOS wiki jsem se dočetl, jak správně bootovat freeldr.sys GRUBem - nikoliv přes chainloader ale přes kernel (přidané řádky do menu.lst):
title ReactOS
root (hd0,0)
kernel /freeldr.sys
Po restartu pokračovala instalace v grafickém režimu, vyplnil jsem jméno uživatele a název PC a nastavil lokální parametry prostředí (překlad do češtiny je, ale chybí přednastavení pro český formát měny, času, data, atd.). V dalším kroku probíhalo registrování součástí, jenže když dojel progress bar nakonec, tak systém zatuhnul. Čekal jsem několik minut a nakonec musel klobnout do resetu. Jenže pak následovalo při kontrole disku dosti nemilé překvapení, neboť mi instalátor rozmrdal FATku tak, že jsem přišel o řadu souborů, které s ReactOSem vůbec nesouvisely a musel jsem je obnovit ze zálohy. Metodou pokus-omyl jsem pak zkoušel, která volba v nastavení instalátoru má na svědomí tyto potíže a po poměrně zdlouhavém testování jsem zjistil toto: Instalaci bylo možné dokončit při výběru angličtiny a pouze 1-jádrového procesoru. Dále jsem otestoval několik novějších denních buildů. Ve všech nefunguje podpora SMP, ale je možno nainstalovat systém v českém jazyce - za podmínky, že se nebudete vrtat do lokálních nastavení (ty lze snadno změnit po instalaci přes ovládací panely). Buildy 59039, 59065, 59131, 59206, 59259, 59272, 59286 (časové rozpětí 19.5. - 22.6.2013) vykazují chybu "DLL register failed..." při registraci součástí mshtml.dll, qmgr.dll a urlmon.dll, nicméně instalaci lze dokončit. Buildy 59311, 59329, 59337 (nejnovější v době testování z 25.6.2013) zas hlásí, že chybí komponenta Wine Gecko a jestli se má stáhnout z Internetu. Jelikož v této fázi jsem ještě logicky neměl nainstalovanou síťovku, tak tato možnost skončila zátuhem, ale dá se to přeskočit a pokračovat dál. Skončil jsem tedy u buildu 59337 v jednoprocesorovém režimu s nastavenou češtinou. Bohužel nějak nefunguje přepínání CZ/ENG rozložení klávesnice, přestože mám v ovládacích panelech nainstalované obě.
      Stejně jako u live CD dělá nainstalovanému ReactOSu potíže připojená USB čtečka karet nebo USB flash disk, kdy vytuhne s nějakou chybou USB řadiče. Pokud se USB flash připojí až po startu systému, tak je nalezená jako nový HW a chce ovladač, ale nevím jaký (Windows mají nativní Mass Storage Class driver). Systém startuje docela svižně, na mém SSD naběhne do plného desktopu za 5 s. Zkusil jsem nainstalovat ovladač pro svojí onboard síťovku Realtek RTL8111B. První pokus dopadl BSODem s jinou verzí ovladačů pro Windows XP se mi to povedlo rozběhnout. Nastavení sítě proběhlo automaticky přes DHCP. Pak je možno využít ReactOS Manažer aplikací, kterým lze stahovat a instalovat doplňky systému a free programy. Povedlo se mi úspěšně spustit tyto aplikace: Mozilla/SeaMonkey 2.0.14, M$ Word a Excel z Office 97, Servant Salamander 2.0, Total Commander 8.01, PC emulátor Bochs 2.6.2, emulátor DOSBox 0.74, Foxit Reader 2.3, Notepad++ 6.3.1 a Media Player Classic 6.4.9.1 (s výchozím VESA ovladačem nešlo přehrávat videa).
      Zkusil jsem také nainstalovat ReactOS na svém notebooku Compaq EVO N600c a na PC v práci (HP s intel Core i5-750), ale neúspěšně. Při bootu systém zatuhne během načítání ovladače floppy.sys. Patrně proto, že oba počítače nemají disketovou jednotku a driver se usilovně snaží o její inicializaci. Závěrem můžu říci, že ReactOS (pokud se ho vůbec podaří na daný PC nainstalovat) je použitelný pro nenáročné či občasné použití pro pár specifických aplikací, kde se nevyplatí kupovat Windows, ale v práci nebo doma bych si s ním rozhodně nevystačil. Čeká ho ještě cesta dlouhá a trnitá...
      3.7.2013 Pro zajímavost jsem ještě zkusil nainstalovat ReactOS (SVN build 59414 z 3.7.2013) na starém PC s Pentiem Pro na 200 MHz a 192 MB RAM. Tentokrát instalace (při dodržení zásad výše) proběhla bez problémů na existující FAT16 oddíl a instalátor korektně rozpoznal NTLDR dříve nainstalovaných Windows NT 4.0 a přidal korektně položku do bootmenu v boot.ini. ReactOS stejně jako WinNT nabootuje za 27 vteřin, po startu obsadí 79 MB RAM a samotný desktop vytěžuje CPU na 6%. Proti tomu WinNT (taktéž jen s VBEMP ovladačem VESA grafiky) obsadily 43 MB RAM a desktop vytěžoval CPU jen na 3%. Při práci to bylo docela znát, zatím co GUI WinNT běhalo plynule bez záseků, tak ReactOS každou chvíli někde drhnul. Nejhorší to bylo při spuštění ReactOS průzkumníka, tomu trvalo vykreslení každého řádku s jedním adresářem na disku snad vteřinu a přitom vytěžoval CPU na 100%. Myslel jsem si, že aspoň na starších PC by se mohl ReactOS dobře uplatnit, bohužel opak je pravdou. Staré Windows NT 4.0 nebo Windows 98 SE jsou zde mnohem použitelnější.


Calmira II pro Windows 3.x
      Možná si ještě vzpomínáte na staré Windows 3.11 a třeba je i používáte na nějakém starším PC či notebooku. Co ale s tím, když si člověk už navykl na komfortnější prostředí Win9X? (nebo KDE, Gnome...) Proto je zde Calmira II GUI - nadstavba pro Windows 3.11, která vám přinese desktop, taskbar, startnabídku a explorer z Win9X. Po rozbalení má asi 1,6 MB. Nové GUI lze během práce kdykoliv vypnout a znovu zapnout bez restartu. Tady je ukázka, myslím, že jim to docela sluší :). Více informací a download na: http://www.calmira.de

Windows 3.x a více jak 256 MB paměti
      Pokud byste si chtěli zavzpomínat u instalace stařičkých Windows 3.x, může vás na novějším PC s více jak 256 MB RAM čekat nemilé překvapení. Po úspěšné instalaci a zadání příkazu win systém jen suše zahlásí: "PageOverCommit value in SYSTEM.INI is too large. Decrease the value, or if not present, add a setting that is less than 4." a nespustí se. Problém je v tom, že Windows běžící v rozšířeném režimu 386 vypočítávají velikost stránkovacího souboru z velikosti RAM (přesněji XMS) a hodnoty PageOverCommit jako SwapSize = PageOverCommit * XMSSize, avšak zvládnou obsluhovat pouze stránkovací soubor do velikosti 1 GB. Implicitní hodnota PageOverCommit je 4, takže při velikosti nad 256 MB XMS dojde k překročení max. velikosti swapu. Náprava je velmi jednoduchá, stačí v souboru system.ini v adresáři Windows hodnotu této proměnné patřičně snížit na nebo ji nastavit na nulu:
[386Enh]
PageOverCommit=0
Další možnost je využít limitace starších správců XMS paměti (starší HIMEM - 64 MB, QEMM386 9.0 - 256 MB). Při tak veliké RAM je ale předpokládám swap soubor zbytečný.


Neoficiální servicepack pro Windows 98 SE CZ + univerzální USB driver.
      Náš milý Micro$oft už ňákou dobu 98čky nesupportuje, přesto je podle posledních statistik (léto 2005) používá stále asi 15% návštěvníků mojeho webu. Nedávno jsem na Hofy v jednom klubu kápnul na stránky http://winpack.org, kde si můžete stáhnout neoficiální servicepack (velikosti asi 15 MB). Ten obsahuje souhrn hotfixů, které oficiálně vydal M$, nové verze některých knihoven, některé převzaté z Windows (Fuck)ME a další drobná vylepšení. Před instalací doporučuju uložit si vlastní nastavení vzhledu windows, protože bude přepsáno tématem "Windows 2000" a knihovnu shell32.dll, pokud vám vadí šipky u ikon zástupců (s novou verzí knihovny je pak nelze přes registry vyzmizíkovat). Jinak jsem po instalaci SP spokojen, vše funguje tak jak má a doufám, že se budou objevovat další verze.
      Dále stojí za zmínku univerzální USB ovladač nUSB 3.3, který si můžete stáhnout zde. Ten by vám měl pomoci zvládnout nápor nových USB zařízení jako klíčenky (flashdisky), čtečky paměťových karet, dig. foťáky a pod. aniž byste museli pokaždé hledat nový ovladač. Od verze 3.0 navíc obsahuje ovladač rychlého USB 2.0. Já jsem jej úspěšně otestoval s noname čtečkou karet 7 in 1 a iPAQ h2210 s Card Export II 3.0. Nedávno jsem narazil na problém při připojení digitálního foťáku Panasonic Lumix DMC-FX550, kdy sice nUSB foťák korektně detekovalo a nainstalovalo jako USB Mass Storage Class zařízení, ale pak hned Windows vyplivly BSOD. Následně jsem si všiml, že na CD k foťáku je i driver pro Win9x. Když se napřed nainstaluje tento driver a pak teprv se připojí foťák, tak vše funguje jak má, funkci nUSB to nijak nenaruší.

Windows 98 (SE) a více jak 512 resp. 1024 MB paměti
      Asi pamatujete, jak na vás instalátor Windows 98 chrlil novinky nových windozů, jak všechno poběží mnohem lépe, rychleji a bezpečněji (za předpokladu, že investujete nějaký ten bakšiš do upgrade železa ;) a jak systém využije více a optimálněji váš počítač jako nikdy předtím. Později se však ukázalo, že tento OS je tak zabugovaný, že zdaleka není schopen plně využít možnosti 32-bit architektury x86, která dovoluje adresovat až 4 GB fyzické paměti. První problém nastává, pokud je v systému 512 - 1024 MB RAM. Instalace Windows se ani nedokončí a skončí po restartu v textovém režimu s paradoxní hláškou "insufficent memory" / "nedostatek paměti" :) Na vině je ovladač vcache, jehož buffer se vzhledem k velké RAM alokoval příliš veliký, více než mohl systém zvládnout. Zde je pomoc jednoduchá. Stačí nabootovat do DOSu a zeditovat soubor system.ini v adresáři Windows, kde omezíme velikost vcache:
[vcache]
MaxFileCache=261120
MinFileCache=32768
ChunkSize=4096
V případě 1 GB RAM omezíme maximální paměť využitelnou Windows pomocí parametru MaxPhysPage:
[386Enh]
MaxPhysPage=40000
      Na mnohem horší problém jsem narazil nedávno při rozšíření z 1 na 2 GB RAM. Windows se při bootování prostě zasekly v textové obrazovce s blikajícím kurzorem, aniž by zanechaly nějakou zprávu. Nouzový režim nešel spustit opět kvůli "nedostatku paměti". Po dlouhých experimentech s hodnotami vcache a MaxPhysPage se mi nakonec podařilo nastartovat systém v normálním režimu, ale nemohl jsem přepnout na vyšší rozlišení nebo pustit nějakou 3D aplikaci, protože se systém hned zakousnul. Při pátrání na Internetu jsem narazil na komerční patch R.Loewa za 20$, který by měl opravit nějaké chyby v ovladači vmm.vxd a zpřístupnit tak veškerou paměť Windows. Ke stažení je zdarma i demo, které ale funguje jen v nouzovém režimu.
      S tímto jsem se však nechtěl smířit, navíc 2 GB RAM pro Windows 98 ani moc nepotřebuji. Jen jsem chtěl, aby systém běžel jako dříve, alespoň s 1 GB RAM. První, co mě napadlo bylo zkusit nechat 1 GB RAM sežrat RAMDISKem, ale bez úspěchu. Pak jsem si vzpomněl na QEMM386 9.0, který se mj. chová (i když nechtěně) jako XMS limiter na 256 MB, jenže Windows 98 se QEMMem nemají moc v lásce a tak to skončilo chybou ochrany paměti. Nakonec padla moje pozornost na ovladač XMS HimemX.exe 3.33, který byl původně napsán pro FreeDOS, jenž dnes maintainuje Japheth, autor extenderu HX DOS. Ten má jednu "úžasnou" funkci, která dovoluje omezit velikost spravované XMS na daný počet kB. Lze jím tak nahradit himem.sys z Windows. Po stažení vybalte himemx.exe do adresáře Windows a přejmenujte ho na himem.exe. V config.sys změňte řádek:
DEVICE=C:\WINDOWS\HIMEM.SYS /V
na
DEVICE=C:\WINDOWS\HIMEM.EXE /MAX=1048576 /NUMHANDLES=64 /METHOD:FAST /VERBOSE
a pokud jste ještě neudělali, v system.ini upravte:
[386Enh]
MaxPhysPage=40000
Nyní by měl systém nastartovat v normálním režimu a používat 1 GB RAM (lze rychle zkontrolovat přes pravé myšítko na tento počítač / vlastnosti).
      Takto ale nebude fungovat nouzový režim, protože ten vynechává startovací soubory config.sys a autoexec.bat a svévolně si zavádí himem.sys. Pro překonání tohoto "neduhu" je třeba upravit systémový soubor io.sys, který jeho zavádění iniciuje. Jde jen o jednoduchou úpravu textového řetězce s názvem ovladače, ale pro pohodlí ostatním jsem na to napsal jednoduchý patch. Ten stačí nakopírovat do kořene k io.sys, spustit a odsouhlasit modifikaci. Předem si můžete io.sys někam zazálohovat, nicméně ho najdete třeba na spouštěcí disketě. Na takto upraveném systému funguju zatím 2 dny a vše se chová stejně jako když jsem měl jen 1 GB RAM, ale nemůžu zaručit, že to tak bude fungovat všem.
      Na základě diskuse na MSFN fóru se ukázalo, že parametr /MAX=... v config.sys není nutný a systém se pak řídí hodnotou MaxPhysPage v system.ini. Při dalších experimentech jsem se postupným zvyšováním dostal bez zamrznutí až na hodnotu 488FFh, tedy 1159 MB RAM. Zbylou RAM lze pak využít na RAMDISK, např. program xmsdsk 1.9i a umístit na něj swapovací soubor a případně temp. Podmínkou je, že RAMDISK bude alokován na konci XMS, což zajistí parametr /t. Do autoexec.bat přidáme řádek:
C:\DOS\XMSDSK.EXE 850000 Z: /t /y
který v tomto případě vytvoří RAMDISK Z: o velikosti 850MB. Protože Windows nedovolí swap umístit na RAMDISK standardním způsobem přes ovládací panely, je třeba jim domluvit v souboru system.ini řádkem:
[386Enh]
PagingDrive=Z:
Je však třeba zvážit, zda-li bude tato kapacita dostačovat. Některé nenažrané programy (či při zpracování velkého objemu dat) mohou vytvořit swap o velikosti x GB, v lepším případě pak spadne aplikace, v horším celé Windows.
      Při pročítání MSFN fóra jsem také narazil na velice zajímavý článek od Igora Leyka, který detailně rozebírá správu paměti ve Windows a možné potíže, které vznikají v důsledku instalace více jak 512 MB RAM. Mj. např. zmiňuje, že jeden z betatesterů Windows 98 rozběhl na mamutím serveru s 1 GB RAM a systém zkolaboval, takže se o problému ví už docela dlouho, jenže v tu dobu hořel deadline na vydání ostrých Windows a tak se tímto problémem dál nikdo moc nezabýval, protože tehdá měly běžné PC jen max. desítky MB RAM a navíc pro servery se počítalo s Windows NT nikoliv s 9x. Článek jsem zkopíroval na lokál, zde je originální ruská verze a zde anglický překlad od GreyPhounda, člena MSFN.

Windows 98 (SE), NT a moderní grafické karty
      Vzhledem k zastaralosti a ukončené oficiální podpoře M$ těchto OS, skončili tři nejvýznamnější výrobci grafických karet nVidia, AMD/ATI a intel vývoj ovladačů pro tyto systémy. Grafická karta je přitom jedna z nejčastěji upgradovaných komponent, takže uživatelů těchto OS se problém dotkne poměrně záhy (téměř u všech dnes dostupných nových karet). Stále však lze vybrat novější kartu, kterou by neměl být problém rozchodit. Blíže se zmíním o podpoře karet nVidia, s ostatními nemám zkušenosti. V případě Windows NT 4.0 SP6 poslední oficiální verze ForceWare 77.72 podporuje GeForce 6xxx. Provozoval jsem s nimi úspěšně MSI GeForce 6600GT PCI-E 128MB. Pro Windows 98 je k dispozici poslední verze ForceWare 81.98, která umí GeForce až do 7800 v AGP. Pro novější řadu GeForce 7xxx a experimentálně 8xxx PCI-E je k dispozici neoficiální verze ForceWare 82.69 (obsahující části driverů 93.71) od ZakMcKracken84 z MSFN. Ta byla zatím úspěšně vyzkoušena s kartami 6600GT PCI-E, 6800GT PCI-E, 7300GT PCI-E, 7600GS PCI-E, 7900GT PCI-E a 7950GT AGP. Zdá se, že důležitou roli hraje velikost VRAM, zatímco 512MB verze 7950GT nefungovala, tak 256MB verze fungovala bez problémů. Nedávno se mi do ruky dostala karta 8800GT PCI-E s 640 MB VRAM, ale nepodařilo se mi ji rozchodit. Drivery se sice nainstalovaly bez potíží, ale po restartu mě akorát v textovém režimu čekala zpráva "Windows Protection Error" a nazdar. Fungoval akorát nouzový / VGA režim. Vypadá to, že jádro NV80 se příliš liší od předchozího NV70 a se starými drivery prostě nepojede.
      Ani v případě novějších nepodporovaných karet ještě není vše ztraceno. Rus Bear Windows vytvořil projekt univerzálního VESA 2.0/3.0 ovladače VBEMP, který pracuje na celé řadě Windows NT 3.1 - XP a 9x. Jedná se pouze o základní podporu, která umožní nastavit vyšší rozlišení a více barev, avšak bez jakékoliv 2D a 3D akcelerace, neboť ta už je nad rámec VESA VBE standardu. Sice existoval standard VBE/AF pro 2D akceleraci, ale kvůli nenažrané licenční politice sdružení VESA se neprosadil. Další problém je ve zkryplené implementaci VESA BIOSu 3.0, kde všechny novější GeForce 5xxx a výše neumožňují nastavit obnovovací frekvenci větší než 60 Hz, což bude působit bolehlav majitelům CRT. Tato funkce správně funguje např. na integrovaných intelích VGA 945G. U karet ATI lze údajně obnovovací frekvenci nastavit natvrdo pomocí nástroje na editaci videoBIOSu. Na jiných kartách zas mohou dokonce v tabulce VESA módů chybět rozlišení větší než 800x600. V případě, že v NT-based OS nefunguje správně full-screen režim, je ještě potřeba nainstalovat patch VIDEOPRT.ZIP [13 kB].

Windows 98 (SE), ME a nové aplikace
      Od doby, kdy v roce 2006 ukončil Micro$oft oficiální podporu Win9x, tak neustále přibývá nových aplikací, které již pod Win9x neběží. Zde najdete seznam posledních funkčních verzí programů pro Windows 98 SE. V lepším případě aplikace vypíše alespoň smysluplné chybové hlášení, že chybí nějaká DLL knihovna nebo že se nepodařilo z knihovny importovat nějakou funkci. V horším případě nevypíše vůbec nic nebo provede klasicky neplatnou operaci - zavřít. Často programu chybí jen pár funkcí, které by šly snadno nahradit staršími verzemi, ale moderní vývojáři se s tím prostě nehodlají obtěžovat. Ukázkový příklad je hra Doom III, kde se doom3.exe odkazuje na neexistující funkci GlobalMemoryStatusEx v kernel32.dll. Nějaký koumák přišel na to, že stačí volat funkci GlobalMemoryStatus, která už ve Windows 98 je a hra se bez problémů rozběhne, zde si můžete stáhnout patch.
      Pár chytrých hlav z MSFN fóra (Tihiy a Xeno86) se však dalo dohromady a vytvořili OpenSource projekt KernelEx, který rozšiřuje kernel32.dll o nové WinAPI funkce, takže umožňuje pod Win9x běh některých novějších aplikací. O tomto projektu vím už pár let, ale zatím jsem neměl až takovou motivaci ho použít. To se změnilo, když jsem chtěl aktualizovat internetový prohlížeč a přejít na novou Mozillu Seamonkey 2.x, která už pod Win9x nativně neběží. Rozhodl jsem se nainstalovat nejnovější KernelEx 4.5 beta 2. Instalace je velmi jednoduchá, stačí spustit instalátor a párkrát kliknout. Jediné důležité nastavení je, zda-li se má podpora kompatability aktivovat globálně nebo se to nechá na uživateli, který ji nastaví pro každý program individuálně. Já jsem zvolil druhou možnost. Instalátor vytváří zálohu původního kernel32.dll, takže případné odinstalování by mělo být bez problému. Po potřebném restartu systému je vše připraveno k použití. Nastavení se provádí jako ve Windows XP, tj. klepnutím na spustitelný soubor programu pravým tlačítkem, položka vlastnosti a záložka Compatibility, kde lze vybrat od Windows 95 po Windows Vista.
      V případě Mozilla Seamonkey 2.0.4 jsem musel napřed nastavit kompatabilitu pro samotný instalátor (použil jsem Windows XP SP2) a po instalaci pro seamonkey.exe. Pak už jsem jen naimportoval starý profil a mohl vesele browsit. Náročnost na limitované GDI zdroje je zhruba stejná jako u starší verze. Bohužel nová verze Seamonkey 2.1 přestala fungovat (spustí se, ale při vykreslování stránky zatuhne). Poslední funkční verze je 2.1 beta 1 - já jsem se vrátil k 2.0.14. Dále jsem s KernelExem úspěšně rozběhl PC emulátor BOCHS 2.4.5, QEMU 0.13.0, FFDShow 1.1.3943, VLC Media Player 1.1.11, MPlayer WW SVN-r34106 (2011-09-16), WinAmp Pro 5.541 a postupně vyzkouším další programy. Seznam dalších programů, které otestovali uživatelé MSFN najdete zde. Přeji autorům KernelExu zdar a sílu do dalšího vývoje a vylepšování.
      Tak bohužel jsem hned druhý den po instalaci KernelExu objevil nekompatabilitu s VirtualDubem (vůbec se nespustí), resp. některými jeho plug-iny, např. ffvdub.vdf, vdubauo.vdf, MP4InputDriver.vdplugin... Předtím mi VirtualDub se všemi plug-iny fungoval bez problémů. Když jsem problémové plug-iny přesunul jinam, tak se VirtualDub spustil normálně. Zkoušel jsem i starší verze KernelExu 4.0 final a 0.3.6, ale se stejným výsledkem. Nastavení kompatability zde nemá vliv. Teprve po odinstalování KernelExu zase vše fungovalo jak má. Je tedy třeba mít se na pozoru, protože KernelEx může ovlivnit funkci i dalších programů, pro které není nastavena kompatabilita. Problém jsem reportoval na MSFN, autoři už o něm ví a hledají nějaké řešení. Jak bylo upřesněno, patchnutý kernel32.dll se může pokusit spustit některé programy pro novější Windows, i když nebyla nastavena kompatabilita, zatímco originální verze jejich spuštění zamítne (zmiňované plug-iny se tedy vůbec nenačítaly). UPDATE: S novou verzí KernelEx 4.5 RC4 se už VirtualDub spouští bez problémů.
      26.7.2011 oznámil Xeno86 (autor a hlavní programátor KernelExu), že z osobních důvodů končí s dalším vývojem KernelExu. Projekt je sice OpenSource, ale těžko říci, zda-li se najde pár zapálených nadšenců s tak hlubokými znalostmi systému, kteří budou schopni a odhodláni pokračovat. Vzhledem k tomu, že se komunita uživatelů Windows 98 dlouhodobě zmenšuje a takových low-level programátorů na světě není mnoho, tak to vidím spíše skepticky. Každopádně bych chtěl autorovi poděkovat za doposud vynaložené úsilí, jehož výsledky věnoval lidem zdarma a nechť se mu daří v životě a příp. dalších projektech.
      15.2.2012 Navzdory předchozímu oznámení se překvapivě objevila nová verze KernelEx 4.5.2, která umožňuje částečný provoz novějších verzí FireFoxu a Seamonkey. Testoval jsem Mozilla Seamonkey 2.7.1, která sice běží, ale nefungují např. bookmarky (nelze přidávat, v bookmark manageru se nezobrazí vůbec).


Jak nainstalovat M$-DOS a DR-DOS na jeden diskový oddíl aneb skryté možnosti NTLOADERu:
      Tento postup lze použít i pro jiné DOSy, které mají jinak pojmenované systémové a konfigurační soubory (možná by to šlo obejít hexaeditorem ;-). DR-DOS používá názvy ibmio.com, ibmdos.com, dconfig.sys, autodos7.bat, což je zcela nekonfliktní vůči MS-DOSu (io.sys, msdos.sys, config.sys, autoexec.bat). Zbývá vyřešit problém s bootsektory v čemž nám pomůže právě NTLOADER.
      NTLOADER je bootmanager, který je součástí Windows NT/2k/XP. Sestává se ze souborů ntldr, bootfont.bin a boot.ini v kořenovém adresáři. Lze ho používat i bez Windows, ovšem nainstalovat ho lze jen instalátorem Windows (po prvním restartu lze instalaci přerušit a smazat dočasné instalační soubory). Konfigurace je uložena v souboru boot.ini. Obsahuje obvykle řádky podobné tomuto:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation, verze 4.00"
jenž určují jaký systém se z jakého oddílu spustí. V tomto případě se načte bootsector z 1. oddílu. NTLOADER však má jednu vychytávku - umožňuje spustit bootsector z jeho image souboru. Potom by řádek vypadal třeba takto:
C:\bootsect.cds="Caldera DR-DOS 7.03"
Stačí si tedy po instalaci daného DOSu uložit bootsector do souboru (pomocí nějakého specializovaného prográmku nebo Norton DiskEditoru) a ten pak předhodit NTLOADERu. Pořadí instalovaných systémů je zcela libovolné, jen je třeba mít na paměti, že instalátor bootsector přepíše a tak je důležité mít předem vytvořenou zálohu. Nakonec je dobré si vytvořit i zálohu bootsectoru s NTLOADERem, kterou lze v případě problémů pomocí DiskEditoru obnovit. Podobným způsobem se lze vrátit k původnímu OSu.
      Pozor! pokud změníte velikost oddílu (např. pomocí PQMagicu) je třeba image soubory bootsectorů vytvořit znovu, protože se změní některé důležité údaje jako třeba počet sektorů na cluster a oddlíl by nemusel být čitelný.

Jak vytvořit zálohu bootsectoru v Norton DiskEditoru:
spusť diskedit c:
menu "Object|Boot Record" (Alt+B)
menu "Tools|Write Object To...|to a File|C:\nazev.bin" (Alt+W)

Jak obnovit bootsector ze zálohy v Norton DiskEditoru:
spusť diskedit c:
menu "Object|File...|C:\nazev.bin" (Alt+F)
menu "Tools|Write object To...|to Sectors...|C:\0-Boot area" (Alt+W)

      Skrze boot.ini lze prostřednictvím NTLOADERu předat NT kernelu celou řadu parametrů (zapsaných na konec řádku s cestou a jménem systému), které nelze většinou v běžícím systému nikde měnit. Jedním ze zajímavých je volba /3GB, měnící rozdělení alokace virtuálního adresového prostoru (max. 4 GB) mezi aplikace a jádro. Standardně se používá 2 + 2 GB a lze to změnit na 3 + 1 GB ve prospěch aplikací, což někdy může zlepšit výkon. Na druhou stranu se tím ale zmenší prostor pro diskovou cache. Přehled dalších parametrů zde.


Windows NT a HDD větší než 128 GB:
      Podobně jako Windows 9x ani Windows NT nepodporují LBA48 a tím pádem disky větší než 128 GB. Jelikož Windows NT neumí používat režim INT13h, tak z takového disku ani nenabootují. A Microsoft samozřejmě žádný patch oficiálně nevydal. Někteří výrobci řadičů (spíše starší typy) ale dodávají svoje ovladače (např. intel Application Accelerator - intelata.sys pro starší verze <ICH5), které LBA48 podporují. Objevila se však záchrana od ukrajince Alexandera Telyatnikova v podobě univerzálního OpenSource driveru UniATA, který podporuje řadu moderních řadičů. Driver lze nainstalovat do Windows NT 3.51 až XP a využívá ho též ReactOS. Po instalaci je třeba vypnout standardní driver Windows atapi.sys, aby nekolidoval. Osobně jsem ho vyzkoušel pod Windows NT 4.0 SP6CZ na ICH7 s 500GB SATA HDD v IDE režimu a funguje zatím bez problémů. Dosažený výkon disku je srovnatelný s provozem pod Windows XP SP3.


Formátování disku s explicitní volbou filesystému pod Windows NT/2K/XP:
      Velký Bill ví, co je pro uživatele nejlepší a tak standardní formátovací nástroj z Windows 9x si za vás typ nového souborového systému vycucá z prstu. Já jsem bohužel nutně potřeboval zformátovat 8 MB CompactFlash kartu na systém FAT16, přičemž formát mi na něj zatvrzele cpal FAT12. Snažil jsem se na webu najít ňákou utilitu, ale marně. Akorát jsem zjistil, že formát má nedokumentovaný přepínač /z: počet_sektorů_na_cluster, který ale nelze použít na výměnné disky. Celkem příjemně mě pak překvapil formát z Windows XP (NT/2K), který oplývá hned dvěma zázračnými přepínači /fs: FAT/FAT32/NTFS a /a: velikost_clusteru. Když jsem mu naforcoval dostatečně malou velikost clusteru (2048 B), tak správně pochopil, že pro větší počet clusterů (něž asi 4096) musí použít FAT16 a já tak dosáhl kýženého cíle. Problém ovšem nastane, pokud potřebujete naformátovat FAT32 oddíl větší než 32 GB. Pak je nutné použít formátovací utility 3. stran, např. FAT32Format.

Windows 2000 - jak vypnout ochranu systémových souborů?
      Pokud jste si už zvykli na to, že vaše nová windows jsou pěkně tučná, já tedy ne. Po instalaci W2K +SP2 měl jejich adresář velikost kolem 900 MB. Když jsem procházel adresářovou strukturu, nemohl jsem si nevšimnout adresáře %WINDIR%\SYSTEM32\DLLCACHE, který prakticky duplikoval %WINDIR%\SYSTEM32 a zabíral kolem 250 MB. Pokud totiž někde smažete nějaký systémový soubor, nahradí se hned odpovídajícím z tohoto adresáře. Pokud je náhodou smažete oba, bude po vás systém vynucovat instalační CD. Vypnutí této funkce může být taky třeba pro korektní nainstalování některých programů. Takže jak na to?
      Pokud nemáte nainstalovaný žádný servispack, stačí v registrech (pomocí regedit.exe) změnit hodnotu klíče "HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\SFCDisable" z "0" na "FFFFFF9D".
Pokud máte nainstalovaný servispack nebo používáte WinXP, musíte napřed modifikovat soubor z %WINDIR%\SYSTEM32\sfc.dll resp. sfc_os.dll ve WinXP.
1) zkopírujte si jej někam stranou
2) kopii otevřete hexaeditorem (DN, HIEW,...)
3) jděte na offset 6211h
4) změňte dva bajty "8B C6" na "90 90" a uložte
5) nejlépe z jiného operačního systému nahraďte %WINDIR%\SYSTEM32\sfc.dll za modifikovanou variantu. Nyní můžete adresář %WINDIR%\SYSTEM32\DLLCACHE v klidu smazat. Podobný adresář zde taky vytvořil servispak, který má kolem 120 MB. Po smazání dalších zbytečností a zabalení některých souborů packerem UPX jsem se dostal na velikost 320 MB, což je zhruba 1/3 původní velikosti.

Jak na editaci registrů Windows NT/2000/XP?
      Registry Windows jsou komplexní databáze, kde je uloženo nastavení systému, nainstalovaných aplikací a profily uživatelů, která postupně nahradila samostatné .ini soubory používané ve Windows 3.x a starších. Vytváří se již při instalaci OS, další část pak při zakládání uživatelských účtů. Fyzicky jsou registry uložené v několika binárních souborech (binary hives) v adresáři %WINDIR%\SYSTEM32\CONFIG (default, sam, security, software, system), %USERPROFILE%\ntuser.dat a %USERPROFILE%\Local Settings\Data aplikací\Microsoft\Windows\UsrClass.dat.
      Logicky jsou registry reprezentovány jako stromová struktura klíčů obsahující proměnné různých datových typů. Obsah binárních souborů sam, security, software a system se mapuje do klíčů HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\SECURITY, HKEY_LOCAL_MACHINE\SOFTWARE a HKEY_LOCAL_MACHINE\SYSTEM, které uchovávají specifické informace o PC společné pro všechny profily. Klíč HKEY_LOCAL_MACHINE\HARDWARE je generován dynamicky při startu Windows. Binární soubory ntuser.dat a UsrClass.dat specifické pro právě přihlášeného uživatele se mapují do klíče HKEY_USERS a binární soubor default se mapuje do klíče HKEY_USERS\.DEFAULT. Ostatní klíče už jsou jen symbolické linky na jiné klíče. Binární soubory registrů jsou za běhu Windows chráněny proti přístupu, takže ani administrátor je nemůže přečíst nebo zkopírovat. Zálohu je možno jednoduše udělat pomocí nějakého live CD s Linuxem nebo Windows PE, či využít DOS s podporou NTFS4DOS driveru.
      Pro editaci registrů Windows nabízí 2 programy, regedit.exe s GUI a reg.exe pro příkazovou řádku. Jejich funkce jsou zhruba stejné, reg.exe se více hodí pro volání v dávkových souborech a regedit.exe zas pro ruční editaci. Regedit umožňuje libovolný klíč uložit buď v textovém formátu (volba "Registrační soubory *.reg") nebo jako binary hive (volba "Soubory podregistru *.*"). U textového formátu *.reg jsou ještě 2 volby: novější v 16-bitovém kódování UNICODE pro Windows 2000 a vyšší a klasický 8-bitový ASCII pro kompatabilitu s Windows 9x a NT4. Uložené části registrů lze zpětně importovat buď dvojklikem na daný *.reg soubor nebo volbou z menu "Soubor|Importovat" a pak vybrat požadovaný formát souboru. Do Windows 2000 a vyšších lze importovat ASCII i UNICODE formát do starších Windows jen ASCII formát. Pozor, je zde podstatný rozdíl mezi importem binárních a *.reg souborů! Zatím co při importu binárního souboru se kompletně přepíše daný klíč se všemi podklíči (původní hodnoty se vymažou), tak při importu *.reg souborů dochází ke sloučení s již existujícími klíči, což někdy může vést k nepředvídatelnému výsledku či minimálně aspoň k nabobtnání registrů. V souborech *.reg je uložena absolutní cesta ke všem klíčům, takže při importu jsou cílové klíče předem dané. Nic nám však nebrání soubor zeditovat a přepsat jinou cestou. Při importu binárního souboru se přepíše libovolný právě označený klíč. Protože Regedit nepodporuje pro klíče oblíbené funkce CTRL-C / CTRL-V, je toto jediný způsob, jak klíče přesouvat a kopírovat.
      Při importu souboru registrů však může nastat zásadní problém - Windows odepřou přístup k některým klíčům z důvodu nedostatečného oprávnění nebo proto, že je systém právě používá. Oprávnění se dá pořešit kliknutím pravým tlačítkem na klíč, výběrem nabídky "Oprávnění..." a přidáním práv pro aktuálního uživatele. Nedávno jsem však potřeboval přepsat kompletně klíč HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 a ani se změnou oprávnění jsem neuspěl. Jedinou možností tak byla offline editace v jiném systému. Naštvaně jsem přitom vzpomínal, jak v Linuxu lze snadno a bez restrikcí krásně editovat konfigurační adresářovou strukturu /etc (jako ostatně celý filesystém). Ve starších Windows 9x byl Regedit i pro DOS a bylo tak možné snadno celý binární registr rozbalit do textu, zeditovat a zase zabalit zpět. Novější Windows už nic takového nemají. Lze však jednoduše použít záchrannou konzoli z instalačního CD Windows 7 (případně Bart's PE live CD). Ta se spustí po startu instalátoru sekvencí voleb: Opravit tento počítač -> Použijte nástroje pro obnovení -> Příkazový řádek. Narozdíl od starší recovery konzole Windows NT/2000/XP zde máme k dispozici plně funkční příkazový řádek s možností spouštět konzolové WIN32 i GUI aplikace. A samozřejmě zde nechybí regedit.exe.
      Při modifikaci jsem postupoval tak, že jsem si označil kořenový klíč HKEY_LOCAL_MACHINE a načetl celý binární soubor system z mých Windows XP na disku volbou menu "Soubor|Načíst podregistr..." a vybral pro něj jméno "muj". Z něj jsem vymazal klíč ControlSet001. Pak jsem spustil notepad.exe a v daném .reg souboru zeditoval funkcí najít/nahradit cesty klíčů z HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 na HKEY_LOCAL_MACHINE\muj\ControlSet001 a naimportoval ho. Zde by bylo jednodušší importovat binární soubor s klíčem ControlSet001, ale z důvodů složitější editace jsem potřeboval pracovat s textovým formátem. Nakonec je třeba editovaný registr odpojit volbou menu "Soubor|Uvolnit podregistr..." (musí být vybraný klíč, jehož jméno jsme zadali při načtení). Pak už jen stačí restartovat a změny by se mely projevit.

Instalace ovladačů intel AHCI pod Windows XP
      Moderní chipsety už řadu let podporují rozšířený režim SATA řadiče AHCI (Advanced Host Controller Interface), který umožňuje využívat pokročilejší funkce jako např. NCQ a tím se může pozitivně projevit na výkonu diskového subsystému. Režim AHCI je však nekompatabilní s klasickým SATA/IDE na úrovni řídicích registrů a I/O portů. To znamená, že operační systémy, které nevyužívají pro práci s diskem služeb BIOSu, potřebují vlastní AHCI ovladač. Ten byl v základu integrován až do Windows Vista a novějších, jednoduše proto, že v době vzniku Windows XP žádné AHCI nebylo (M$ by sice mohl podporu AHCI integrovat do SP3, ale to by si podrážel prodej Vist a sedmiček). Windows XP a starší sice umožňují načtení ovladače z diskety během první fáze instalace (klávesou F6), jenže většina PC už dnes disketovku nemá (prakticky ze všech nových základních desek s čipsety intel 5x/6x/7x vymizel FD řadič) a je otázkou, jestli by fungovala USB disketovka v BIOS legacy režimu (režimy emulace USB legacy zařízení v BIOSu bývají nezřídka implementovány prasácky a způsobují tuhnutí či pád některých programů). Proto většina výrobců základních desek nabízí v SETUPu možnost přepnout SATA na IDE nebo legacy režim, v kterém by měla instalace Windows XP a starších proběhnout bez problémů. Instalaci AHCI ovladače lze provézt dodatečně, takže o nic nepřijdete.
      Ruční doinstalace je poměrně snadná, i když doporučuju předem zálohovat systém, protože by se mohl dostat do nebootovatelného stavu. Pokud máte intel chipset ICH7 - PCH řady 7x, stáhněte si balíček iahciwxp.zip [297 kB], který obsahuje vše potřebné. Popis instalace je v install.txt. Nejprve nakopírujte soubor ovladače iastor.sys do vašeho adresáře WINDOWS\SYSTEM32\DRIVERS a pak ťukněte na iastor.reg, který ovladač správně zaregistruje tak, aby se zavedl při bootu systému. Po té restartujte a Windows by měly detekovat nový AHCI řadič, pak už jen nainstalujte klasicky jako nové zařízení s ovladačem z daného umístění, kam jste soubory rozbalili.
      Já jsem tento postup úspěšně vyzkoušel na základní desce Gigabyte GA-B75M-D3V s SSD Samsung 840 (120 GB), kterou jsem měl zapůjčenou od kolegy. Podle výsledků z testů HD Tune Pro, jsou však rozdíly nevýrazné:

režim AHCI IDE
přenosová rychlost  404,4 MB/s 399,3 MB/s
přístupová doba 0,046 ms 0,055 ms
zátěž CPU 7,5% 10,7%

BTW instalace dalších ovladačů (intel INF, HD Graphics, Realtek HD Audio, Realtek NIC 8111F) proběhla bez problémů a Windows XP běžely velmi svižně a startovaly za 12 - 15 s. Ovšem na některých systémech tomu může být i naopak. Na PC v práci s chipsetem intel H57 a klasickým diskem jsem v AHCI režimu dosáhl maximální přenosovou rychlost 110 MB/s, zatím co v IDE režimu až 130 MB/s. Schválně jsem zkusil ještě kopírovací test pod Linuxem (kernel 3.7) a i zde bylo AHCI pomalejší - doba kopírování 2:57 minut, v IDE režimu 2:42 minut.
      Také jsem se pokusil o manuální integraci ovladače iastor.sys přímo do instalačky Windows XP SP3 (úprava instalačního skriptu txtsetup.sif), kam jsem již dříve úspěšně integroval ovladače RAID řadičů HPT 3xx, ITE 8211/8212 a SIL 0680, ale operace skončila nakonec neúspěchem. Celý proces instalace proběhl normálně, takže ovladač musel být už v tuto dobu aktivní, jenže po závěrečném restartu, kdy se má objevit uvítací obrazovka, se systém zacyklil v nekonečných restartech. Na další debugování už nebyl čas, zapůjčené PC jsem musel vrátit. Zde je návod, jak integrovat ovladače pomocí utility nLite.


Windows Vista / 7 - proč to kurva zabírá tolik místa na disku?
      Asi každý, kdo instaloval nové Windows Vista nebo Windows 7 si všiml, že vyžadují na disku více než 10-násobek volného místa než předchozí systém Windows XP. Většina lidí nad tím dnes mávne rukou, že prý "to je pokrok" nebo že "disky jsou dnes levné". Občas se někdo podiví, jak jeho instalace postupným používáním neustále bobtná, což může být nepříjemné např. na netboocích s omezenou kapacitou SSD. Já jsem zatím instaloval oba systémy pouze do virtuální mašiny na moje pokusy (k přechodu zatím nemám pražádnou motivaci). U Windows Vista Ultimate 32-bit SP1 po instalaci SP2 obsadil systémový adresář \Windows asi 10 GB, zatím co u Windows 7 32-bit jen necelých 8 GB. U 64-bitových Windows by to bylo ještě více, protože ty obsahují řadu knihoven jak v 64-bitové, tak 32-bitové verzi (navíc ty 64-bitové verze jsou až 2x větší než 32-bitové). Ve skutečnosti je obsazená kapacita asi o 20% menší, protože Windows používají NTFS hard-linky a některé soubory se tak při vyčíslení započítávají vícekrát. Jen pro srovnání, u mé asi 3 roky staré a pečlivě udržované instalace Windows XP 32-bit SP3 s .NET 1.1 (nainstalovány stovky aplikací) zabírá adresář \Windows 800 MB. Zajímalo mě tedy, co na JehoVistách a 7 zabírá tolik místa.
      Jak jsem zjistil, tak největším adresářem v systému je \Windows\winsxs - Vista SP2: 6,3 GB, 34420 souborů a Windows 7: 4,1 GB, 29328 souborů. Řada uživatelů však hlásí po nějaké době používání objemy klidně 10 - 20 GB, které neustále narůstají. Proč tomu tak je? U Windows Vista došlo k poměrně zásadní změně adresářové struktury systému. Zatímco u Windows XP byly téměř všechny DLL knihovny sdílené v adresáři \Windows\system32, tak u Vist se přestěhovaly do \Windows\winsxs, tzv. Component Storage. WinSxS znamená Windows Side-by-Side, tedy něco jako různé komponenty Windows vedle sebe. Tato technologie si klade za cíl vyřešit problém zvaný "DLL Hell". Dříve se totiž mohlo celkem snadno stát, že se instalací nové aplikace přepsala nějaká DLLka v systémovém adresáři \Windows\system32, což mohlo ovlivnit jinou dříve instalovanou aplikaci, která využívala DLLku se stejným názvem avšak jiné verze. Proč existují vzájemně nekompatabilní DLLky se stejným názvem, na to se mě neptejte. Nicméně tento problém je snadno řešitelný díky tomu, že každá aplikace hledá DLLku nejprve ve svém adresáři a až potom v systému (přesné pořadí vyhledávání je popsáno zde), takže pro konfliktní aplikace lze nahrát různé verze DLLek do jejich adresářů. To však vyžaduje trochu detektivního úsilí a mít vytvořené zálohy systému.
      WinSxS to řeší tím, že každou verzi DLLky od aplikace nebo Windows Update instaluje izolovaně do jiného podadresáře ve \Windows\winsxs. Aplikace si pak mohou pomocí .manifest souboru nebo vestavěného manifestu v binárce přesně říct, kterou verzi DLLky potřebují a systém jim ji poskytne. Tím je sice problém kolizí vyřešen, ale za cenu nehorázného plýtvaní úložným prostorem a většího overheadu při nahrávání knihoven. Trochu mi připadá, že se tímto neguje původní význam sdílených knihoven, možná by méně místa zabraly aplikace se staticky linkovanými knihovnami :P Další problém je, že při odinstalování aplikace je instalátor málo důsledný a nepoužívané knihovny v systému většinou nechá (naproti tomu např. v Debian Linuxu tohle už léta funguje, správce balíčků apt/dpkg má dokonalý přehled o závislostech a umí nepoužívané balíčky kompletně odstranit). V případě Windows Vista po instalaci SP1 by mohla alespoň trochu pomoci utilita vsp1cln.exe. Ruční čištění desítek tisíc provázaných souborů nepřipadá moc v úvahu. Doporučuji tedy instalovat jen opravdu nutné aplikace a updaty, ostatní zkoušet ve virtuální mašině, kterou lze po zabordelení jednoduše smazat nebo obnovit ze zálohy.

Windows Vista / 7 a limit DPMI paměti
      Další "skvělou" vlastností nových OS Windows Vista 32-bit a Windows 7 32-bit je omezení DPMI paměti, kterou mohou alokovat 32-bitové DOSové programy běžící v NTVDM na pouhých 32 MB. Naštěstí tento limit není hardkódovaný, ale dá se změnit v registrech. Stačí spustit regedit.exe, najít větev:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
a v ní vytvořit novou DWORD hodnotu DpmiLimit do které zapíšeme maximální přidělenou velikost DPMI paměti v Bytech. Pozor, tento trik nefunguje na starších Windows Vista před vydáním SP1. Více informací a testovací program zde.
      Další zádrhel může nastat, pokud DOSový program používá nějaký VDD ovladač. Windows Vista / 7 nedovolí tuto DLLku zavést pokud není umístěna v systémovém adresáři %windir%\system32. Např. nová verze Necromancer's DOS Navigatoru používá VDD winoldap.dll na propojení schránky NDN s Windows. Po překopírování do systémového adresáře ale vše funguje správně.
      Dále jsem ve Windows 7 narazil na problém, že nelze spustit žádný DOSový program, který běží v grafickém režimu VESA. Detekuje sice správně nabízené VESA módy, ale nepodaří se je nahodit (ani v banked režimu). Fungovaly mi pouze VGA módy (např. Quake 1).

Windows XP / Vista / 7, hotfix KB2724197 a EMS paměť v NTVDM
      11.10.2012 Před pár měsíci vydal Micro$oft hotfix KB2724197, který opravuje bezpečnostní chybu, jenž umožňovala 16-bitovému programu skrze díru obsluhy EMS paměti v NTVDM se dostat na CPL ring 0. To hrozí jen při spuštění škodlivého programu na lokálním PC (po přihlášení do systému), takže vzdálený počítač to nemůže poškodit (pokud někdo sám program nespustí jako trojana). Micro$oft ovšem tuto chybu opravil dost svérázným způsobem a to tak, že zablokoval v NTVDM vestavěnou podporu EMS paměti pro všechny programy. Sice dnes asi málokdo pouští DOSový program, který potřebuje EMS, ale mohl by být v takovém případě nepříjemně překvapen, zvlášť pokud má zapnuté automatické aktualizace. Jsou na výběr 2 řešení: buď hotfix KB2724197 neinstalovat či odinstalovat nebo použít alternativní emulátor EMS paměti EMS Magic, který je pro nekomerční účely ke stažení zdarma.
      22.12.2012 Reakce DOSových fandů na sebe nenechala dlouho čekat a tak Hjort Nidudsson a Japheth vydali alternativní ovladač EMS paměti pro Windows XP: DZEMM (DOSZIP Expanded Memory Manager) 1.0b alpha, který navíc nabízí až 256 MB EMS paměti. Instalace je jednoduchá. Do systémového adresáře Windows nakopírujeme 2 soubory dzemm.sys a dzemm.dll a pak do config.nt přidáme řádek DEVICE=%SystemRoot%\SYSTEM32\dzemm.sys hned za řádek s ovladačem himem.sys. Po zadání příkazu mem v příkazovém řádku by se mělo ve výpisu objevit: "268435456 bajtů celkem paměti EMS".

Windows Vista / 7 32-bit a více jak 4 GB paměti
      Řada lidí se mylně domnívá (i díky reklamní masáži M$), že 32-bitový operační systém nemůže využít více jak 4 GB operační paměti a musí proto přejít na 64-bitový systém. Přitom procesory intelu už dávno (od Pentia Pro) podporují technologii PAE (Physical Address Extension), což je 36-bitové rozšíření adresové sběrnice a 64-bitové rozšíření položek ve stránkovací tabulce, které umožňuje adresovat až 64 GB fyzické paměti. Důležitou roli však hraje také chipset, resp. MCH (Memory Controller Hub), který určuje kolik a jak max. velkých paměťových modulů deska pobere. Do nedávna více jak 4 GB zvládaly pouze speciální serverové desky, ale s příchodem chipsetů i965 a P3x/4x se tato možnost dostala i na desktopy.
      Dále je nutná podpora PAE v operačním systému a některých driverech, které pracují přímo s fyzickou adresou. Stávající 32-bitové aplikace fungují beze změn, pochopitelně ale nemůžou využívat víc jak 4 GB paměti pro jednu instanci. V Linuxu a pod. unixových OSech je podpora PAE celkem samozřejmost. Windowsy podporují PAE už od serverových edicí Windows 2000. Desktopové Windowsy jsou limitovány na 4 GB nebo ještě méně, obvykle modifikací kódu jádra. Geoff Chappell však zjistil, že Windows Vista obsahují kernel s plnou podporou PAE, který je pouze omezen softwarovou licencí na více jak 4 GB paměti. Jenže tu nelze od Micro$oftu nijak koupit. Na své stránce dále ukázal, že malou změnou funkce MxMemoryLicense v souboru ntkrnlpa.exe, lze kontrolu licence paměti vyřadit a využít maximální instalovanou kapacitu RAM (v jeho případě 8 GB). Tento patch slouží pouze pro testovací účely a má svoje úskalí. Jednak je potřeba při modifikaci souboru opravit i kontrolní součet v PE hlavičce, což není problém, ale také soubor znovu digitálně podepsat. Windows Vista loader totiž z bezpečnostních důvodů kontroluje při bootu certifikáty některých systémových souborů. To lze obejít spuštěním Windows v testovacím režimu a nebo úplným vypnutím kontroly integrity systémových souborů konfigurací bootloaderu.
      13.5.2012 Netrvalo to dlouho a objevil se patch ReadyFor4GB, který zapne existující podporu PAE v kernelech Windows Vista a Windows 7. Teoreticky by mělo být možné využít až 128 GB RAM (na serverových procesorech s podporou 40-bitového PAE). Protože patch modifikuje soubor kernelu, je tím zneplatněn jeho digitální podpis a je tak potřeba v nastavení bootloaderu povolit volbu "testsigning on" a pro funkci PAE "pae forceenable". Ani po té ještě není úplně vyhráno, protože některý driver nemusí být s PAE kompatabilní a systém může spadnout. V tomto případě je možné přes bootmenu spustit původní kernel (patchnutý kernel byl přidán, nikoliv přepsán) a zkusit nekompatabilní ovladač vyřadit.


Jak vytvořit bootovací CD-ROM s Windows 95?
      Dnešní PC umožňují bootovat kromě diskety také z CD-ROM mechaniky, ZIPky a dalších zařízení. Občas se nám pak může hodit, když Widle kleknou, nějaké prostředí s podporou FAT32 a dlouhých názvů, v němž se můžeme pokusit o záchrannou akci. Takže proč si neudělat bootovací CD přímo s Windows? Tato myšlenka mě napadla už dávno a částečně jsem rozchodil první verzi s WIN98SE, ale občas to tuhlo/padalo. Teď jsem se k tomu vrátil s tím, že jsem použil Windows 95 OSR 2 CZ (to OSR2 je docela důležité, zahrnuje podporu FAT32 a obsahuje míň chyb). Celé to funguje tak, že se systém nastartuje z bootovací diskety (emulací bootdiskety na CD), načtou se potřebné ovladače pro CD-ROM a další, vytvoří se RAMDISK kam se rozbalí ZIPák s Windows a následně se Windows spustí. Podotýkám, že jsem je předem _trochu_ okrouhal, takže postačí 32MB RAMDISK + zhruba 16 MB pro běh, takže na systému s 64 MB a více RAM by neměl být problém.
      Předpokládám využití trochu zkušenějšími uživateli, takže postup uvedu stručněji (o tom, že byste si měli předem vytvořit zálohu systémového disku snad nemusím hovořit). Takže:

1) Zkopírujem si instalační soubory W95OSR2 na disk do adresáře C:\INSTALL.
2) Vytvoříme adresář simulující RAMDISK C:\RAMDISK.
3) Vytvoříme adresář simulující CD-ROM C:\CDROM.
4) Do souboru config.sys přidáme řádky:
      SUBST W: C:\RAMDISK
      SUBST X: C:\CDROM
      (je potřeba mít někde správnou verzi souboru SUBST.EXE)
5) Spustíme instalaci Windows (C:\INSTALL\setup /is /im).
6) Ignorujeme hlášku o běžícím SUBST stiskem ESC.
7) Zvolíme instalační adresář W:\WIN95.
8) Nainstalujeme si potřebné ovladače.
9) Nainstalujeme si potřebné aplikace na disk X: (např. dále potřebný WinZIP).
10) V ovládacích panelech zakážeme odkládací soubor virtuální paměti.
11) Jako prevenci před zásahem do registrů jiných nainstalovaných Windows je možno přejmenovat soubor system.dat na system.win a user.dat na user.win (či jinak, dle vlastního uvážení). Pak je nutno též hexaeditorem upravit io.sys a některé další soubory v W:\WIN95, kde se vyskytuje řetězec "system.dat" a "user.dat". Pokud jsou správně nastavené proměnné WinDir, WinBootDir a HostWinBootDrv v msdos.sys něměla by být tato úprava nutná, nicméně jsem ji provedl.
12) Zbavíme se nepotřebných souborů (chce to trochu citu, pomůže vám filelist, viz níže).
13) Další soubory zabalíme pomocí UPX.
14) Snažíme se omezit dlouhé názvy, zejména se je třeba zbavit českých znaků aby mohlo dojít ke korektnímu rozbalení. Adresář Nabídka Start necháme, zástupce programů si pojmenujeme třeba anglicky nebo prostě bez hacku a carek. Lépe by se hodila anglická instalace Windows.
15) Pokud máme vše nainstalováno a nastaveno, za běhu Windows zabalíme WinZIPem.
16) Připravíme si bootovací disketu podle filelistu, nejprve budem rozbalovat ještě z disku. Fígl je v tom, že použijeme rezident na podporu dlouhých názvů DOSLFN 0.32c v DOSu, RAMDISK s podporou dlouhých názvů a rozbalovač UNZIP32 též s podporou dlouhých názvů.
17) Pokud došlo ke korektnímu rozbalení na RAMDISK a spuštění Windows, tak ještě provedeme závěrečné nastavení a zkontrolujeme, jestli se někde neodkazujeme na cestu C:\RAMDISK\WIN95, případně opravíme na W:\WIN95. Nakonec Windows opět zabalíme WinZIPem.
18) Nyní se můžeme vrátit k původnímu systému a vypalovat (silně doporučuji na CD-RW).
19) Vytvoříme si image bootovací diskety a předhodíme ji vypalovacímu programu.
20) Na CD dáme soubory z adresáře C:\CDROM a pálíme.
21) Po vypalování restartujeme a v SETUPu nastavíme bootování z CD-ROM. Pokud vše proběhlo dobře, mělo by to fungovat stejně jako při zkoušce s disketou, zkuste také v SETUPu úplně zakázat disky. Tak hodně štěstí ;-) mě to trvalo asi 1,5 dne, než se mi to podařilo vyladit.

Co by se mělo ještě vylepšit:
1) Bych chtěl zakázat detekci nového hardware, pokud je to však vůbec možné.
2) Hodil by se nějaký univerzální SVGA ovladač, který by pracoval na všech VESA VBE 1.2+ kompatabilních grafických kartách a umožnil práci ve vyšších rozlišeních. EDIT: Řeřením je univerzální VESA 2.0 ovladač VBEMB pro Windows 9x.
W95 boot CD screenshot Zde je výsledek mého snažení (velikost 30 MB).

TADY je balíček s listingy souborů bootovací diskety a Windows (z pochopitelných důvodů zde nemůžu dát kompletní image), moje *.ini, autoexec.bat, config.sys soubory a pár esenciálních freewarových utilit: ATAPICD.SYS, DOSLFN 0.32c, UNZIP32 5.40 a RAMDISK XMSDSK 1.9I.

Jak vytvořit bootovací USB flashdisk s GRUB4DOS pod Windows NT/2K/XP?
      Tak jako v BIOSech přibyla podpora bootování z CD/DVD, tak dnes už snad všechny základní desky umí bootovat z USB zařízení třídy Mass Storage. V SETUPu lze obvykle zapnout podporu pro USB Legacy, čímž se USB disk zpřístupní skrze služby BIOSu INT 13h pro operační systémy tak, jakoby to byl klasický pevný disk nebo disketa. USB flashdisky lze provozovat buď v režimu SuperFloppy, kdy BIOS emuluje disketovou jednotku A: nebo v režimu pevný disk, kdy BIOS emuluje jednotku C: (hd0). Windows standardně formátují USB flashdisky jako SuperFloppy, tzn. bez MBR s partition tabulkou. Na nultém sektoru je tedy bootsektor operačního systému následovaný FAT a kořenovým adresářem. Pro nás bude ale výhodnější naformátovat USB flashdisk jako klasický disk, tj. s MBR a partition tabulkou.
      Pokud máte na PC DOS / Windows 9x nebo bootovací disketu s DOSem, lze při zapnuté podpoře USB Legacy s flashdiskem pracovat klasickými nástroji DOSu (FDisk, Format, Sys), kterými nejdříve vytvoříme primární oddíl, nastavíme ho jako aktivní, naformátujeme a následně přeneseme systémové soubory. Pod Windows NT/2K/XP/Vista/7 to už takhle snadno nejde, protože Windows brání DOSovým programům v přímém přístupu na disk. Použijeme proto nástroj HP USB Disk Storage Format Tool, který na flashdisku vytvoří MBR s partition tabulkou a naformátuje ho. Lze zvolit souborové systémy FAT16/32/NTFS, doporučuji použít FAT (u disků větších než 2 GB musí být použita FAT32). Volba "Create a DOS Bootable Disk" umožňuje nakopírovat na flashdisk systémové soubory DOSu, které musíte mít někde na disku (io.sys, msdos.sys, command.com, lze stáhnout např. zde) a patřičně upraví boot sektor (DBR). Další alternativou je program Rufus, který taktéž umí formátovat USB flashky a obsahuje už v sobě jádro FreeDOSu a loader pro instalační ISO image Windowsů. Pokud chcete bootovat i jiné systémy než DOS, čtěte dále.
      V dalším kroku na USB flashdisk nainstalujeme mocný bootloader GRUB4DOS, poslední verze ke stažení zde. Ten umí bootovat různé verze DOSu, Windows, Linuxu, BSD, ISO, HDD a floppy image. GRUB lze nainstalovat do MBR či DBR nebo natáhnout windowsím zavaděčem NTLDR. GRUB4DOS je navíc v podobě EXE souboru, který lze spustit z DOSu. V našem případě provedeme instalaci do MBR. Pro DOS / Windows 9x je určen nástroj bootlace.com a pro Windows NT/2K/XP/Vista/7 je potřeba grubinst.exe. K němu existuje i grafický frontend GRUB4DOS Installer. V něm vybereme náš USB flashdisk a zatrhneme položky "No backup MBR", "Disable PrevMBR", "Verbose output", do pole Timeout zadáme 0 a klikneme na tlačítko "Install". Parametry pro příkazovou řádku vypadají následovně:
grubinst.exe --pause --verbose --no-backup-mbr --mbr-disable-osbr --time-out=0 (hd2)
kde hd2 udává číslo fyzického disku. Dále je potřeba do kořenového adresáře flashdisku nakopírovat soubory grldr (vlastní jádro GRUBu) a menu.lst, což je textový soubor s definicí bootmenu, viz manuál. GUI GRUBu může jet buď ve textovém režimu nebo grafickém režimu VESA. Lze definovat i vlastní barvy a obrázek na pozadí. Balíček se všemi potřebnými soubory je ke stažení zde.
      GRUB označuje fyzické pevné disky jako (hd0) - primární master, (hd1) - primární slave, (hd2) - sekundární master, (hd3) - sekundární slave, atd. a disketové jednotky jako (fd0) - A:, (fd1) - B:. Oddíly na disku jsou pak číslovány dalším číslem: (hd0,0) - první oddíl na primárním master disku. Jednotky lze také vzájemně přemapovat. Každá položka v bootmenu začíná klíčovým slovem title a následuje nejčastěji příkazem chainloader, který načte systémový soubor operačního systému nebo bootsektor (z disku či z image). Pokud se bootuje systém z jiného disku, tak se ještě příkazy root / rootnoverify / find --set-root ... přenastaví kořen na jiný disk. U OS Linux se zadává přímo cesta ke kernelu příkazem kernel a případně initrd pro RAMDisk image. Výchozí položka bootmenu se nastaví příkazy default n (číslováno od 0) a timeout t v sekundách. Příkaz commandline spustí příkazovou řádku, kde si můžete jednotlivé příkazy vyzkoušet. Zde je ukázka mého jednoduchého menu.lst:

# GRUB4DOS Boot Menu

color blue/green yellow/red white/magenta white/magenta
timeout 5
default 0

title FreeDOS
chainloader /kernel.sys

title Windows XP/PE mini
chainloader /XP/ntldr

title AVG Linux
kernel /DOS/AVGLINUX/vmlinuz max_loop=255 vga=791 init=linuxrc
initrd /DOS/AVGLINUX/initrd.lzm

title HDD (hd0)
# swap flashdisk and HDD then load 1 sector from 1st partition and set root
map (hd0) (hd1)
map (hd1) (hd0)
chainloader (hd1,0)+1
rootnoverify (hd1,0)

title Floppy (fd0)
# load 1 sector from floppy and set root
chainloader (fd0)+1
rootnoverify (fd0)

title CommandLine
commandline

title Reboot
reboot



Odkazy na další zajímavé operační systémy zde.



Zpět

Aktualizováno 2.4.2014 v 3:31