OPERAČNÍ SYSTÉMY

   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
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.
      12.5.2016 vyšel nový FreeDOS kernel 2042, vývojová větev (zdrojáky) zde.
      29.12.2019 vyšel nový interpret příkazů FreeCOM 0.84-pre7.
      1.1.2021 POZOR: v nástroji Free FDISK 1.3.1 byla nalezena chyba, která spočívá v tom, že pokud disk používá LBA a byly na něm vytvořeny nějaké oddíly pomocí jiného nástroje, který nezarovnává na hranice CHS (např. fdisk z Linuxu), tak při vytvoření dalšího oddílu pomocí Free FDISKu může dojít k tomu, že se začátek nového oddílu bude částečně překrývat s koncem předchozího oddílu (nejvýše o 1 stopu). Při zápisu dat na konec předchozího oddílu tak může dojít k přepsání začátku oddílu vytvořeného Free FDISKem a tím pádem ke ztrátě dat na něm. Nový oddíl by měl být vytvořen tak, že se LBA hodnota konce předchozího oddílu + 1 převede na CHS a pokud při dělení vyšel nějaký zbytek, tak se zaokrouhlí na další stopu (tím vznikne malá mezera nevyužitých sektorů). UPDATE: výše zmíněný problém by měla řešit nová verze Free FDISK 1.3.3. Všiml jsem si ale další chyby Free FDISKu (týká se i starších verzí), že v informacích o rozdělení vypisuje chybně názvy oddílů a také jejich velikost ukazuje poněkud odlišně od FDISKu z MS-DOSu.
      31.8.2023 objevil jsem neoficiální verzi FreeDOS Kernelu s podporou GPT a FAT32 od Toma Ehlerta. FAT32 oddíl musí ležet pod hranicí 2 TB a z GPT disku je potřeba FreeDOS bootovat např. GRUBem s podporou GPT nebo z jiného disku s MBR.

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.


   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 (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. Bohužel kolem roku 2012 Udo Kuhnt ukončil další vývoj EDR-DOSu. Poslední verzi 7.01.08 WIP spolu s dalšími 5 OS (Caldera DR-DOS 7.03, FreeDOS build 2042, MS-DOS 7.10.2400, IBM PC DOS 7.1 build 1.19.Y2K a IBM OS/2 4.5 bez GUI) si můžete jako image pro virtuální stroje stáhnout zde.

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 real mode 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.
      Jako poslední novinku jsem objevil novou 32 / 64-bitovou verzi Necromancer's DOS Navigator 2.31.5461 (aktuálně 3.00.0003) pro DOS, Windows a Linux. Výhoda 64-bitů pro filemanager není moc podstatná (autor zmiňuje kalkulačku počítající s 256-bitovými čísly, více paměti pro editaci velkých souborů se zapnutým syntax highlightingem a podporu souborů větších jak 2 GB, pokud to filesystém dovolí), spíše naopak je zde omezení - program nemůže v DOSu přepnout do long mode z V86 mode, takže pokud používáte EMM386 / JEMM / QEMM..., tak vám nepůjde spustit. Spíše jde o zajímavé technologické demo, že už i DOS má svou první 64-bitovou aplikaci. Škoda jen, že v NDN chybí proti klasickému DOS Navigatoru v utilitách sériový terminál, který byl opravdu vymazlený. UPDATE: nová 64-bitová DOSová verze 3.00.0009 je nyní schopná běžet i s loadnutým správcem paměti JEMM s pomocí VCPI, pokud má PC více jak 4 GB RAM (nebo aspoň nějakou remapovanou paměť nad hranicí 4 GB).
      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 (bývalí zaměstnanci Linea, které koupila firma MetroWerks) 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. Více o historii DR-DOSu si můžete přečíst zde.


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 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 98 SE, 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.


 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ě.


RDOS není běžným klonem DOSu, ale spíše embedded OS inspirovaný jednoduchostí DOSu. Obsahuje i V86 mode emulátor DOSu a DPMI server, takže možná pod ním i nějaké DOSové programy poběží. RDOS je OpenSource multitaskingový systém napsaný v C a assembleru, který podporuje řadu moderních technologií jako např. multi-core (ale vystačí si i s 386), 64-bit long mode, ACPI a obsahuje řadu driverů: AHCI, USB, AC97 a HDA zvuk, tiskárny, síťovky včetně TCP/IP stacku a server/klient aplikací, VESA VBE grafiku a GUI s podporou TTF. Přečte souborové systémy FAT12/16/32. Pro větší bezpečnost a stabilitu využívá segmentaci. V porovnání s Windows je v řadě operací (např. práce se soubory) výrazně rychlejší.
      Na webu jsem nenašel žádný testovací image, takže jsem si stáhl zdrojové kódy z repozitáře SVN a přeložil je kompilátorem Open Watcom. Z jednotlivých modulů jsem pak sestavil image RDOS.BIN. Jelikož nemám žádné PC s UEFI, tak jsem ho zkoušel spustit pomocí bootloaderu GRUB, jak je popsáno v sekci "Booting RDOS with GRUB bootloader", ale RDOS mi vždy crashnul do crash debuggeru. A to jak na reálném PC, tak ve virtuálu. Zkoušel jsem různě ubírat nepotřebné moduly a použít starší doporučenou verzi Open Watcom kompilátoru, ale nic nepomohlo. Škoda, že už se patrně dál nevyvíjí. I tak je to ale zajímavé programátorské dílo, které může posloužit jako inspirace psaní DOSových ovladačů či knihoven.


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 20 adresních linek procesoru na 1 MB (2²⁰). 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é neboli konvenční paměti (00000 - 9FFFFh). Ano, jak kdysi prohlásil velký vizionář 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 v systému zprovoznit 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ů v pouzdrech 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 (2²⁴) fyzické paměti. Později u 32-bitového 80386 je to až 4 GB (2³²). 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í. Samotný DOS však z důvodu kompatability využívá i nadále 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 zavést ovladač rozšířené paměti XMM (eXtended Memory Manager), který programům poskytuje své služby přes INT 2Fh. Maximální velikost paměti XMS 2.0 je 64 MB a 4 GB pro 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 INT 31h. DPMI server se staral sám o přepínání do reálného režimu a zpět (též o transfer dat mezi oběma světy), když bylo třeba zavolat nějakou funkci DOSu nebo BIOSu.
      V MS-DOSu od verze 5.0 byl přítomen správce rozšířené paměti himem.sys, který využívá tzv. unreal mode pro přístup k celé paměti. 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řijde 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í. Poslední verze 5.79 ke stažení zde. 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 64-bitové aplikace (využití RAM nad 4 GB)
      MS-DOS je sice 16-bitový OS, ale nijak nebrání tomu, aby spouštěné aplikace či ovladače používaly 32-bitový chráněný režim nebo dokonce 64-bitový long mode. První vlaštovka v podobě Hello 64-bit World dema (včetně zdrojáku) od Michaela Chourdakise se objevila v roce 2015. Pak se dlouho nic nedělo a až v roce 2018 začal s 64-bitovým režimem experimentovat další kodér CandyMan, který mimo jiné napsal i vlastní 64-bitový operační systém SigmaOS podobný DOSu včetně pár aplikací (port FASM, debugger, filemanager a různá dema) a oživil DOSový extender D3X. Jeho dalším počinem je aktualizovaná 32 a 64-bitová verze filemanageru Necromancer's DOS Navigator pro DOS a Windows, zmíněná o pár stránek výše. Zatím poslední novinkou je 64-bitový ovladač EMS64, který umožňuje jinak nevyužitou paměť nad hranicí 4 GB používat dle standardu EMS 4.0, např. pro velký RAMDISK. Nevýhoda je, že tyto programy zatím neumí přepnout do long mode z V86 režimu (EMM386 / JEMM / QEMM...). Ke své funkci naopak vyžadují přítomnost XMS ovladače. Nechme se překvapit, jakou další 64-bitovou nadílku nám CandyMan připraví :)
      21.10.2020 Japheth vydal svůj OpenSource ovladač XMS paměti HimemSX, který rozšířil o podporu alokace tzv. Super-eXtended paměti (RAM nad 4 GB) až do velikosti 1 TB. Jde o rozšíření standardního XMS API (nyní povýšeného na verzi 3.50) o nové funkce: C8h - query free super-extended memory, C9h - allocate block of super-extended memory, CCh - lock a super-extended memory block, které pak můžou volat ostatní DOSové programy. Bohužel přetrvává podstatná nevýhoda, že nefunguje ve V86 režimu. Japhet také upravil program RDiskSX, který umí tyto nové XMS funkce využít pro vytvoření RAMDISKu v paměti nad 4 GB. Vzhledem k většímu overheadu je tento RAMDISK asi o 20% pomalejší. Program jsem otestoval na svém PC a funguje. UPDATE: Japheth vydal novou experimentální verzi JEMM386 5.80pre5, která umožňuje používat nové funkce HimemSX i v režimu V86, avšak na mém PC jsem narazil na konflikt s CWSDPMI, kdy mi spuštění jakékoliv DPMI client aplikace způsobilo crash JEMMu. Pokud jsem ale zavedl rezidentně Japhethův DPMI server HDPMI32, tak aplikace běžely normálně. UPDATE: Japheth našel chybu v modulu VCPI, která nekonzistentně přistupovala k poli XMS handlů a vydal novou opravenou verzi JEMM386 5.80pre8, která mi už funguje bez problémů.

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 od intelu pro řadiče v režimu AHCI: AHCICD.SYS 1.1 [12 kB]. Později se ukázalo, že tento ovladač nefunguje na nových chipsetech, které už podporují pouze AHCI bez režimu kompatability (nemají IDP registry pro přístup z real mode). V takovém případě by měl fungovat stejnojmenný ovladač AHCICD.SYS 1.1 [22 kB] od R. Loewa, který upravil Japheth (v baíčku je originál i upravená verze včetně zdrojáků). Ten k přístupu k MMIO využívá unreal mode a nefunguje tak v módu V86.
      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 podpora velkých sektorů (a disků)
      Jednou z možností, jak prolomit 2TB limit disků, je použití větších sektorů při zachování velikosti ostatních datových struktur souborového systému. U disket a disků se standardně předpokládá velikost sektoru 512 B. Některé nové disky umožňují přepnout např. na 4kB sektory. MS-DOS (a patrně i PC-DOS) lze jednoduchou úpravou přimět k tomu, aby s většími sektory pracoval (neplatí to však pro FreeDOS). To je možné 2 způsoby: buď se v config.sys zavede ovladač disku, který podporuje větší sektory (např. TurboDisk RAMDISK umí až 2kB sektory, pro nové HDD by se musel ovladač napsat) a jádro DOSu se tak automaticky přenastaví na větší sektory (teoreticky až do velikosti 8 kB) nebo modifikací jádra DOSu msdos.sys - je potřeba změnit 2 Byte, podrobný návod je zde (v souboru usbdrive.a36, od řádku 291). Pro MS-DOS 7.1 a Windows 98 existuje sada utilit TeraByte Plus Package 3.0 od R. Loewa, jenž obsahuje patchnutý io.sys, esdi_506.pdr + další VXD, utility pro rozdělení disku a formátování (rfdisk.exe, rformat.exe) a další. Je třeba upozornit na to, že spousta dalších systémových utilit pro DOS byla napsána s hardkódovanou velikostí sektoru 512 B a jejich spuštění by pak na disku s většími sektory nejspíš způsobilo poškození dat. Běžné programy, které využívají služeb DOSu, by měly fungovat normálně. Také je třeba počítat s tím, že DOSové buffery budou zabírat několikanásobně více paměti a tím se zmenší dostupná dolní paměť pro spouštění programů.

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.

      17.11.2015 Bohužel jsem zjistil, že intel na chipsetech řady 5x a novějších vypustil UHCI řadiče a připojil USB 2.0 porty přes huby přímo k EHCI, s čímž většina DOSových USB driverů nepočítá a tak najdou pouze EHCI řadič, ale už ne připojená koncová zařízení. Jedinou výjimkou je komerční program DOSUSB 2.0. Více o tom píšu ve svých zkušenostech s novou základní deskou Gigabyte GA-P67-DS3-B3.

DOS a WIN32 aplikace
      Hodilo by se vám občas v DOSu spustit nějakou Win32 aplikaci? S HX DOS Extenderem (starší verze na SourceForge) 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. Poslední verze 2.17 ke stažení zde
      15.2.2016 Ruslan Starodubov vydal novou verzi HX DOS 2.17+ rozšířenou o podporu moderních zvukových karet HDA (intel High Definition Audio). Vyzkoušel jsem s ní na mém Realteku ALC889 Quake II, zvuk sice šel, ale všechny zvuky se přehrávaly zrychleně, jako by byla nastavená vyšší vzorkovací frekvence. V DOSBoxu se zas ve všech hrách zvuk sekal - krátce přerušovaný asi 5 - 10x za vteřinu. Na notebooku s ADI1981B AC'97 nepřekvapivě nešel zvuk vůbec. Zatím to tedy pro mě není moc použitelné, ale třeba to někomu na jiném HW bude fungovat...
      8.3.2016 Ruslan aktualizoval knihovnu dpci.dll, která nově podporuje i zvukové kodeky AC'97. Na mém notebooku byla nyní zvukovka ADI1981B rozpoznána. Vyzkoušel jsem napřed Quake II, ale ten se při startu seknul. V DOSBoxu po vyladění CPU cycles na hodnotu cca 18000 fungoval zvuk celkem bez sekání ve hrách Doom, Duke Nukem 3D a Dynablaster. Avšak ve všech hrách se projevovalo nepříjemné zpoždění zvukových efektů asi o 0,5 vteřiny. Nicméně je to pokrok, lepší než drátem do oka :).

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é. Intel a Realtek stále ještě DOSové ovladače podporují. Lze také rozchodit nějaké staré PCMCIA WiFi karty.
      I v dnešní době vznikají nové projekty na DOSové síťování, např. EtherDFS, jehož autorem je Mateusz Viste. Tento program umožňuje v DOSu mapovat síťové disky z linuxového serveru a používá k tomu nejnižší vrstvu raw Ethernet rámců. DOSový klient je v podstatě rezidentní FS driver, který potřebuje jen zavedený packet driver pro síťovou kartu. Linuxový server je dodáván v podobě zdrojových kódů a též jsou k dispozici i binární balíčky pro známé linuxové distribuce včetně Raspbianu pro Raspberry Pi.
      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ů 1280 x 1024 a 1600 x 1200, 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.17 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, balík mTCP obsahující i malý FTP a HTTP server. 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.




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, WavPack, MP2/MP3, MPC, OGG/VORBIS, OGG/OPUS, WAV, WMA, WV, pomocí plug-inu 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čů portovaných z Linuxu, 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 emulujícícmi Sound Blaster. Nedávno byla funkce otestována i s novou PCI-E zvukovkou SB Audigy Rx. V novější verzi MPXPlay 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. MPXPlay 1.60 beta též obsahuje vlastní enkódovací plug-iny pro AAC, MP3, OGG, FLAC a WavPack. Zatím chybí podpora souborů MIDI, které lze přehrát např. portovaným programem TiMidity 0.2g, ke kterému je potřeba stáhnou ještě 8MB banku samplů (původně určených pro GUS).
      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. Později jsem do PC přidal druhou PCI zvukovou kartu, která v DOSu lépe emuluje Sound Blaster a funguje i na novějších základních deskách s PCIe chipsety.
      10.3.2023 Po mnoha letech došlo na poli podpory zvuku k zásadnímu průlomu, když uživatel Crazii na VOGONS fóru zveřejnil svůj OpenSource emulátor Sound Blasteru SBEMU, který funguje v RM i PM na moderních PCI zvukovkách SB Live!, Audigy 1/2/4, AC'97 a HDA. Využívá k tomu ovladače z přehrávače MPXPlay.
      Pro přehrávání videa existuje komerční program QuickView Pro od MultiMediaWare, který zvládne i MOV, MPEG2 a MPEG4, poslední verze 2.60 též h264. Umí také běžné hudební soubory MPx, OGG, WAV a obrázky. Ovládá se přes textové rozhraní s menu. Pro grafický výstup podporuje VESA VBE 2.0 a na starších GPU (např. v mém notebooku ATI Mobility Radeon 7500) umí využít i hardwarové škálování videa. Pro zvukovky používá buď DOSové ovladače od výrobce nebo externí plug-iny, kde nechybí podpora SB Live! Nedávno se objevil nový ovladač PCI.SDR od Ruslana Starodubova, který přidává podporu moderních PCI zvukových karet Intel HDA, AC'97, SB Audigy 1/2/4, VIA a další. Jde vlastně pouze o wrapper kódu ovladačů, které používá MPXPlay, jenž byly původně převzaty z Linuxu. Aby QuickView ovladač použil, je potřeba ho spustit s parametrem -WE$pci.sdr. Úspěšně jsem ho otestoval na SB Audigy 2 a AC'97 kodeku ADI1981B + ICH4.
      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. 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.
      23.1.2017 se objevila neoficiálně novější verze MPlayer 1.3.0 SVN-r37916, která nyní obsahuje podporu PCI zvukových karet SB Live! a Audigy. Úspěšně jsem ho otestoval na své SB Audigy 2. V konfiguráku je třeba změnit parametr zvukového výstupu na ao=au:volume=15, kde volume [0-100] je výstupní úroveň HW mixéru. Po ukončení přehrávání mi MPlayer rozbije obrazovku, takže musím znovu inicializovat textový režim. To jsem vyřešil jednoduše přidáním volání své utility set8025.com na konec svého dávkového souboru pro spouštění MPlayeru.
      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čí.

DOS a antiviry
      DOSové verze legendárních českých antivirů AVG 6.0 a AVAST 7.70 už dávno zmizely v propadlišti dějin. Nedávno jsem ale objevil jeden dosud aktualizovaný (2016) DOSový antivirus VirScan Plus od švédské firmy ROSE (rozhraní programu je v němčině). Shareware verze zdarma je použitelná, akorát neobsahuje heuristickou analýzu a nepodporuje generovaní hledacích řetězců pro nové viry.

(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í... UPDATE: další podobný OpenSource projekt se jmenuje FluxEngine a je postavený na PSoC5 LP od Cypressu.
      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.


DOSBox-X a emulace DOSu pod DOSem
      Jedním z forků populárního emulátoru DOSBox je verze DOSBox-X, která přidává různé funkce navíc včetně možnosti spouštět Windows 3.x a 9x. K dispozici jsou standardně buildy pro Win32, Linux, MacOS a DOS, x86/x64/ARM32/ARM64. Někoho možná překvapí proč DOS. Na nových PC, pokud spustíme DOS nativně, tak už řada věcí nefunguje tak dobře a kompatabilně jako na starých PC (bude nám třeba chybět reálný GUS, SB16, korektní podpora Hercules, CGA, EGA), navíc pro některé staré hry můžou být dnešní CPU příliš rychlé. Přesto si třeba budeme chtít zahrát nějakou hru bez nutnosti přebootovávat z DOSu do jiného OS, což nám umožní speciální verze DOSBox-X upravená pro běh pod HXDOS extenderem (minimální podpora Win32 API pro DOS). V upravené verzi HXDOSu je možné rozběhnout zvuk i na novějších onboard zvukovkách.
      Nyní se objevila další neoficiální varianta DOSBox-X pro DOS/Linux, která využívá na míru šité minimalistické distribuce Linuxu, která se spouští z DOSu pomocí loadlinu. Start je velmi rychlý, asi 1 - 2 vteřiny. V nové verzi z 1.1.2021 [12 MB] přibyly drivery pro disky a zvukové karty se systémem ALSA, takže už je to použitelné i na reálném HW, ne jen v QEMU, avšak k tomu je po startu ještě potřeba pár triků. Pomocí klávesové kombinace CTRL+ALT+F1 se přepneme do linuxové konzole, kde se přihlásíme jako root (bez hesla). Spustíme alsamixer a zvýšíme master hlasitost z 0 na nějakou použitelnou hodnotu. Pak je třeba někam přimountovat náš DOSový oddíl, např. mount /dev/sdb9 /mnt (místo sdb9 si dosaďte váš oddíl). Pomocí klávesové kombinace CTRL+F2 se přepneme zpět do obrazovky DOSBox-X a připojíme náš oddíl třeba jako disk D: příkazem mount d /mnt a pak už můžeme spouštět DOSové programy. Zvuk mi fungoval na SB Audigy normálně, ale zaznamenal jsem problémy s VESA LFB grafikou, kdy např. Quake při přepnutí do vyššího rozlišení kompletně zatuhnul celý systém a bylo nutno zmáčknout tlačítko RESET. Jak jsem zjistil, toto chování závisí na vybraném videomódu s kterým se spouští linuxový framebuffer. Toto nastavení lze změnit v souboru linux.par, kde je parametr vga=788. Pokud jsem použil vyšší TrueColor módy jako např. 842 (1600 x 1200 / 32 bpp) či 795 (1280 x 1024 / 32 bpp), tak Quake naběhl normálně v 1024 x 768, které jsem tam měl dříve nastavené. Když jsem ale v menu přepnul na jiné rozlišení, tak to zase vytuhlo, takže to ještě bude chtít doladit. Podotýkám, že z DOSBox-X se už nelze vrátit do DOSu jinak než restartem.
      Linuxový souborový systém běží z RAMDISKu a je připojen jako read-only. Pokud bychom chtěli provést nějakou trvalou změnu (např. v nastavení mixéru či mountování), je potřeba pod linuxem s nainstalovaným balíčkem squashfs-tools a podporou komprese zstd upravit initrd image soubor dosbox-x.sqf (souborový systém SquashFS). Image se rozbalí do pracovního squashfs-root adresáře příkazem unsquashfs dosbox-x.sqf, upravíme obsah (např. souborů /etc/inittab, /etc/init.sh, /etc/fstab), /etc/fstab a vytvoříme nový image příkazem mksquashfs squashfs-root dosbox-x.sqf -comp zstd -b 256K -no-recovery -all-root -no-xattrs -not-reproducible -no-exports -all-time $(date +%s) -Xcompression-level 22 a zkopírujeme ho do našeho adresáře DOSBOX-X v DOSu. Já jsem si takto upravil hlasitost v mixéru na SB Audigy a přidal automountování DOSových oddílů. Můj upravený balíček je ke stažení zde.
      9.1.2021 Grapeli vydal další aktualizaci s novým 64-bitovým kernelem, který v sobě zahrnuje podporu nouveaufb pro grafické karty nVidia. Zaznamenal jsem, že vykreslování v Quake je cca 2x rychlejší v porovnání s předchozí verzí. Můj VESATEST změřil propustnost LFB cca 450 MB/s. Také lze bez problému přepínat rozlišení, akorát s omezením, že okno DOSBoxu musí být menší než rozlišení framebufferu. Např. já mám nativní rozlišení FB 1600 x 1200, takže musím nastavit omezení v DOSBoxu tak, aby poskytoval rozlišení nejvýše 1280 x 1024, což lze nastavit v /etc/dosbox-x.conf proměnnými vesa modelist width limit = 1280 a vesa modelist height limit = 1024. Můj upravený balíček je ke stažení zde.

---

   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. Zatím jsem si nezkusil upéct vlastní linuxovou distribuci, jako třeba VDL, na tolik hraní už není čas. 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. Pro zajímavost, upravený Linux kernel může běžet i na procesorech 8086/286 - projekt ELKS.
      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á:

      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 (pro novější Debian je vhodnější použít tuto variantu image obsahující i nonfree firmware pro různý HW potřebný k instalaci). 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)

      20.1.2016 Při aktualizaci jádra z verze 3.16.5 na 4.3.3 se mi zas rozbil binární ovladač nVidie a nepomohlo ani DKMS. Resp. kernel modul se přeložil správně, ale nepodařilo se ho zavést, jelikož nebyly nalezeny odkazy na funkce mtrr_add() a mtrr_del() v jádře, přestože mám podporu MTRR v kernel configu zapnutou. Chybová hláška "Kernel module load error: insmod: ERROR: could not insert module ./kernel/nvidia.ko: Unknown symbol in module" je dále popsána zde. Nepomohla ani aktualizace na poslední verzi balíčku ovladače nvidia-legacy-304xx-driver_304.131-2_i386.deb Novější verzi nvidia-legacy-340xx-driver nemůžu použít, protože už nepodporuje starší GeForce řady 7xxx. Jak jsem pochopil, vývojáři kernelu se rozhodli výše zmíněné 2 funkce nahradit jinými a tak je sice úplně nezrušili, ale schovali (smazali jen exporty, takže nejsou zvenku ostatními moduly vidět). Náprava je naštěstí jednoduchá: ve zdrojovém souboru kernelu /src/arch/x86/kernel/cpu/mtrr/main.c je potřeba za definici funkce mtrr_add() doplnit řádek EXPORT_SYMBOL(mtrr_add); a stejně tak pro funkci mtrr_del() doplnit řádek EXPORT_SYMBOL(mtrr_del); a znovu přeložit jádro. Po té se už nVidia kernel modul zavedl bez problému.
      Další průser jsem čekal u VMware Workstation, což se hned potvrdilo, neboť nešly přeložit jaderné moduly vmmon a vmnet. Navíc, jak jsem k nelibosti zjistil, tak VMware přestalo od verze 11.x podporovat 32-bitové OS a už vydávají jen 64-bitové verze. Poslední 32-bitová verze pro Linux je patrně 10.0.6 a ani ta mi nefungovala. Musel jsem ručně rozbalit zdrojové balíčky modulů /usr/lib/vmware/modules/source/vmmon.tar, /usr/lib/vmware/modules/source/vmnet.tar a následně je zkoušel přeložit a hledal co proč nefunguje. Nakonec se mi povedlo z více míst na Internetu posbírat různé patche a oba moduly úspěšně přeložit. Zde je můj balíček patchů pro verzi 10.0.6 otestovaný na kernelu 4.3.3. Po opatchování jsem moduly zabalil a vrátil zpět na místo. VMware si je při prvním spuštění zkompiloval, zavedl a vše zas fungovalo normálně. Bohužel se API mění každou chvíli, takže s nějakou novější verzí jádra se to rozbije znova. To je možná také jeden z důvodů, proč řada komerčních SW firem nechce vyvíjet porty svých aplikací pro Linux(y). Na Windows mají totiž celkem solidní šanci, že aplikace půjde spustit i třeba po více než 10 letech na nejnovější verzi OS. Poslední verze Windows 8 a 10 jsou ale děsný výblitek, tak bych opravdu uvítal nějakou použitelnou alternativu, jenže tou pro mě Linux bez klíčových aplikací stále není... :(

Aktualizace Debian Jessie a kompilace ovladače USB WiFi modulu s RTL8812BU
      27.4.2023 Po delší době jsem zas potřeboval trochu zaktualizovat svůj starý Debian Jessie, protože mi po upgrade grafické karty z nVidia GTX 670 na GTX 970 přestal fungovat Xorg, neboť starý driver 304.131 už GTX 970 nepodporuje. Po zadání příkazu apt-get update mě čekalo 1. nepříjemné překvapení v podobě chyby:
E: Ovladač metody /usr/lib/apt/methods/https nemohl být nalezen.
N: Je balík apt-transport-https nainstalován?
Musel jsem tedy ručně stáhnout a nainstalovat balíček apt-transport-https_1.0.9.8.4_i386.deb, ale ani tak jsem nezískal seznam aktualizací, protože Jessie už vypadla z fáze old stable někam do propadliště dějin a oficiální servery repozitářů s balíčky už vracely jen Error 404. Bylo tedy třeba najít archivní a alternativní servery a zapsat je do /etc/apt/sourcers.list:

# Jessie archive/backports deb http://archive.debian.org/debian/ jessie main non-free contrib deb-src http://archive.debian.org/debian/ jessie main non-free contrib deb http://archive.debian.org/debian/ jessie-backports main contrib non-free deb-src http://archive.debian.org/debian/ jessie-backports main contrib non-free deb http://deb.freexian.com/extended-lts jessie-lts main contrib non-free deb-src http://deb.freexian.com/extended-lts jessie-lts main contrib non-free

Pak se konečně začaly stahovat seznamy balíčků, ale APT si stěžovalo na prošlé/chybějící certifikáty serverů:

root@MR:~# apt-get update W: Chyba GPG: http://deb.freexian.com jessie-lts InRelease: Následující podpisy nemohly být ověřeny, protože není dostupný veřejný klíč: NO_PUBKEY A07310D369055D5A W: Chyba GPG: http://archive.debian.org jessie-backports InRelease: Následující podpisy jsou neplatné: KEYEXPIRED 1587841717 KEYEXPIRED 1668891673 W: Chyba GPG: http://archive.debian.org jessie Release: Následující podpisy jsou neplatné: KEYEXPIRED 1587841717 výpis expirovaných klíčů: root@MR:~# apt-key list | grep ila pub 4096R/C857C906 2014-11-21 [platnost skončila: 2022-11-19] pub 4096R/518E17E1 2013-08-17 [platnost skončila: 2021-08-15] pub 4096R/46925553 2012-04-27 [platnost skončila: 2020-04-25] pub 4096R/65FFB764 2012-05-08 [platnost skončila: 2019-05-07] pokus o jejich aktualizaci: root@MR:~# apt-key update gpg: klíč 65FFB764: "Wheezy Stable Release Key " beze změn gpg: klíč 46925553: "Debian Archive Automatic Signing Key (7.0/wheezy) " beze změn gpg: klíč 518E17E1: "Jessie Stable Release Key " beze změn gpg: klíč 2B90D010: "Debian Archive Automatic Signing Key (8/jessie) " beze změn gpg: klíč C857C906: "Debian Security Archive Automatic Signing Key (8/jessie) " beze změn gpg: klíč 1A7B6500: "Debian Stable Release Key (9/stretch) " beze změn gpg: klíč F66AEC98: "Debian Archive Automatic Signing Key (9/stretch) " beze změn gpg: klíč 8AE22BA9: "Debian Security Archive Automatic Signing Key (9/stretch) " beze změn gpg: klíč 77E11517: "Debian Stable Release Key (10/buster) " beze změn gpg: klíč 3CBBABEE: "Debian Archive Automatic Signing Key (10/buster) " beze změn gpg: klíč CAA96DFA: "Debian Security Archive Automatic Signing Key (10/buster) " beze změn gpg: klíč 0D6C9793: "Debian Stable Release Key (11/bullseye) " beze změn gpg: klíč 8DD47936: "Debian Archive Automatic Signing Key (11/bullseye) " beze změn gpg: klíč 4AAD5C5D: "Debian Security Archive Automatic Signing Key (11/bullseye) " beze změn gpg: Celkový počet zpracovaných klíčů: 14 gpg: beze změn: 14 root@MR:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com C857C906 root@MR:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com 518E17E1 root@MR:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com 46925553 root@MR:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com 65FFB764 root@MR:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com A07310D369055D5A některé se se podařilo zaktualizovat a některé ne: root@MR:~# apt-key list | grep ila pub 4096R/518E17E1 2013-08-17 [platnost skončila: 2021-08-15] pub 4096R/65FFB764 2012-05-08 [platnost skončila: 2019-05-07] root@MR:~# apt-get update W: Chyba GPG: http://archive.debian.org jessie-backports InRelease: Následující podpisy jsou neplatné: KEYEXPIRED 1587841717 KEYEXPIRED 1668891673 W: Chyba GPG: http://archive.debian.org jessie Release: Následující podpisy jsou neplatné: KEYEXPIRED 1587841717

Nicméně po potvrzení, že nejde ověřit důvěryhodnost zdroje, jdou balíky normálně instalovat. Podařilo se mi nainstalovat novější verzi nvidia-legacy-390xx-driver (390.154) z backportů pro Buster (backporty pro Jessie obsahují poslední verzi 340.106 a ta ještě GTX 970 nepodporuje), DKMS bez problému přeložil kernel modul a grafika se rozběhla.
      Další hraní nastalo s USB WiFi modulem LGSWFAC81 založeným na čipu Realtek RTL8812BU o kterém jsem psal níže. Můj kernel 4.3.3 obsahuje modul rtl8821ae (potřebuje ještě balíček firmware-realtek), který podporuje pouze starší typ RTL8812AE a nikoliv RTL8812BU (ten byl přidán až do 5.x kernelu). Nicméně jsem na GitHubu našel driver, který je kompatabilní s 4.x i 5.x kernelem. Pro jeho použití jsem musel ještě doinstalovat balíček rfkill. Rovnou jsem také přidal USB VID, PID svého WiFi modulu do souboru os_dep/linux/usb_intf.c, abych pak nemusel pro něj vytvářet udev rule:

#ifdef CONFIG_RTL8822B /*=== Realtek demoboard ===*/ {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0xB82C, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Default ID for USB multi-function */ {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0xB812, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Default ID for USB Single-function, WiFi only */ /*=== Customer ID ===*/ {USB_DEVICE_AND_INTERFACE_INFO(0x13b1, 0x0043, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Alpha - Alpha*/ {USB_DEVICE_AND_INTERFACE_INFO(0x043e, 0x3108, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* LGSWFAC81 by RayeR */ #endif /* CONFIG_RTL8822B */

Tato sekce se kompiluje na základě konfigurace v Makefile, kde je v sekci "WIFI IC" vybrána volba "CONFIG_RTL8822B = y" (ostatní jsou vypnuté). Pak jsem modul 88x2bu.ko normálně zkompiloval a nainstaloval přes make install. Po připojení WiFiny ji systém správně rozpoznal, nahodil jsem ji a otestoval ve wifi-radaru...

root@MR:~# ip link set wlxf0f0f0f0f0f0 up root@MR:~# iw wlxf0f0f0f0f0f0 info Interface wlxf0f0f0f0f0f0 ifindex 7 wdev 0x1 addr f0:f0:f0:f0:f0:f0 type managed wiphy 0

Až na to budu mít čas, zkusil byl Jessie aktualizovat na Stretch, to by mělo oficiálně jít, zde je to popsáno stručněji. Radši bych před tím zazálohoval celý oddíl.

---

ELKS (Embeddable Linux Kernel Subset)
      21.1.2020 Když jsem loni na podzim opravoval jednu starou 286 základní desku, přemýšlel jsem, co bych na ní mohl zkusit spustit za operační systém kromě DOSu a Windows a vzpomněl jsem si na ELKS, o kterém jsem kdysi četl. Linux se zaměřuje na novější 32-bitové CPU s MMU, ale byla tu i snaha dostat Linux na starší/jednodušší 16-bitové stroje s omezenou velikostí paměti a tak vznikl ELKS. Běží v reálném módu na CPU 8086, 186, 286, NEC V20, V30, atd. a může tak oživit starý HW, např. Psion 3 i novější embedded mini PC desky. ELKS vznik před více než 20 lety, ale i dnes je stále vyvíjen a zdrojáky si můžete stáhnout z GitHubu. Instalace a kompilace není nijak složitá, kompiloval jsem na svém PC ve 32-bitovém Debian Linuxu. Po stáhnutí a rozbalení zdrojáků do nějakého adresáře je třeba nejprve spustit skript . tools/env.sh, který nastaví pár proměnných jako např. TOPDIR. Připomínám, že tečka na začátku příkazu je důležitá proto, aby proměnné zůstaly nastavené i po ukončení běhu skriptu. Pak spustíme skript tools/build.sh, který postahuje a zkompiluje buildovací toolchainy - překladač GCC-IA16, binutils, emu86 (uloží se do podadresáře cross), mezitím si můžete jít na kafe.
      Dále spustíme make menuconfig a objeví se nám klasický menuconfig jako pro linuxový kernel, akorát s poněkud menším počtem voleb. Můžete vybírat různé fíčury architektury, pár ovladačů, filesystémů a další utility, které se budou překládat. Důležité je vybrat správně cílový image - typicky image soubor diskety o různé kapacitě. Lze vybrat buď souborový systém MINIX nebo FAT. Zde bych upozornil, že podpora FAT zatím není úplná a z image s FAT nelze bootovat! Proto vyberte MINIX a zaškrtněte volbu "bootable". Tím je bohužel kapánek znesnadněn přístup k souborům na image z DOSu a Windows, na Linuxu ho není problém přimountovat. Nakonec po uložení konfigurace spustíme make all a v podadresáři image by měla vzniknout binárka, např. fd1440.bin. Tu pak můžeme pomocí dd či rawrite přesypat na disketu, či předhodit virtuálu a vesele boootovat. Zde je video, jak ELKS běhá na výše zmíněné 286 z 3,5" diskety.
      Přece jen mi to nedalo a pokusil jsem se jádro ELKSu elks/arch/i86/boot/Image resp. soubor /linux v kořenovém adresáři MINIX FS nabootovat pomocí GRUB4DOSu, SysLinuxu a bootsektoru z FreeDOSu, ale bez úspěchu. Samotný linux image soubor se skládá ze 3 částí: RAW bootsektor (elks/arch/i86/boot/bootsect, není kompatabilní s FAT FS), pomocný program, který zjišťuje nějakou HW konfiguraci a nastavuje parametry (elks/arch/i86/boot/setup) a samotné jádro (elks/arch/i86/boot/system). V případě MINIX FS se ale spouští jiný bootsektor, který je součástí prvního 1kB bloku (elkscmd/bootblocks/minix.bin) a ten v kořenovém adresáři najde a načte linux image soubor. Zároveň musí tento image soubor rozdělit na 2 části: RAW bootsektor sektor se setupem kopíruje na adresu 0100:0000h a jádro na adresu 1000:0000h. Nakonec předá řízení setupu na adrese 0100:0200h. Když jsem celý linux image soubor zapsal pomocí rawrite na disketu (takže BIOS načetl a spustil jeho RAW boot sektor), tak se ELKS kernel spustil, ale nemohl najít nepřekvapivě root FS a čekal s pauzou na vložení root FS diskety, ale ani když jsem mu dal root FS disketu ve FAT formátu, tak z ní dál nepokračoval.
      16.2.2020 Po té, co jsem na GitHubu rozvířil debatu na téma bootování z FAT12 image, tak se poměrně v krátkém čase podařilo nakódovat nový FAT-kompatabilní bootsektor, který umí správně zavést linux image. V menuconfigu pak u položky FAT image přibyla volba bootable. Díky tomu lze nyní snáze na disketě přenášet data mezi ELKSem a DOSem / Windows. Novou verzi ELKSu na FAT disketě jsem znovu otestoval na mé 286 a funguje správně.

---

   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é plug-iny. 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.

---

   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

   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.
      22.1.2020 Nedávno jsem se díval, co je zde nového a jak se zdá, tak i projekt Syllable nakonec vyhnil a celé doména je nyní mimo provoz. Poslední vydanou verzí tak bylo live CD 0.6.6 a instalačka 0.6.7, která se dá najít na SourceForge.

---

   Projekt ReactOS si klade velice ambiciózní cíl - vytvořit OpenSource klon Windows NT4/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/chybí.
      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:

• výběr typu PC "Standard PC Multiprocessor" vede na chybu "Error loading imported dll" při bootu v textovém režimu hned po přejetí progress baru
• výběr typu PC "ACPI PC Multiprocessor" vede na zátuh bez výpisu chyby při bootu v textovém režimu hned po přejetí progress baru
• výběr češtiny při instalaci vede na zatuhnutí po registraci součástí

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, 192 MB RAM a 40 GB WD HDD. 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ší.
      6.11.2014 Do nové verze ReactOSu 0.3.17 byla přidána experimentální verze NTVDM, která by měla být schopná spouštět většinu 16-bitových DOSových programů. 32-bitové DOSové programy (DPMI) zatím nejsou podporovány stejně jako grafické režimy VESA.
      16.2.2016 byla vydána nová verze ReactOS 0.4.0 s celou řadou vylepšení, zejména subsystému NTVDM, který nyní podporuje i 32-bit PM programy a DPMI. Zatím jsem nový ReactOS vyzkoušel nainstalovat akorát ve VMWare a podařilo se mi tam spustit Doom (v okně, bez zvuku). Přepínání na fullscreen pořádně nefunguje, dole byla pořád vidět lišta a část desktopu. Při spuštění jakéhokoliv programu kompilovaného v DJGPP vyskočí podivná chybová hláška "Exception: Invalid Opcode occured at CCCC:CCCC, Opcode: FF FF FF FF FF FF FF FF FF FF", ale po odkliknutí se program normálně rozběhne. Podpora VESA je zatím dost neúplná. NTVDM má řadu chyb a bezpečnostních děr, jedním programem se mi podařilo dokonce zatuhnout celý systém. Ale zdá se, že je to na dobré cestě...
      29.3.2016 Znovu jsem zkusil nainstalovat ReactOS na starém PC s Pentiem Pro 200 MHz, 192 MB RAM a otestoval nový NTVDM v reálu. Je to fakt požitek, viz video.
      14.1.2020 Po téměř 4 letech jsem si zase zkusil na stejnou retro mašinu s Pentiem Pro nainstalovat novou verzi ReactOSu 0.4.12. Při instalaci doporučuji ponechat výchozí anglické prostředí a moc nevrtat do nastavení GUI instalátoru, neboť mi první instalace vytuhla, nepodařilo se ji ani po restartu dokončit a musel jsem začít znovu načisto. Instalace trvala 17 minut. Boot systému se prodloužil na 47 s, po startu obsadí 119 MB RAM a při nečinnosti vytěžuje CPU na 5 - 9%. Grafické prostředí je stále dost trhané, třeba ovládací panely s ikonami se vykreslovaly 15 vteřin. Proti tomu i Windows XP SP2 běží poměrně použitelně (podobně jako WinNT 4.0), s vytížením CPU 3% v klidu a obsazenými 70 MB RAM. Při změně velikosti fontů z 96 na 120 DPI v nastavení Display se mi jednou podařilo vyvolat modrou smrt.


      Pokusil jsem se nainstalovat ovladače grafické karty Matrox Millennium II 5.82.018 pro Win2k/XP - setup.exe nefunguje, tak jsem instaloval ručně přes INF soubor ve Správci zařízení a po restartu na úvodní grafické obrazovce s logem a progressbarem systém vytuhnul. Přes klávesu F8 jsem zkoušel spustit SafeMode, ale bez úspěchu a tak jsem instaloval znovu (ano, měl jsem si to před tímto pokusem zálohovat). Zkusil jsem i starší ovladače 5.01.007 pro WinNT 4.0, ale ty ReactOS odmítá nainstalovat. Upravil jsem tedy INF soubor z ovladačů pro Win2k/XP tak, aby nainstaloval soubory ovladače pro WinNT 4.0. Sice se je podařilo nainstalovat, ale po restartu jsem se dostal jen o kousek dál a po kontrole disků mě čekala modrá smrt: "STOP: 0x000000B4 - The video driver failed to initialize." (tentokrát už jsem měl zálohu, tak byla obnova rychlá), vzdávám to.
      Dále jsem zkusil, jak si ReactOS poradí s USB flashkou. Na interním USB 1.1 řadiči intel PIIX3 vůbec flešku nedetekuje, ale na přídavném PCI USB 2.0 řadiči NEC uPD720101 ji najde a zobrazí obsah. Souborový manažer Servant Salamander 2.54 nejde spustit (při předchozím testu ve VMWare šel). Starší verze 2.0 spustit jde, ale není moc použitelná, např. se nezobrazují položky menu. O něco lépe je na tom ještě starší verze 1.52, ale i ta píše chybu o nedostatku paměti při výběru disku v panelu a někdy po zkopírování souboru zatuhne. Samotný ReactOS Explorer je ale ještě tragičtější, po spuštění mi vždy nějak vytuhne, že nejsem schopen ani přejít z My Documents do jiného adresáře. Subsystém NTVDM doznal mírného zlepšení, programy kompilované v DJGPP píšou výjimku "Invalid Opcode occured at CCCC:CCCC, Opcode: FF FF FF FF FF FF FF FF FF FF" až při ukončení běhu, ale větší programy jako gcc.exe nebo ld.exe crashnou. Doom se spustí po 9,5 minutách (zobrazení menu), rychlost překreslení je asi 1 snímek za půl minuty. Inu, žádný velký pokrok v optimalizaci a použitelnosti ReactOSu na starých PC jsem nezaznamenal, ale někdy příště zas novou verzi otestuju.
      16.12.2021 vyšel ReactOS 0.4.14 a tak jsem ho zkusil nainstalovat na mé retro PC s Pentiem Pro. Samotná instalace proběhla bez problémů a vcelku rychle. Avšak pro prvním spuštění, když jsem zkusil v nastavení obrazovky vybrat nějaký obrázek na pozadí (tuším že oblohu), tak se systém zaseknul a po resetu už nenaběhnul - objevila se modrá smrt v modulu win32k.sys: "STOP: 0x00000D3 (0xFAF4100, 0xFFFFFFFF, 0x00000000, 0x809776A6), The driver mistakenly marked a part of its image pageable instead of non-pageable." a nezbylo než systém smazat a znovu nainstalovat. To samé se mi stalo i po druhé instalaci. Na 3. pokus jsem to už radši nepokoušel a systém hned po instalaci zazálohoval. Boot systému se prodloužil na 52 s, po startu obsadí 95 MB RAM a při nečinnosti vytěžuje CPU na 6 - 8%. Rychlost odezvy GUI se asi o něco zlepšila, ale proti Windows se to stále nedá srovnat. ReactOS Explorer byl opraven, není zrovna nejrychlejší, ale už se dá používat. Problémy se Servant Salamanderem stále přetrvávají. Taktéž Matroxí ovladače grafiky stále nejdou nainstalovat, resp. způsobí zatuhnutí při bootu. DJGPP programy stále vyhazují výjimku nebo zatuhnou. Doom se spustí po 12:20 minutách (začátek automaticky přehrávaného dema) a rychlost překreslení je 1 snímek za 15 s, v samotné hře pak ještě výrazně pomalejší. Mikro Manažer se spustí za 36 s a dá se i používat.

---

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 2.0 driver.
      Náš milý Micro$oft už ňákou dobu 98čky nepodporuje, 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 winpack.org (UPDATE: už jsou zrušené, takže nSP, další utility a ovladače pro Win98 hostuju zde), kde si můžete stáhnout neoficiální servicepack (nSP). 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ší.
      Pokud máte moderní základní desku, která má pouze USB 3.0 (xHCI) řadič, tak vám USB ve Win9x nebude fungovat vůbec, ani v nejpomalejším režimu 1.1. V takovém případě je jediné řešení koupit rozšiřující USB2.0 PCIe kartu s řadičem Moschip MCS9990 nebo VIA VT6212 (používá PCIe2PCI můstek od Pericomu) - ta by měla být ověřená více uživateli.

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. Pokud vám tuhne instalátor setup.exe, zkuste místo něj spustit setupcor.exe (nelokalizovaná verze setupu s méně bugy). 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. UPDATE: po jeho smrti v roce 2019 je patch volně ke stažení zde a zde.
      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. Pozor na karty s označním 7800GS, ty mohou obsahovat jak starší čip G70 podporovaný oficiálními drivery, tak novější čip G71 (oba uměle limitované z 24 -> 16 pixel pipelines / 8 -> 6 vertex pipelines / 24 -> 16 TMUs / 16 -> 8 ROPs). Pro novější řadu GeForce 79x0 (čip G71) a experimentálně 8xxx (čip G80) 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. UPDATE: problém karet s > 256 MB paměti by měl vyřešit patch NVSIZE 3.0 od R. Loewa, ale nemám k dispozici žádnou 512MB kartu řady 7xxx, abych to vyzkoušel. Později jsem na Danovo přání patch backportoval do ovladače verze 77.72, který lépe funguje s některými hrami. Dan ho pak otestoval na GeForce 7800GT AGP s čipem G70 a 512 MB paměti.
      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 zkriplené 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) na moderních základních deskách
      Řada experimentů prokázala, že Windows 98 (SE) je možné s jistými omezeními nainstalovat i na moderních základních deskách pro intel Skylake nebo Ryzen 1. i 2. generace, jak demonstruje např. toto video a tento příspěvek. Je třeba si uvědomit, že Win98 nemají tušení, jak používat moderní periferie, neboť za těch 20 let se výrazně změnily programátorské interfejsy (nikdo nevyvíjí nové ovladače) a legacy kompatabilita se v posledních letech vytrácí. Pro rozumný běh systému potřebujeme rozchodit alespoň řadič disků, grafiku, zvukovku, síťovku a USB. Proto se velmi hodí, když máme základní desku s klasickými PCI sloty, ale dnes již jde spíše o raritu, např. Gigabyte GA-Z170-HD3 či GA-Z370-HD3P pro intel nebo Gigabyte GA-AB350M-D3H či Asus PRIME B350-PLUS pro AMD. Pak máme možnost použít starší PCI řadiče (IDE, SATA, USB, LAN...), pro které ještě výrobce dodával ovladače pro Win9x. Pokud PCI slot není, je možno vyzkoušet různé PCIe2PCI adaptéry s můstky od Pericomu či ASMedia. Jsou levné, ale ne vždy a se všemi PCI kartami fungují.
      Onboard řadič SATA disků (u některých desek i NVMe) by měl stále podporovat BIOS rozhraní INT 13h, které Win9x umí používat, ale za cenu velmi nízké přenosové rychlosti (řádově jednotky MB/s) a absence DMA bude vytěžovat CPU. Intel už ze svých nových chipsetů vyhodil legacy emulaci IDE mode, byť jistá výjimka existuje a o AHCI Win9x ve své době neslyšely. Avšak R. Loew naprogramoval vlastní AHCI driver, který je nyní zdarma k dispozici. Případně lze použít PCI IDE/SATA řadič s vlastním BIOSem, který umožní z připojeného disku bootovat. Je možno připojit jak klasický disk, tak SSD, akorát je třeba počítat s tím, že Win9x neznají TRIM, tak bude občas třeba smazaná data vyčistit ručně utilitou od výrobce SSD (intel, Samsung), která vyžaduje alespoň WinXP a vyšší.
      Na onboard zvukové karty intel HD audio můžete rovnou zapomenout, PCIe karty také nemají ovladače pro Win9x, ale můžete použít levné USB zvukovky (daná USB třída je podporovaná nativně, nejsou třeba žádné ovladače) nebo starší PCI zvukovky. Některé starší ethernet řadiče, např. Realtek RTL8111D ještě měly nativní ovladače pro Win9x. Novější revize RTL8111E už nefunguje, ale podařilo se mi ji rozchodit alespoň v 16-bitovém režimu přes DOSový NDIS2 ovladač, s kterým umí Win9x pracovat. U novějších řadičů, které nemají ani DOSové ovladače už máte smůlu a nezbývá, než použít PCI nebo PCIe síťovou kartu, např. Broadcom 5721, která má ještě ovladače pro Win98 a dá se celkem levně sehnat na eBay. O USB a grafických kartách jsem se již zmiňoval výše. Jen bych upozornil, že byly zjištěny problémy s kompatabilitou některých starých PCIe 1.0 VGA na chipsetu intel Z370 (nebyla vůbec vidět ve Správci zařízení).
      Při instalaci Win98 je pak nutné omezit velikost RAM a vyzkoušet, jak si Win98 porozumí s ACPI. Zde záleží na konkrétním BIOSu, jaké má ACPI tabulky a jak se budou Win98 líbit. Napřed bych tedy zkusil ACPI nuceně zapnout parametrem instalátoru setup.exe /p j a pokud instalace selže, tak naopak ACPI zakázat pomocí setup.exe /p i. Po základní instalaci lze očekávat ve správci zařízení les vykřičníků. Nepoužívaná/nepodporovaná zařízení je vhodné zakázat. Někdy může být problém s alokací IRQ např. pro více USB řadičů a bude třeba některé zakázat. Před instalací každého ovladače nebo patche doporučuji celý systém zazálohovat. Může se snadno stát, že se systém dostane do kolečka modrých smrtí, které nepůjdou vyřešit ani v nouzovém režimu a pak je vždy lepší obnovit systém ze zálohy, než začínat od znova. Mou sbírku různých patchů a ovladačů pro Win98 najdete zde.

Windows 98 (SE) a problémy na nových CPU (i ve virtualizaci)
      13.6.2023 Když jsem zkoušel nainstalovat Windows 98 SE do VirtualBoxu 7.0 (pod Windows 10 s vypnutým Hyper-V) na notebooku s poměrně novým CPU intel Core i7-11850H (11. generace, Tiger Lake), narazil jsem na problém, že během instalace (ve fázi detekce HW po 1. restartu) došlo k chybě v shell32.dll resp. explorer.exe a po nuceném restartu i v dalších systémových souborech. Vyzkoušel jsem český i anglický instalační ISO image a oba se chovaly stejně. Následně jsem se dopídil, že stejný problém má více uživatelů na moderních CPU intel Core a AMD Ryzen a také, že uživatel JHRobotics už našel řešení a vytvořil utilitu patcher9x pro Win95/98/ME. Ta opravuje 2 problémy: TLB Invalidation Bug a dělení nulou v testu rychlosti CPU. Patcher je k dispozici jako Win32/DOS binárka a jako image bootovací diskety, kterou lze připojit do VM. Umí patchnout jak soubory už nainstalovaného OS, tak instalační soubory (CAB archivy) Windows. Po aplikaci patche se mi podařilo instalaci dokončit bez dalších problémů. Diskusní vlákno na Vogons fóru je zde. UPDATE: objevil se další problém s chybou "Windows protection error" ve vcache.vxd na CPU intel Core i7-12700K (12. generace, Alder Lake) a chipsetu Z690 - řešení je zde.
      Autor má též na svém GitHubu další zajímavý projekt SoftGPU, což je SVGA ovladač pro Win95/98/ME s podporou 3D akcelerace (Direct 3D, OpenGL, Glide) určený pro virtuální stroje, které podporují virtuální SVGA typu VMware SVGA-II (VMware, VirtualBox, Qemu) a Bochs VBE (Bochs, VirtualBox, Qemu). K dispozici je ve formě ISO image s instalátorem, který stačí připojit do VM a nainstalovat. Aby fungovala HW podpora 3D akcelerace, je třeba ve VirtualBoxu vybrat/změnit typ VM na Linux místo Windows, vybrat grafický adaptér VMSvga, nastavit mu 128 MB video RAM a zatrhnout 3D akceleraci, dále v příkazovém řádku je třeba spustit: VBoxManage setextradata "My Windows 98" "VBoxInternal/Devices/vga/0/Config/VMSVGA10" "0", kde "My Windows 98" je název VM. Rychlost ve 3D lze pak otestovat přiloženou utilitou OpenGLChecker. Já jsem dosáhl v Blendermarku v rozlišení 1024 x 768 / 32 bpp rychlosti cca 230 FPS se zapnutou 3D akcelerací a 45 - 49 FPS přes SW MESA renderer. Měl jsem ale po instalaci driveru problémy se stabilitou, Windows náhodně buď zatuhly po startu do desktopu nebo vyhodily BSOD. Diskusní vlákno na Vogons fóru je zde.

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. Jako další alternativa se nabízí prohlížeč RetroZilla kompatabilní s Windows 95 a NT 4.0, který vychází z Mozilla SeaMonkey 1.1.19 a přidává některé nové funkce. Tento neoficiální build od RoyTama navíc podporuje i novější zabezpečení TLS 1.2. 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).
      29.11.2020 Vývoj KernelExu na MSFN fóru neustále pokračuje a k dispozici je experimentální update 4.5.2019.247, starší buildy zde. Také se objevila speciální verze knihoven Visual C++ 2008 Redistributable pro Windows 9x/ME.

---

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) nebo pomocí DOSové utility BOOTPREP.EXE [11 kB] z Windows Embedded. Pokud byly Windows nainstalované na disk typu SCSI, může se v rootu ještě nacházet soubor ntbootdd.sys, což je SCSI miniport driver potřebný pro start Windows, který vznikl přejmenováním konkrétního souboru ovladače, např. aha174x.sys.
      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í (cesta dle ARC). V tomto případě se načte bootsector z 1. oddílu na disku 0. 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. Zmíním jich jen několik:
      /3GB (Windows NT 4.0 Server a vyšší) - mění rozdělení 32-bitového virtuálního adresového prostoru, který je k dispozici každému procesu na samostatnou část aplikace a sdílenou část jádra (nesouvisí přímo s velikostí fyzické paměti RAM, proces může s pomocí stránkovacího souboru využívat více virtuální paměti, než je v systému instalováno). Standardně Windows používají rozdělení 2 + 2 GB a tímto přepínačem ho lze změnit na 3 + 1 GB ve prospěch aplikací. Na druhou stranu se tím ale zmenší prostor pro diskovou cache, neswapovatelná paměť pro buffery driverů, počet volných položek ve stránkovací tabulce, atd. Podrobně je to popsáno zde. Navíc zdaleka ne každá aplikace pak může využít více než 2 GB. Jednak musí mít v PE hlavičce spustitelného souboru aktivní příznak LARGEADDRESSAWARE, druhak musí být s ohledem na to napsaná (např. nepoužívat signed int pointery pro práci s takto velkým polem). V praxi to využije pár náročných serverových aplikací jako třeba M$ Exchange Server.
      /pae (Windows 2000 a vyšší) - zapíná podporu PAE (Physical Address Extension) s kterou je možno v 32-bitovém OS využívat více než 4 GB RAM (typ. až 64 GB pro CPU s 36-bitovou adresovou sběrnicí, rozhodující je omezení chipsetu), nelze však překročit 2 - 3 GB limit virtuální paměti na 1 proces. Může se hodit při spouštění více paměťově náročných aplikací, např. virtuálních mašin. Bohužel deskopové verze Windows mají PAE uměle omezeno na 4 GB, více umí jen serverové edice. UPDATE1: pro Windows Vista/7 se objevil PAE crack, který licenční limit bezezbytku odstraňuje. UPDATE2: PAE crack se objevil už i pro Windows XP, je trochu komplikovanější.
      /noexecute={alwayson | optout | optin | alwaysoff} (Windows XP SP2, Windows Server 2003 SP1 a vyšší) - nastavuje chování DEP (Data Execution Prevention). Tato ochrana umožňuje pomocí NX bitu (NonExecutable) ve stránkovací tabulce zabránit spuštění potenciálně škodlivého kódu z paměti označené jako data (různe chyby přetečení bufferů a pod.). Avšak některé né úplně čistě napsané aplikace můžou přestat fungovat. Možnosti jsou: alwayson - aktivuje DEP pro OS i aplikace a nelze ho selektivně vypnout, optout - aktivuje DEP pro OS i aplikace a lze ho v ovládacích panelech pro konkrétní aplikaci vypnout, optin - aktivuje DEP jen pro OS a lze ho pro konkrétní aplikaci selektivně zapnout, alwaysoff - vypne DEP. Na 64-bitových Windows je DEP pro 64-bitové aplikace vždy aktivní a nelze vypnout, parametr tak ovlivňuje jen 32-bitové aplikace. Pokud není parametr v boot.ini zadaný, tak je na Windows XP SP2/SP3 použito nastavení optin. Podporuje-li CPU hardwarově NX bit, tak 32-bitové Windows při aktivovaném DEPu zároveň zapnou PAE bez ohledu na použití parametru /nopae, protože NX bit se nachází v 64-bitové rozšířené položce stránky, které se aktivují pravě s PAE. Je také možné používat PAE s vypnutým DEPem (parametry /noexecute=alwaysoff /pae).
      /kernel=filename a /hal=filename - umožňují specifikovat alternativní jméno souboru jádra a HALu. To se může hodit pro různé ladění, např. možnost vybrat si při bootu jedno nebo více-procesorové jádro.
      /debug a s ním se pojící parametry /debugport=COMx a /baudrate=xxx (pokud použijeme /debugport, není už třeba přidávat /debug) aktivují rozhraní pro připojení kernel debuggeru WinDbg (poslední verze 6.11.1.404 pro Windows XP je zde). Přes něj získáme zajímavé ladicí výpisy už v průběhu bootu Windows a možnost kdykoliv systém zastavit a krokovat. Pro debugování je potřeba druhý počítač s Windows a nainstalovaným WinDbg, který propojíme s laděným PC přes křížený sériový kabel (stačí 3-vodičový: RxD, TxD, GND). Na laděném PC přidáme do boot.ini výše zmíněné parametry. Abychom dostali podrobnější výpisy, je vhodné ladění provádět na tzv. "checked" verzi systému (zde je ke stažení včetně debug symbolů - soubory windowsxp-kb936929-sp3*.exe). V základu stačí jen checked verze jádra systému ntoskrnl.exe a hal.dll (správné verze pro konkrétní HW), pro nějž můžeme přidat novou položku do menu v boot.ini. Pak na ladicím PC spustíme WinDbg a v menu "File|Kernel Debug..." (Ctrl+K) vybereme na záložce "COM" správný port a odpovídající bitovou rychlost. Otevře se okno s hláškou, že se čeká na spojení a při bootu laděných Windows se začnou objevovat výpisy. Pak můžeme kdykoliv laděný systém zastavit přes menu "Debug|Break" (Ctrl+Break), krokovat, prohlížet paměť a registry, atd.

      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 INT 13h, 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. Novou verzi UniATA 0.46d7 používám bez problému na novější základní desce Gigabyte GA-P67-DS3-B3 s PCH intel P67 v IDE legacy mode. Zde je návod od Bear Windowse, jak nainstalovat Windows NT 4.0 na moderním PC.

Windows NT Workstation a omezení počtu procesorů:
      Kdysi, více než před 15 lety jsem si nainstaloval Windows NT 4.0 Workstation na jednoprocesorovém stroji a stále je mám na disku. Oni prostě pořád fungují bez ohledu na změny HW, které jsem za ta léta provedl a těch 120 MB dat mi nijak nepřekáží. Po posledním upgrade na 4-jádrový procesor intel Core i7-2600K se základní deskou Gigabyte GA-P67-DS3-B3 mě napadlo, že bych mohl zkusit vyměnit uniprocesorové jádro za multiprocesorové a využít tak plně potenciál všech 4 jader. To lze provést poměrně snadno, stačí do systému nakopírovat (a přepsat) následující soubory: halmps.dll (ver. 4.0.1381.164) - přejmenovat na hal.dll a ntdll.dll (ver. 4.0.1381.298) ze Service Packu 6a, kernel32.dll (ver. 4.0.1381.7095) z hotfixu CZEQ299444i a ntkrnlmp.exe (ver. 4.0.1381.7265) - přejmenovat na ntoskrnl.exe z hotfixu KB835732. Problém je ale v tom, že licenčně jsou Windows NT Workstation omezena pouze na 2 procesory, zatím co různé verze NT Serveru podporují 8 - 32 procesorů. Jak jsem zjistil, tak jádro Workstationu i Serveru je naprosto shodné, systémy se liší pouze několika důležitými záznamy v registrech a asi 200 různými systémovými soubory, které na počet procesorů nemají vliv. Přemýšlel jsem tedy, jestli je možné nějakým způsobem změnit již nainstalovaný Worsktation na Server, aniž bych musel celý systém přeinstalovat. Možné to je, dokonce na to existují 3 utility: NTSwitch, TweakNT a NTTune od Marka Russinoviche, kterou jsem však nikde nenašel. Jenže žádný z těchto programů mi nefungoval. NTSwitch mi psal, že nemůže změnit registry a že se mám přihlásit jako admin, přestože jsem přihlášený jako admin pořád. TweakNT zas na oko registry změnil, ale po restartu jsem měl pořád Worsktation.
      Nezbylo tedy, než zeditovat registry ručně. Jedná se zejména o hodnotu klíče HKEY_LOCAL_MACHINE\System\CurrentControlSet\ControlProductOptions\ProductType, kterou je třeba změnit z řetězce "WinNT" na "ServerNT". Jenže běžící systém to nedovolí, po editaci klíče vám vynadá chybovou hláškou o porušení licence a vrátí hodnotu zpět. Je tedy třeba registry editovat offline, např. tak, jak popisuji zde. Lze samozřejmě použít jiný NT-based systém, který máte nainstalovaný na tomtéž PC. Pokud ovšem změníte jen klíč ProductType, odmění vás systém při dalším bootu BSODem "SYSTEM_LICENSE_VIOLATION".


      Je tedy třeba ještě upravit další klíč HKEY_LOCAL_MACHINE\System\Setup\SystemPrefix, který obsahuje binární řetězec 8 Bytů. Tyto Byty jsou interpretované jako 2 DWordy uložené v pořadí little endian (LSB vlevo). Pokud je klíč ProductType nastaven na serverovou verzi řetězcem "ServerNT" nebo "LanmanNT", musí být ve vyšším DWordu klíče SystemPrefix nastavený bit 26 (maska 0x04000000), tzn. v otočeném pořadí to je bit 2 v posledním Byte vpravo. To ale není všechno. Další důležitý klíč je HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\LicensedProcessors, který má na Workstation hodnotu 2. Po vzoru Enterprise Serveru jsem ji zvýšil na 8. Tato hodnota se musí shodovat se zakódovaným počtem procesorů v nižším slově klíče SystemPrefix. Výpočet je následující: NumberOfProcessors = (~(SystemPrefix.lowDW>>5))&0x1F+1. V mém případě byla na Workstationu hodnota SystemPrefix = CB 13 00 00 00 E0 39 90, tedy nižší slovo je 0x000013CB a podle výpočtu dostáváme: (~(0x000013CB>>5))&0x1F+1 = 2. Upravil jsem nižší slovo na hodnotu 0x0000130D, takže pak vyjde: (~(0x0000130D>>5))&0x1F+1 = 8. Vyšší slovo jsem upravil takto: 0x9039E000|0x04000000 = 0x9439E000. Dohromady po Bytech zapsaná nová hodnota klíče SystemPrefix = 0D 13 00 00 00 E0 39 94. Po této úpravě už systém nabootoval jako Server, což lze snadno ověřit kliknutím na tlačítko Start, kde je v banneru vlevo podél nabídky napsaný název systému. Avšak systém viděl stále jen 2 procesory. Poslední potřebnou změnou je hodnota klíče HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\RegisteredProcessors, kde lze zadat počet požadovaných procesorů od 1 do hodnoty LicensedProcessors. Když zadáte více, než má procesor jader, tak se použije max. platná hodnota, v mém případě 4.
      Chování Serveru se v určitých ohledech liší od Workstationu a různé systémové součásti Windows si zjišťují na jakém systému běží a podle toho můžou měnit online své chování. Pomocí utility NTWatch lze monitorovat, který proces se dotazuje na hodnoty výše zmíněných klíčů ProductType a SystemPrefix. Jedna nepříjemnost, která plyne ze zapnutí většího počtu jader je zvýšená spotřeba procesoru a s tím spojená produkce odpadního tepla hluku. MPS HAL totiž neumí vkládat HLT, natož dynamicky měnit frekvenci pomocí EIST, takže i při nulovém vytížení procesoru topí na plné pecky, jako kdyby byl vytížený na 100%. Zkusil jsem použít upravený halvmx.dll, kde autor doplnil instrukci HLT do funkce HalProcessorIdle, což skutečně spotřebu procesoru výrazně snížilo, ale výkon šel brutálně dolů na úroveň nějaké 386tky...

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. Oddíly FAT lze kdykoliv později bez ztráty dat převést na NTFS pomocí příkazu convert X: /FS:NTFS.

Windows 2000 a nové aplikace
      Podpora Micro$oftu pro Windows 2000 už také dávno skončila. Uživatel blackwingcat na MSFN fóru se inspiroval projektem KernelEx pro Windows 98 a odstartoval nový KernelEx pro Windows 2000. Začal nejprve drobným patchováním knihovny kernel32.dll a během dalších 3 let přibyly desítky dalších knihoven rozšiřujících WinAPI o nové funkce Windows XP, Vista a DirectX 10 (s využitím Wine Direct 3D to OpenGL wrapperu). Já už nikde nemám žádnou instalaci Windows 2000, takže to nevyužiju, ale doufám, že časem vznikne něco podobného i pro Windows XP.

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 HKEY_LOCAL_MACHINE\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. Nově jsem objevil univerzální OpenSource AHCI ovladač StorAHCI, který je upraveným examplem z WDK 8 backportovaným pod WDK 7 tak, aby fungoval na Windows 2003 Server.

Windows XP a NVMe
      Nativní podpora moderních SSD s rozhraním PCI Express - NVMe byla přidána do Windows 8.1 a Windows Server 2012 R2 a dále prostřednictvím aktualizací do Windows 7 SP1 a Windows Server 2008 R2 SP1. Sdružení OFA (OpenFabrics Alliance) udržuje OpenSource NVMe ovladač pro Windows 7/8/8.1 a Windows Server 2008R2/2012/2012R2. Uživatel Kai Schtrom pak upravil tento ovladač tak, aby fungoval i na Windows Server 2003 R2 SP2 potažmo na Windows XP. Pro XPčka je potřeba zkopírovat a přepsat ovladač storport.sys verze 5.2.3790.4173 z Windows Serveru 2003, resp. ze záplaty KB943545-x86, x64. Podle uživatele Dietmara nabootují Windows XP SP3 z NVMe Samsung 960 Pro do 0,5 s, to se zdá neuvěřitelné. Aby bylo možné z NVMe bootovat, musí BIOS či UEFI (CSM) základní desky NVMe podporovat (služby INT 13h) nebo SSD musí mít vlastní legacy option ROM jako např. Samsung 950 Pro, ale takové SSD se už dnes nevyrábí.
      Pro starší základní desky bez UEFI a bez podpory NVMe také existuje trochu složitější řešení pomocí OpenSource CloverBootloaderu. Ten umí bootovat jak na PC s UEFI, tak s legacy BIOSem, např. z jiného SATA disku, USB flashky či CD. CloverBootloader také umí na PC s legacy BIOSem emulovat 64-bitové UEFI prostředí, které zahrnuje i NVMe driver NvmExpressDxe.efi, pomocí nějž může dále bootovat OSy z NVMe SSD. Na mé základní desce Gigabyte GA-P67-DS3-B3 mi poslední verze 5151 crashne s "X64 Exception Type 0xE" (boot z ISO image). Zkoušel jsem tedy postupně starší verze a jako poslední mi funguje 5145. Zatím žádný NVMe nemám a ani ho teď neplánuju pořídit, takže bootování nemůžu vyzkoušet, ale je dobře, že tu tato možnost je. BTW start Windows XP také výrazně urychlí, když se vypne prohledávání počítačů lokální sítě. To lze snadno vypnout např. volbou "Disable network crawling" v utilitě XP-AntiSpy.

Windows XP a disky > 2 TB
      Pro prolomení 2TB limitu kapacity disků se dnes běžně používá nově definovaná tabulka rozdělení disků GPT. Windows XP tuto strukturu neznají, ale mohou se ji naučit s pomocí ovladače Paragon GPT Loader. Platí jen omezení, že systémový oddíl s Windows XP musí začínat pod hranicí 2 TB. Paragon GPT Loader však není úplně 100% spolehlivý. Jako další řešení je možné využít sadu utilit a ovladačů z tohoto balíčku. Ten obsahuje soubory disk.sys, partmgr.sys a mountmgr.sys z Windows Server 2003 SP2, které GPT podporují a nahradí se jimi stávající soubory Windows XP. Dále obsahuje hybridní MBR, který se nainstaluje na disk pomocí SysLinuxu a GPT fdisk, který umožňuje vytvářet GPT oddíly.

Windows XP a souborové systémy
      Windows XP SP3 standardně podporují souborové systémy FAT12/16/32, NTFS, ISO9660 a UDF 2.01. Podporu pro další filesystémy lze díky modulární architektuře doinstalovat pomocí IFS driverů. FAT32 oddíly mohou mít velikost až 2 TB se soubory velkými až 4 GB. Pro naformátování FAT32 oddílu > 32 GB je třeba použít nějaký ne-M$ zkriplený nástroj, např. již zmíněný FAT32Format. Podporu 64-bitové FAT - exFAT pro velké USB flashdisky a paměťové karty vydal Micro$oft v balíčku KB955704. Avšak možná díky licenční a patentové politice se ani dnes tento systém nějak masově nerozšířil. Pro podporu novější verze UDF 2.x používané na Blu-ray discích je potřeba doinstalovat Panasonic DVD-RAM Driver nebo UDF Reader 2.5.
      Windows se také naučily rozumět řeči tučňáčího kmene. Podporu EXT2/3/4 zajistí driver Ext2Fsd nebo starší Ext2Ifs. Nově také přibyla podpora BtrFS (je též nativně v ReactOSu) díky projektu WinBtrFS. Zde je ale trochu problém vybrat funkční verzi, protože podpora Windows XP byla přidána ve verzi 1.5 a po verzi 1.7.3 se zas rozbila. Aby to nebylo tak jednoduché, tak formátovací utilita mkbtrfs.exe ze starších verzí nefunguje a musel jsem použít tu z poslední verze 1.7.5. Ta má ale v PE hlavičce nastaveno OS version 6.0, kterou je třeba pomocí PEHDR-lite snížit na 5.1. Tato utilita naformátuje libovolný diskový oddíl na BtrFS, ale nemění FS ID v partition tabulce. Jak jsem zjistil, tak starší verze 1.5 bez problémů přimountuje BtrFS oddíl s partition FS ID 83h (Linux), tak 07h (NTFS). Novější verze 1.7.3 ho automaticky přimountuje jen pokud má partition FS ID 07h. Pokud už máte nainstalovaný Ext2Fsd, tak lze i v případě partition FS ID 83h oddíl připojit pomocí Ext2 Volume Manageru. Takže já jsem nejprve nainstaloval verzi 1.7.5 přes INF soubor, pak jsem ručně přepsal driver btrfs.sys starší verzí 1.7.3 a upravil PE hlavičku mkbtrfs.exe. Zkusil jsem naformátovat nový BtrFs oddíl a zjistil jsem, že pokud tentýž oddíl zformátuju 2x po sobě, tak dostanu modrou smrt. Jinak na oddíl jde zapisovat a číst ho ve Windows i Linuxu.

Windows XP a moderní grafické karty
      Problém s ovladači na nové grafické karty dolehl i na Windows XP. Poslední podporovaná řada od nVidie je GTX 9xx s ovladači 368.81 z roku 2016 (pro GTX 460 - 960) a scaling pro DVI a DP výstupy funguje správně do verze 355.98. Po drobné úpravě INF souboru fungují i GTX 970 a 980(Ti) a dokonce i GTX 1060, ale ta jen v 64-bitových XP a jen 2D akceleraci. 2 roky po té nVidia zrušila podporu všech 32-bitových Windows (7 - 10), které jako poslední podporují řadu GTX 10xx s ovladači 391.35 z roku 2018. Na podzim roku 2021 přestala nVidia podporovat Windows 7 a 8.1 (poslední verze 472.12) a aktuálně podporuje už jen Windows 10-x64.
      Kvalita implementace VESA VBE šla opět dolů a na GTX 670 jsem narazil na problémy s page flippingem a některé staré hry používající EGA/CGA grafiku mají problémy s fonty. Ani VGA font 8x16 nefunguje správně. Také jsem se doslechl, že na nových základních deskách s chipsetem Z370 už nefungují staré VGA karty s rozhraním PCIe 1.0 a některé PCI VGA také ne (karta není vůbec vidět ve Správci zařízení). U karet řady GTX 10xx a RTX 20xx se objevil další problém s kompatabilitou dokonce na úrovni VGA registrů. Např. Laaca zkoušel spustit starou DOSovou hru Prehistorik 2 a dostal chybu "This card is not fully VGA compatible".

OS:	Win 3.X	WinNT 4.0	Win 98	Win XP	Win 7-32b	Win 7/8-64b
latest GPU:	TNT2 *	GF 6xxx	GF 7xxx	GTX 9xx	GTX 10xx	RTX 30xx

* ovladače jsou ve stavu alpha-beta, nestabilní

Windows XP a provoz na 4k LCD monitoru
      Na Windows XP je možné rozchodit 4k rozlišení, ale zkriplené ovladače karet nVidia jsou na DP výstupu limitované přenosovou rychlostí HBR1 (8,64 Gb/s), přestože např. moje grafická karta GTX 670 podporuje max. rozlišení DP 1.2: 4096 x 2160 @60 Hz (HBR2), HDMI 1.4a: 3840 x 2160 @30 Hz, DVI-D: 2560 x 1600. Z omezené šířky pásma HBR1 pak plyne, že v rozlišení 3840 x 2160 je možné dosáhnout max. 30 Hz. Je zajímavé, že stejná verze ovladače pro Windows 7 normálně HBR2 podporuje. Někde jsem se dočetl, že je tam snad nějaká závislost na nějakém WinAPI, které v XPčkách chybí a tak podporu HBR2 asi při kompilaci ovladačů pro WinXP vypnuli. Konkurence AMD to však dokázala obejít vlastní implementací a některé novější Radeony, jejichž ovladače ještě podporujou WinXP (např. HD 7970 a R9 280X), tak HBR2 podporují a skutečně funguje.
      Měl jsem možnost vyzkoušet 27" LCD Dell P2721Q s nativním rozlišením 3840 x 2160 @60 Hz připojený k mé novější grafické kartě GTX 970. Ta už podporuje HDMI 2.0 s max. rozlišením 3840 x 2160 @60 Hz. LCD podporuje také HDMI 2.0 a DP 1.2. Motivoval mě k tomu nedávný objev patche ovladačů od Yase, který našel způsob, jak odstranit umělé omezení pixel clocku na HDMI a DVI-D výstupech, které tam ty jebky nVidiotský zakódovali. V podstatě se jedná jen o přepsání jedné 32-bitové konstanty a opravu kontrolních součtů v souborech nv4_mini.sys a nv4_disp.dll. Yasův popis platí pro 32 a 64-bitové ovladače verze 355.98, testoval to ale jen na GT 710 a 730 v nižším rozlišení 2560 x 1440 pro vyšší frekvence.
      Nejprve jsem vyzkoušel, jak se tato kombinace zachová v DOSu. Při připojení LCD přes DP 1.2 monitor hlásil v textovém režimu (přeškálovaný a roztažený na celou obrazovku) rozlišení 3840 x 2160 @60 Hz a dokonce nabízel i 2 VESA módy 3840 x 2160 / 8 a 16 bpp, které jsem úspěšně otestoval svou utilitou VESATEST. Napadlo mě vyzkoušet též Windows NT 4.0 s univerzálním ovladačem VBEMP. NTčka nabootovaly v 1600 x 1200 (jak jsem je měl předtím nastavené) v zobrazení 1:1 bez scalingu, ale po přepnutí na 3840 x 2160 skončily modrou smrtí. Vyzkoušel jsem obě barevné hloubky a nějaká další nastavení, ale nepovedlo se mi to rozchodit. Po připojení LCD přes HDMI 2.0 z nějakého záhadného důvodu zmizely ze seznamu VESA módů všechny varianty rozlišení 1600 x 1200 a 3840 x 2160.


      Pak jsem nabootoval Windows XP s LCD připojeným přes DP 1.2. V ovládacích panelech Windows i nVidia Control Panelu bylo zobrazeno nejvyšší rozlišení 3840 x 2160, ale pouze frekvence 60 Hz a když jsem ho vybral, tak monitor zčernal a hlásil, že po DP nejde žádný signál. Zkusil jsem tedy vytvořit vlastní videomód 3840 x 2160 @30 Hz, ale po kliknutí na Test, skončil okamžitě chybou (LCD ani žádnou změnu nezaregistroval). Nejvyšší funkční rozlišení bylo 2560 x 1440 @60 Hz. Pak jsem vygooglil, že problém může být způsobený chybějící podporou MultiStream v DP a doporučuje se ho na monitoru vypnout nebo přepnout na DP 1.1a. V manuálu monitoru jsem našel, že to lze provézt 8 s dlouhým stiskem menu tlačítka v OSD menu Input source na položce DP. Po přepnutí na DP 1.1a už bylo možné vybrat a použít rozlišení 3840 x 2160 @30 Hz. Jakékoliv snahy o definici vlastního rozlišení s vyšší nebo i nižší frekvencí okamžitě selhaly.


      Jak bylo zmíněno, YASův patch se DP výstupu netýká, takže se to dalo očekávat. Přehodil jsem tedy LCD na HDMI 2.0 výstup a narazil jsem na stejný problém jako u DP 1.2 - bylo nabízeno max. rozlišení 3840 x 2160 pouze v 60 Hz a nefungovalo. Nejvyšší funkční rozlišení opět bylo 2560 x 1440 @60 Hz. Zkusil jsem podobný trik v OSD na položce HDMI a nabídlo mi to přepnutí z HDMI 2.0 na 1.4, ale ani pak rozlišení 3840 x 2160 @30 Hz nechtělo fungovat. Monitor hlásil jinou chybu, že aktuální časování není podporováno a vypnul se. Zkusil jsem vytvořit uživatelský videomód, ale opět to vždy skončilo okamžitou chybou pro jakoukoliv frekvenci. Pak mě napadlo zkusit snížit Y-rozlišení na nižší hodnotu, např. 1440 či 1600 fungovalo normálně, 1601 už ne. Postupným zvyšováním frekvence jsem nalezl limit na 3840 x 1600 @89 Hz, což při reduced blanking časování dosahuje pixel clock téměř 600 MHz. Je tedy evidentní, že YASův patch zafungoval a umožnil zvýšení pixel clocku na maximum, ale ty zmrdi tam někde zakódovali další omezení na počet řádků max. 1600, které ještě bude třeba najít a odstranit. To bude předmětem dalšího bádání v IDA...


Windows XP a nové základní desky (problémy s ACPI)
      Po ukončení podpory Windows XP se čím dál častěji objevují problémy s novým HW, protože chybí potřebné ovladače (např. pro onboard intel USB 3.x xHCI, síťovky, GPU...) nebo jsou jiné potíže s kompatabilitou. To se začalo projevovat i při pokusech o instalaci Windows XP na nových základních deskách pro intel Core zhruba od 6. generace (Skylake) s chipsety řady 1xx/2xx/3xx - od modrých smrtí během instalace, přes nefunkční multiprocessing po všelijaké jiné divné chování nainstalovaného OS. Zde bych také zmínil, že intel ze svých chipsetů řady 1xx a novějších odstranil u SATA řadiče podporu IDE compatible (legacy) režimu (řízení přes I/O porty) a zbyly tak jen režimy AHCI a RAID. Je tedy nutné integrovat ovladač intel AHCI do instalačky (např. pomocí nLite) nebo použít jiný řadič, který IDE compatible režim má a je z něj možné bootovat. Pro starší systémy (jako např. DOS) je zatím implementován AHCI legacy BIOS s podporou služeb INT 13h. UPDATE: problém s USB 3.0 byl zdá se vyřešen backportováním USB ovladače storport.sys z Windows 8 pomocí projektu NTOSKRNL Emu_Extender a problém s AHCI řeší nový univerzální OpenSource ovladač StorAHCI.
      Řadu problémů má na svědomí nekompatabilita v systému ACPI. Ten už zdaleka neřeší jen power management, ale spoustu dalších důležitých věcí, jako třeba plug & play detekci zařízení, přiřazení IRQ, multiprocessing, časovače a další. Řada výrobců už z BIOSu odstranila podporu MPS 1.4, takže bez funkčního ACPI vám poběží OS jen na jednom jádře (uniprocessor kernel). ACPI je pro mě zatím tajuplnou černou skříňkou, jejíž útroby jsem detailně nekoumal. Popíšu to tedy velice zjednodušeně. Dříve OS předával různé požadavky na řízení spotřeby prostřednictvím volání služeb APM BIOSu a nad prováděním jeho kódu neměl žádnou kontrolu. ACPI tento přístup od základu změnilo: pomocí speciálního jazyka ASL (ACPI Source Language) jsou výrobcem desky/BIOSu vytvořeny tabulky (některé jsou statické, jiné se vytváří dynamicky za běhu) popisující aktuální konfiguraci HW zařízení a metody - jakési funkce, které mohou s těmito zařízeními nějak pracovat. Tento textově čitelný zdrojový kód je zkompilován kompilátorem (např. iASL) do bytekódu AML (ACPI Machine Language) a vložen do BIOSu či UEFI. Operační systém si pak při bootu tyto ACPI tabulky vyhledá v paměti a jejich bytekód spouští pomocí interpreteru AMLI (ve Windows acpi.sys). Taktéž po bootu, za běhu OS, pokud nějaká periferie vyvolá ACPI přerušení nebo OS potřebuje vyvolat nějakou akci, tak zavolá danou metodu, jejíž kód runtime interpretuje a provádí ve vlastní režii. Pro tvůrce OS je k dispozici referenční OpenSource implementace ACPICA (ACPI Component Architecture), kterou používá např. Linux či ReactOS. Bytekód AML se dá pomocí iASL zpětně dekompilovat do čitelné zdrojové podoby a znovu zkompilovat. Ovšem může se také stát, že disassemblovaný kód obsahuje chyby a je tak nutná ruční úprava.
      Problém s ACPI je v tom, že se neustále vyvíjí a jeho jazyk se rozšiřuje o nové funkce (aktuální verze specifikace je 6.3), zatím co Windows XP podporují verzi 1.0b a malou část z verze 2.0 (sekci 8.3). Už v začátcích ACPI a Windows XP byly občas problémy. Kodéři UEFI v poslední době začali psát podle novější specifikace ACPI a na zpětnou kompatabilitu často kašlou. To má pak za následek, že zmatený AMLI narazí na neexistující opkód a vyhodí BSOD 0xA5 nebo v lepším případě jen něco nefunguje správně, jako např. systémový časovač ve Windows - ten může být odvozen z různých HW zdrojů: TSC, HPET, ACPI timer (pokud je nastaven bit USE_PLATFORM_CLOCK v ACPI tabulce FACP)... To pak může způsobovat zatuhávání nebo špatnou funkci různých aplikací a her. Řešením problému je buď upravit ACPI tabulky pro různé verze OS podle _OSI nebo patchnout M$ AMLI (či naprogramovat jeho náhradu). Touto problematikou se docela podrobně zabývá obsáhlé vlákno na Win-Raid fóru, kde se některým uživatelům podařilo patchnout ACPI tabulky základních desek s novými chipsety H110, Z170 a Z370 tak, že na nich úspěšně spustili Windows XP a postupně odstranili některé problémy. Později se tam objevily různé patchnuté verze ovladače acpi.sys a také utilita ACPI Patcher, takže už není nutné upravovat firmware. UPDATE: po leaku zdrojových kódů Windows XP SP1 a 2003 se otevřela možnost si acpi.sys upravit ve zdrojové podobě a znovu ho zkompilovat. Na Win-Raid fóru se už objevilo několik nově zkompilovaných a upravených verzí.
      Další zajímavé vlákno se zabývá úpravou pro podporu HT nových 6-jádrových CPU na deskách s chipsety Z170 a Z270, kde korektně fungovaly jen 4-jádrové CPU. Zde jeden popis instalace Windows XP na desce Asus Maximus Apex X Z370. A na tomto ruském fóru najdete sbírku všech potřebných ovladačů a patchů pro XP včetně postupu jejich integrace do instalačního image (WinXP-IE Optional Patch Integrator, poslední verze 2.3.4b17).


Windows XP a nové aplikace z MSVC 2011 a novějších
      I v době příchodu Windows 10 stále ještě nemalé procento uživatelů používá XPčka, která jim poskytují dnes relativně nenáročný vyladěný systém s dobrou kompatabilitou ke staršímu HW a SW, bez zbytečností a bez iritujících či naopak chybějících prvků. Micro$oftu se tak stalo trnem v oku jeho vlastní dítě, které je třeba zadusit, aby lépe běžel byznys. Kromě ukončení oficiální podpory a postupnému odstraňování downloadů ze serverů M$ byla dalším strategickým krokem změna v kompilátoru MSVC 2011, jenž produkuje spustitelné soubory, které lze spustit jen ve Windows Vista a novějších bez možnosti změny. Tohoto umělého omezení bylo dosaženo nastavením minimální požadované verze OS v PE hlavičce programu (položky Operating System Version a Subsystem Version) na hodnotu 6.00 i v případě, že program nevolá ani jednu novější WinAPI funkci. Patrně na nátlak vývojářů přibyla možnost nastavení až v MSVC 2012 Update 1 (XP targeting) a kupodivu přetrvala i v MSVC 2013 a 2015. Kompatabilitu je však nutno explicitně nastavit v Platform Toolsetu a někteří vývojáři na to kašlou. UPDATE: mělo by to fungovat i v MSVC 2017 a 2019 s platform toolsetem verze 141. S tímto problémem jsem se setkal až nedávno, když jsem v práci nainstaloval program ELA Terminal 3.0.1 pro novou UHF RFID čtečku. Instalace proběhla normálně, ale při pokusu o spuštění jsem dostal pouze suchou chybovou hlášku:

Program byl přeložen v MSVC 2013. Napřed mě napadlo, že by to mohla být 64-bitová verze, což vyloučil rychlý pohled do PE hlavičky a po chvíli jsem dohledal příčinu i řešení problému. Pomocí programu editbin.exe, který je součástí MSVC (závisí na link.exe a mspdb80.dll), lze výše zmíněné položky PE hlavičky snadno změnit,
pro GUI aplikaci: editbin.exe program.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1
pro konzolovou aplikaci: editbin.exe program.exe /SUBSYSTEM:CONSOLE,5.01 /OSVERSION:5.1
Po této úpravě už šel program bez problémů spustit. RoyTam napsal vlastní malou OpenSource utilitku PEHDR-lite [5 kB], kterou lze provést totéž: pehdr.exe program.exe -osver 5.1 -subsysver 5.1 (m.j. přepočítá a aktualizuje kontrolní součet v PE hlavičce).

Windows XP a SSL / OpenSSL
      31.10.2016 V posledních týdnech jsem zaznamenal problémy s připojením klienta Miranda NG na svůj jabber účet na serveru jabber.cz. Prý došlo k nějaké aktualizaci protokolu TLS na novější verzi, přičemž Windows XP nepodporují SSL 3.2 / TLS 1.2. Náprava je naštěstí snadná, stačí do Mirandy NG nainstalovat OpenSSL plugin (nakopírovat soubor OpenSSL.dll do podadresáře PLUGINS a dále stáhnout balíček s OpenSSL knihovnou pro Windows (zde je verze pro Windows 9x bez podpory SSE2 instrukcí), rozbalit a nakopírovat soubory libeay.dll a ssleay.dll do podadresáře LIBS a po restartu Mirandy NG by se to mělo připojit.
      Jak jsem dále zjistil, systémová podpora SSL a TLS je implementovaná v knihovně WINDOWS\SYSTEM32\schannel.dll (TLS / SSL Security Provider), takže lepší řešení je aktualizovat tuto systémovou knihovnu pomocí záplaty KB3081320 (ENG), kde se nachází poslední verze 5.1.2600.6926 z 24.9.2015, která již podporuje novější protokoly. Ověřeno i se starší Mirandou IM.
      4.1.2017 Jeden uživatel vyzkoušel, že je možné tento update aplikovat i na Windows XP SP2. Stačí výše zmíněnou záplatu rozbalit pomocí parametru /x a ručně zkopírovat knihovny schannel.dll, rsaenh.dll a dssenh.dll do adresáře WINDOWS\SYSTEM32 (staré verze přepsat). Dále je možné přidat záznam do registrů ve větvi HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols (můžete použít .reg soubor níže). Avšak Miranda se do registrů nekouká a běží i bez toho. Podporu šifrovaných protokolů a kontrolu zranitelností webového prohlížeče si lze ověřit zde. Různé prohlížeče mohou používat buď podporu šifrování OS nebo mají svou vlastní. Pokud potřebujete aktualizovat kořenové certifikáty a Windows Update už nefunguje, můžete zkusit utilitu Root Certificates Updater.
      31.8.2017 Vyšla další záplata na šifrovací knihovny pod číslem KB4019276 (ENG) - schannel.dll verze 5.1.2600.7346.
      13.11.2018 Vyšla další záplata na šifrovací knihovny pod číslem KB4459091 (ENG) - schannel.dll verze 5.1.2600.7567.
      16.8.2020 Od jednoho kamaráda jsem dostal info, že začal mít problém se SSL připojením Mirandy i s poslední verzí schannel.dll. Doporučuji tak raději nainstalovat OpenSSL plugin, jak je zmíněno výše. S ním to zdá se normálně funguje.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "Enabled"=dword:00000001 "DisabledByDefault"=dword:00000000

Windows XP a bezpečnostní aktualizace po ukončení oficiální podpory
      Micro$oft ukončil oficiální podporu Windows XP 8.4.2014, ale i po té ještě vydal několik důležitých bezpečnostních záplat. Neoficiálně pak lze využít podpory pro Windows Embedded Standard 2009, což jsou defakto klasická XPčka, ale rozložená na komponenty z kterých si lze sestavovat vlastní systém. Jejich podpora potrvá až do 8.1.2019. Micro$oft vydává každý měsíc Security Release ISO Image, kde se nachází balíčky záplat pro všechny aktuálně podporované OS, všechny podporované architektury a jazykové mutace. UPDATE: poslední ISO image vyšel v červenci 2016, nyní jsou k dispozici ke stažení jednotlivé záplaty zde (pro setřídění podle datumu klikni v záhlaví na "Last Updated"). Aby to nebylo tak snadné a BFU si nemohli nainstalovat balíček s aktualizací pro Windows Embedded Standard 2009, provádí instalátor kontrolu klíče HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady v registru. Balíček lze rozbalit pomocí parametru /x a soubory ručně zkopírovat (do neběžícího systému) a nebo prostě nastavit registry tak, jak instalátor očekává. To lze provést snadno spuštěním tohoto .reg souboru:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady] "Installed"=dword:00000001

Pak už instalace normálně funguje. Hromadné rozbalení balíčků lze provést pomocí dávkového souboru s obsahem: for %%f in (*.exe) do %%f /q /X:.\%%~nf a hromadnou instalaci balíčků bez restartů pomocí: for %%f in (*.exe) do %%f /passive /norestart (spustit z adresáře s balíčky). Zde je moje sbírka záplat (rollup) vydaných od SP3 do ukončení podpory, naposledy aktualizovaná 7.3.2020 (MD5: 4E6573D9B9D7F4352A8D6944DDB6C4EF). U starších PC pozor na to, že XPE záplaty vydané od srpna 2018 vyžadují CPU s podporou SSE2. Pokud jste nainstalovali hotfix KB4494528 (Windows Installer 4.5.6003.20488) a nefunguje vám instalace programů, tak je třeba ručně spustit příkaz regsvr32 MSI.DLL.
      Dále lze využít i některé záplaty (např. USB ovladače) pro Windows Server 2003, které budou podporovány do 14.7.2015. V tomto případě lze provést jen ruční instalaci rozbalených balíčků. Před mixováním různých verzí ovladačů a knihoven vždy doporučuji zazálohovat původní verzi souboru a provádět instalaci po částech. Tak ať vám XPčka ještě dlouho spokojeně dupou, ke dnešnímu dni 11.4.2015 je na desktopu dosud používá 17% uživatelů (v Pentagonu prý dokonce 75% :), hned po Windows 7 s 58% uživatelů. Pokud by někoho trápilo vypnutí aktivačních serverů, může vyzkoušet tento Keygen.

Windows XP a konec podpory aplikací
      Bohužel časem přibývá čím dál více aplikací, které už nejsou kompatabilní s Windows XP, např. Adobe Lightroom 4.x (rok 2012) a novější, Telegram IM klient 1.9.3 (2019) a novější (na podzim 2022 přestalo v Telegramu 1.8.15 fungovat přidávání a komunikace nových uživatelů, prý kvůli rozšíření User ID na 64 bitů, komunikace s dříve přidanými uživateli zatím funguje), od jara roku 2016 prohlížeč Google Chrome 50, od konce roku 2016 prohlížeč Pale Moon 27 (zde je aktualizovaná verze 28.10.2a1 pro XP z 31.1.2020 s podporou TLS 1.3 od RoyTama a Mypal 29.3.0 od Feodora) a na podzim roku 2017 skončila na XP i Mozilla Firefox a SeaMonkey s poslední verzí 2.49.5 z roku 2019. Zkoušel jsem novou verzi 2.53.1 a ta už pod XP nefunguje. U SeaMonkey se od verze 2.49.3 nějak pokazilo přehrávání MP4/h264 videa, stačí však přepsat knihovny mozavcodec.dll, mozavutil.dll, vcomp140.dll, vcruntime140.dll novějšími verzemi z Pale Moonu 28.x pro XP. Na blokování reklam používám add-on uBlock Origin (legacy verzi 1.16.4.30 pro SeaMonkey). Ten už se oficiálně také nevyvíjí, nicméně na něm dále pokračuje uživatel AstroSkipper z MSFN fóra. Před instalací jeho verze je třeba odinstalovat předchozí oficiální verzi a smazat soubor ublock0.sqlite a cache (příp. ještě předtím exportovat vlastní nastavení a pak ho naimportovat zpět).
      V poslední době mě začal zlobit Google, že se nešlo přihlásit k účtu pro zastaralost prohlížeče, ale oblafnul jsem ho změnou UserAgentu: do adresního řádku zadej about:config a přidej novou stringovou proměnnou general.useragent.override nastavenou na Mozilla/5.0 (Windows NT 6.1; Win32; x32; rv:56.0) Gecko/20100101 Firefox/56.0 (pak se SeaMonkey tváří jako FireFox 56 a přihlášení funguje). Velmi podobný prohlížeč jako SeaMonkey s integrovaným e-mailovým klientem a HTML 'kompostérem' je IceApe, který se s Pale Moonem neoficiálně aktualizuje i v roce 2020. Seznam dalších aktualizovaných prohlížečů pro starší Windows je zde. Úroveň podpory HTML5 vašeho prohlížeče si můžete ověřit zde.
      Ještě bych pro úplnost zmínil čínský prohlížeč 360 Extreme Explorer založený na Chromiu 86. Originální čínská verze obsahuje nějaké šmíráky, ale odkazovaná verze od ArcticFoxie z MSFN fóra by měla být čistá. V roce 2022 začala řada webů (např. Rajfka, Moneta, ČSOB, Aukro, GitHub...) používat novější nekompatabilní verzi Javascriptu a tak je v současnosti Extreme Explorer 360 13.5.x jedinou možností, jak se v XP na takové weby dostat. Bohužel je to poslední verze pro XP, neboť novější verze 21.0 založená na Chromiu 95 už opustila podporu XP, Vista a kompletně 32-bitových Windows. UPDATE: Našel jsem o něco novější buildy 13.5.1030 z 9.11.2023 a 13.5.2036 z 10.4.2023 (odkaz ke stažení je v popisku videa), používá však stejnou verzi Chromia 86.0.4240.198. Dále jsem našel ještě novější odrůdu Chrome - Supermium, která používá výrazně novější backportované jádro Chromium 121.0.6167.81. Pokus o instalaci staženého setupu skončil chybou, ale našel jsem v TEMPu Windows balíček chrome.packed.7z, který jsem rozbalil ručně, spustil chrome.exe a funguje normálně. Funguje mi i podpora WebGL (např. 3D mapy.cz), akorát že přes softwarový renderer, který vytíží na 100% všechna jádra CPU (časem bude možná opravena podpora pro DirectX 9 na WinXP). Zkusil jsem Supermium potrápit otevřením asi 20 tabů s náročnými weby a po spotřebování veškeré volné paměti prohlížeč v tichosti crashnul a zůstaly po něm viset 4 zombie procesy chrome.exe, tedy lepší, než aby spadl celý systém s win32k.sys BSODem...
      Po delší době jsem objevil novou verzi MyPalu 68.13.5b od Feodora, která vychází z Firefox Quantum 68, což je oproti předchozí verzi 29 o pořádný kus dál. Nadšeně jsem se pustil do testování, všechny testované weby mi fungovaly, ale po pár minutách mi MyPal sestřelil celé Windows XP s BSODem v modulu win32k.sys. To se děje i některým dalším uživatelům. Jako workaround jsem našel doporučení v nastavení about:config (zadej do adresního řádku), změnit proměnnou layers.omtp.enabled na false. Tím se vypne funkce Off Main Thread Painting (vykreslování mimo hlavní vlákno). Od té doby mi to zatím BSOD nehodilo. Zkusil jsem MyPal potrápit a poodvíral asi 16 - 20 záložek s náročnějšími weby, kdy MyPal zkonzumoval asi 1,5 GB RAM a následně v tichosti spadnul, ale bez vlivu na Windows. Důvod BSODu se zatím nepodařilo objasnit. Domnívám se, že to souvisí třeba s nějakým souběhem (race condition) při volání funkcí ovladače grafické karty (když prohlížeč používá HW akceleraci pro vykreslování). Zdá se, že to častěji padá uživatelům v grafikou od nVidie, kamarád má ATI a jemu to BSOD nehází. Také na 64-bitové verzi Windows XP se zatím BSOD neobjevil.
      Zde je stručný přehled posledních verzí některých aplikací, které ještě oficiálně či neoficiálně fungují pod Windows XP. Obsáhlejší seznam je na na MSFN fóru a zde.

aplikace	verze	datum
MPC-BE (Media Player Classic Black Edition)	1.4.7.0	20.6.2016
MPC-HC (Media Player Classic Home Cinema)	1.7.13.32	23.7.2017
LAV Filters kodeky	0.70.2	6.7.2017
PotPlayer	1.7.21419	9.2.2021
Adobe DNG Converter	8.3.0.141	2.12.2013
ImageMagick	7.0.7-25	4.3.2018
Arduino	1.8.9	15.3.2019
CMake	3.13.5	14.5.2019
Cygwin, postup instalace	2.5.2	21.6.2016
Python	3.4.4	21.12.2015
PHP	5.4.9	21.11.2012
Apache	2.2.25	10.7.2013
Notepad++	7.9.2	1.1.2021
Saturn PCB Toolkit (ver. 7.11 nejde v XP nainstalovat, ale nainstalovaná jinde funguje)	7.08 (7.11)	8.1.2022
QEMU	2.7.0	3.9.2016
VMWare Workstation	10.0.7	2.7.2015
VirtualBox (více info zde)	5.2.44	14.7.2020
Bochs (neofiko MinGW32 build ver. 2.7 od Roberta Riebische)	2.6.11 (2.7)	5.1.2020
.NET Framework	4.0.3	28.11.2011
Mono (OpenSource alternativa k .NET Framework)	4.3.2	23.2.2016

Windows XP Kernel API extenders
      Pro Windows XP se postupně objevilo několik Kernel API extenderů, ale jedná se více méně o one man show hobby projekty v alpha stavu, které už jsou v současnosti (2020) opuštěné nebo zmizely v propadlišti dějin. Jako první rozšíření jsem objevil Alky For Applications 1.1 (2010), které přidalo nějaké funkce Windows Vista a umožňovalo spustit Windows Sidebar. Instalátor vyžaduje instalační disk s Windows Vista a licenční klíč. Po instalaci přibudou do kontextového menu souborů 2 položky: "Run Vista Executable" a "Patch and Run Vista Executable". Žádnou jinou aplikaci než Sidebar se mi s tím nepodařilo rozběhnout, všechny jen vyhodily chybovou hlášku "Aplikace skončila v důsledku stisknutí kláves CTRL+C".
      Na MSFN fóru jsem našel vlákno o ExtendedXP (2017) uživatele Dibya, kde byly odstraněny linky a jediný download jsem našel zde. Jedná se o instalační balíček, tvářící se jako standardní záplata, která přepíše asi 20 systémových souborů. Mě instalátor vynadal, že mám nejprve nainstalovat poslední aktualizace a skončil. Rozbalil jsem ho 7Zipem a soubory ručně přepsal offline. Systém nabootoval, ale hned první chybu mi indikoval CoreTemp, který crashnul. Stejně tak mi spadly při pokusu o spuštění prohlížeče Mozilla SeaMonkey, Palemoon a IceApe. Ale podařilo se mi spustit Adobe DNG Converter 9.6, který už v XPčkách normálně nefunguje.
      Další vlákno na MSFN fóru je věnované projektu XomPie (jako XP zombie :) uživatele TuMaGoNx, který je ke stažení na GitHubu (poslední verze z roku 2018). Pro svou funkci vyžaduje nainstalované knihovny MSVC++ 2013 a MSVC++ 2015. Využívá opačný přístup - nemodifikuje systém, ale patchuje binárku aplikace tak, aby volala redirector knihovny, které pak předávají volání nativním API funkcím nebo se nějak emulujou z části kódem z Wine nebo dummy funkcemi. Nainstaluje se jednoduše pomocí skriptu install.cmd, který pouze nakopíruje nové knihovny a utility do Windows (nic nepřepisuje). Následně na požadovanou binárku aplikace klikneme pravým tlačítkem a vybereme "Odeslat|xpatcher.cmd" a odklepnem výběr možností patche (původní binárka se zazálohuje s příponou .bak). Nevím, co jsem dělal špatně, ale jakákoliv aplikace, kterou jsem patchnul, tak jen vyhodila při spuštění chybové okno "Aplikace skončila v důsledku stisknutí kláves CTRL+C". A to včetně primitivního Hello Worldu zkompilovaného v MinGW32 jako konzolová WIN32 aplikace, která žádné nové WinAPI funkce nevolala. V onom vláknu na MSFN fóru jsem ještě našel zmínku uživatele Svyatpro o jakémsi upraveném kernel32.dll pro Windows 2003 Server, s kterým se mu podařilo spustit Adobe Photoshop CC 2015, avšak s nějakými chybami v menu a jeho projekt jsem ke stažení stejně nikde nenašel.
      Jako poslední, a zatím nejslibněji vypadající projekt, jsem nyní objevil One-Core-API (2020) uživatele Samuka aka Skulltrail (jeho jméno už jsem zahlédl v souvislosti s upraveným acpi.sys pro nové MB). Bohužel na GitHubu je jen jeden starý release 1.1, nenechte se zmást odkazem "Source code (zip)". Projekt je hodně rozsáhlý (obsahuje kódy z Wine a ReactOSu) a ke kompilaci je třeba MSVC. Do toho se mi zrovna moc nechce, takže jsem nic novějšího na testování neměl. Dokumentace prakticky žádná neexistuje. Archiv s binárkama (pro x86 i x64 Windows) obsahuje v adresáři PACKAGES\x86\Release\ 6 instalačních balíčků, které se tváří jako klasické hotfixy (se standarndí možností odinstalace). Po instalaci přibudou u EXE souborů (pod pravým tlačítkem) v možnosti nastavení "Vlastnosti|Kompatabilita" další volby až po Windows 10. Ale mám pochybnosti, jestli toto nastavení vůbec něco dělá, protože defaultně je rozšíření API pro všechny aplikace zapnuté a změna volby na Windows XP a nižší na tom nic nezmění a to může být problém. Balíček one-core-api-d3d.exe obsahuje WineD3D, které podporuje emulaci DirectX 10 a 11 přes OpenGL. Avšak právě tento modul je problémový a způsoboval mi crash prohlížečů Palemoon a Mozilla SeaMonkey. U Palemoonu stačilo, když jsem přejmenoval soubor d3d11.dll, SeaMonkey se sice spustila, ale nepřekreslovala obsah okna a menu. Balíček D3D je možné odinstalovat nebo přeinstalovat Direct X 9.0c. Nicméně některé programy mi sním fungovaly dobře, např. pěkné 64kB intro Offscreen Colonies od Conspiracy. Dále jsem rozběhnul Adobe DNG Converter 9.6, ThrottleStop 8.7.4.0 a někomu se podařilo rozjet PHP 7.3.2. Avšak třeba nový souborový manažer Salamander 4.0 nebo SeaMonkey 2.53.x skončily crashem. Starší Salamander 3.08 si zas začal stěžovat, že je spuštěn v režimu kompatability a nemusí správně fungovat (to se děje, když ho pustím ve Windows 7 a novějších). Tak třeba až se objeví nějaký novější release, bude už kompatabilita lepší. UPDATE: 4.7.2022 vyšla nová verze 2.6.0 a podle tohoto videa by na ní měl běžet prohlížeč Chrome 102, ale bohužel jsou ke stažení jen zdrojáky a nikoliv binárky.
      V souvislosti s tímto projektem jsem také narazil na 2 nové OS, které vychází z Windows XP/2003 a integrují v sobě One-Core-API a další vylepšení. Ruský systém nCore (releasy zde) od LWGAME (kteří už dříve vydali upravené DirectX 10 pro XPčka) je postavený na Windows XP SP3 nebo Windows Server 2003 SP2 + One-Core-API. Další systém Shorthorn jde dál a integruje nějaké části Windows Vista. Zatím jsem si stáhnul ISO image na hraní, tak o tom zas někdy příště...

NTOSKRNL Emu_Extender pro Windows XP/Vista/7
      Na MSFN fóru jsem objevil jeden nový zajímavý projekt NTOSKRNL Emu_Extender od uživatele MovAX0xDEAD. Jedná se o rozšíření Windows Kernel API o nové funkce pro podporu novějších driverů z Windows 7/8.x/10 pomocí modulu ntoskrn8.sys, který se nahraje k ostatním driverům do adresáře %windir%\system32\drivers. Hook vyžaduje také ruční editaci daného driveru (SYS souboru) pomocí hexaeditoru, kde je třeba v import tabulce změnit řetězec "ntoskrnl.exe" na "ntoskrn8.sys", případně další úpravy a přepočítání kontrolního součtu v PE hlavičce. Projekt sídlí na GitHubu a k jeho kompilaci je třeba stáhnout M$ Windows 7 DDK 7.1.0 a provést další úpravy dle návodu. Starší přeložená binárka je zde. Zatím se úspěšně podařilo do WinXP backportovat drivery pro NVMe (z Win7), USB 3.0 (z Win7/8), AHCI (z Win8). Je tak otevřená cesta pro doplňování dalších chybějících NT kernel API funkcí a portování dalších ovladačů.
      6.2.2021 Z GitHubu jsem stáhnul aktuální verzi NTOSKRNL Emu_Extender a přeložil ji bez problémů pomocí WDK 7.1.0 pro Windows XP. Otestoval jsem ji na backportovaných ovladačích USB 3.0 z Windows 8 s PCIe x1 řadičem VIA Labs VL805. Zde je ke stažení balíček se vším potřebným (zkompilovaný aktuální NTOSKRNL Emu_Extender, modifikované USB 3.0 ovladače a firmwary pro VL805 s mojí aktualizací INI souboru). Nejprve je potřeba do systému nakopírovat nové *.sys soubory z adresáře RELEASE9. Před instalací USB ovladače je třeba nainstalovat přiložený KMDF (Kernel-Mode Driver Framework) 1.11 z podadresáře RELEASE9\USB_3.0\KMDF_1.11 pomocí souboru wdf01011.inf (pravé myšítko, Nainstalovat) a pak klasicky přes Správce zařízení - vyhledat cestu k ovladači do podadresáře RELEASE9\USB_3.0, kde je usbxhci.inf a další soubory. Po úspěšné instalaci by se měly ve Správci zařízení v sekci "Řadiče sběrnice USB" objevit položky "USB xHCI Compliant Host Controller" a "USB Root Hub (xHCI)". Tyto ovladače, narozdíl od oficiálních VIA, fungují i v PAE režimu s více než 4 GB RAM.

Zdrojové kódy Windows XP SP1 a Windows Server 2003
      25.9.2020 jsem zachytil zajímavou zprávu, že se na fóru 4chan objevil torrent s leaknutými zdrojovými kódy Windows XP SP1 a Windows Server 2003 (cca 43 GB, ze screenshotu je vidět, že torrent obsahuje i starší OS a spoustu balastu). Zatím není jasné, jestli jsou zdrojáky kompletní a autentické. Podle názvu souboru nt5src.7z se dá vygooglit funkční torrent, který má aktuálně 25 seedů. V minulosti už takto unikly zdrojáky Windows NT 4.0, z kterých pak těžil (už mrtvý) projekt OpenNT.
      Přes noc jsem celý torrent stáhnul. Zmíněný archiv nt5src.7z obsahuje 2 adresáře: Win2K3 velikosti 6 GB obsahující 248740 souborů a XPSP1 velikosti 6,8 GB obsahující 277863 souborů. To by snad mohlo být kompletní. Našel jsem tam např. zdrojáky od acpi.sys, takže nyní by mohlo být jednodušší tento ovladač upravit tak, aby fungoval i na základních deskách s novým ACPI. Pokud se někomu podaří celé zdrojáky zrebuildovat (že by?), mohla by se tím otevřít cesta pro další rozšiřování NT API a implementaci chybějících funkcí do XPček, mno uvidíme...
      29.9.2020 Tak už proběhlo několik pokusů o rebuild zdrojáků Windows: XP na Win-Raid fóru a Win2k3 na 4chanu, kde můžeme vidět screenshot z VMWare s nabootovanými čerstvě vybuilděnými Win2k3. V obou případech se zjistilo, že chybí zdrojáky od důležité komponenty winlogon.exe a nějaké další *.SYS soubory, které bylo nutno zkopírovat z originálního instalačního image. Je možné, že jelikož tyto komponenty obsahují nějaké šifrování, tak měly v M$ vyšší třídu zabezpečení a leaker se tak k nim nedostal. Pravost kódů byla následně potvrzena bývalými M$ SW inženýry. Na GitHubu se objevil návod, jak zdrojáky zkompilovat. Buildovací systém Razzle (NT\tools\razzle.cmd) a kompilátor M$ C/C++ Optimizing Compiler 13.10.2179 for 80x86 je už součástí balíku v adresáři NT\tools\x86, můj pokusný build log.
      13.10.2020 Další pokročilejší návody na kompilaci jsou zde a v tomto videu, kde autor přidává další tipy např. na odstranění Timebomb. Také se přišlo na to, že chybí některé důležité zdrojáky jádra systému ntoskrnl.exe a jsou tam jen object soubory, které se po vyčištění (build -cZP) smažou a systém už nejde znovu zkompilovat.

---

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 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 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 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. Obejití 4GB PAE limitu ve Windows XP je popsáno v odstavci výše.
      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.

Windows 7 a nové aplikace
      Po ukončení podpory Windows 7 v roce 2020 (dobíhá už jen Extended Security Update do 10.1.2023) je čeká stejný osud jako XPčka a už se objevují první aplikace, které ve Windows 7 nefungují. Např. jsem zrovna zkoušel nový emulátor QEMU 7.1.92. Nainstalovat šel, ale nespustil se kvůli chybějící knihovně api-ms-win-core-path-l1-1-0.dll. Zkusil jsem tedy napřed nainstalovat poslední verzi MSVC Redistributable 2022, ale tam nebyla. Hledal jsem tedy ve Windows 10, ale ani tam kupodivu tato knihovna nebyla, přestože se tam QEMU normálně spustilo. Nakonec jsem našel řešení v podobě tohoto OpenSource hacku (knihovny vytvořené na bázi zdrojáků emulátoru Wine), který už pomohl rozběhnout 3D modelář Blender 2.93. Stačí z balíčku rozbalit knihovnu api-ms-win-core-path-l1-1-0.dll a nakopírovat ji do adresáře s instalací QEMU. Knihovna by měla pomoci též v případě Pythonu 3.9.

Windows 7 / 8.x / 10 a podepisování ovladačů
      Čím novější Windows, tím jsou restriktivnější v možnostech použití nepodepsaných ovladačů (které si třeba sami programujete). Také se v tomto ohledu liší chování 32-bitových a 64-bitových verzí OS. Zrovna jsem z jedné rozbité LCD televize kuchnul docela moderní a rychlý 2,4 / 5GHz IEEE 802.11 a/b/g/n/ac WiFi modul LGSWFAC81 založený na čipu Realtek RTL8812BU. Přibastlil jsem k němu microUSB konektor a stáhnul oficiální ovladače, jenže jsem zjistil, že si výrobce LG změnil USB VID a PID k obrazu svému a tyto hodnoty (043E:3108h) v INF souboru ovladače chybí. Upravil jsem tedy INF soubor přidáním příslušných sekcí a zkusil ho nainstalovat. Avšak narazil jsem na problém, že ovladače obsahují i catalog soubor (*.CAT) s hashi ostatních souborů pro kontrolu integrity včetně onoho INFu. Zatím co Windows 7-x64 jen zobrazily varování, že nelze ověřit vydavatele ovladače a po kliknutí na volbu "Přesto nainstalovat" je poslušně nainstalovaly a WiFi modul fungoval, tak Windows 10-x64 ohlásily, že sice ovladač našly, ale s neplatným podpisem se prostě nic instalovat nebude. Naštěstí v tomto případě, kdy se nemění přímo kód kernel ovladače (*.SYS), stačí vlastnoruční podepsání (self-signing) bez účasti Micro$oftu. Celý proces je detailně popsán zde, tak ho popíšu jen stručně.
      Nejprve bude potřeba získat pár commandline utilit (cca 3 MB), kvůli kterým budete muset postahovat pár GB celého Windows SDK a WDK. Začneme vytvořením vlastního certifikátu Drivers.cer a soukromého klíče (je požadováno zadání hesla, které si někam zapíšeme):
makecert.exe -r -sv Drivers.pvk -n CN="jméno" Drivers.cer
K němu vytvoříme veřejný klíč:
cert2spc.exe Drivers.cer Drivers.spc
a zkombinujeme oba klíče do formátu PFX (Personal Information Exchange):
pvk2pfx.exe -pvk Drivers.pvk -pi heslo -spc Drivers.spc -pfx Drivers.pfx -po heslo
Dále certifikát naimportujeme do databáze Windows, aby ho považovaly za důvěryhodný:
certmgr.exe /add Drivers.cer /s /r localMachine root
certmgr.exe /add Drivers.cer /s /r localMachine trustedpublisher
Pak můžeme utilitou inf2cat.exe (vyžaduje .NET Framework 4) podle INFu vygenerovat nový catalog soubor a podepsat ho. Parametr os je třeba nastavit dle cílové verze Windows (XP_X86, XP_X64, Vista_X86, Vista_X64, 7_X86, 7_X64, 10_X86, 10_X64, atd.) a adresář ovladačů by měl obsahovat jen soubory, které je nutné hashovat. V této fázi je třeba připojení k Internetu, aby se správně vytvořila časová známka.
inf2cat.exe /driver:cesta_do_adresáře_ovladačů /os:10_X64 /verbose
signtool.exe sign /f Drivers.pfx /p heslo /t http://timestamp.digicert.com /v cesta_a_jméno_souboru.cat
signtool.exe verify /v /pa cesta_a_jméno_souboru.cat
Ovladače s takto vygenerovaným catalog souborem šly následně nainstalovat i ve Windows 10-x64 (s aktivním UEFI Secure Bootem) a WiFi modul fungoval. Zkusil jsem také tímto způsobem podepsat svůj KMD ovladač (jako výchozí hashovací funkce se používá SHA1, parametrem /fd SHA256 lze vynutit SHA256, BTW ta není podporovaná ve Windows XP):
signtool.exe sign /v /ac Drivers.cer /f Drivers.pfx /p heslo /tr http://timestamp.digicert.com ioperm64.sys
signtool verify /v /kp ioperm64.sys
ale zavedl se pouze pokud jsem ve Windows aktivoval testovací režim příkazem:
bcdedit.exe -set TESTSIGNING on
Ten nejde aktivovat na UEFI systémech se zapnutým Secure Bootem, je třeba ho nejprve vypnout (po zapnutí Secure Bootu se testovací režim sám deaktivuje). Na ploše se pak v pravém dolním rohu zobrazuje watermark (upozornění o testovacím režimu a verzi Windows). Toho se lze zbavit úpravou resourců v knihovně user32.dll.mui pomocí utility Remove Watermark pro Windows Vista a 7 nebo utilitou Universal Watermark Disabler pro Windows 8.x a 10, která to umí i bez modifikace systémových souborů. Ještě jsem vyzkoušel další nastavení:
bcdedit.exe -set nointegritychecks on
bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS (někde zmiňováno jako DDISABLE_INTEGRITY_CHECKS),
ale to už nemělo žádný efekt a pokud jsem svůj ovladač vyměnil za nepodepsanou verzi, tak ji Windows odmítly zavést. Takže jsem to zase zrušil příkazem:
bcdedit.exe -deletevalue loadoptions
a nechal zapnutý jen TESTSIGNING. Pro ladění případných problémů ze též může hodit zvýšit podrobnost logování do souboru setupapi.dev.log nastavením hodnoty tohoto klíče:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Loglevel=0x4800FFFF

---

Windows 8.x (32-bit) a NTVDM
      Pokud jste si naivně mysleli, že 16-bitová aplikace spuštěná ve Windows NT (a vyšších) nemůže shodit systém nebo zneužít data, protože přece běží v bezpečném chlívečku NTVDM, tak vězte, že byla objevena celá řada zranitelností a exploitů NTVDM, které popisuje např. j00ru ve své prezentaci. Jde zhruba o to, že ošetřování některých výjimek a emulaci funkcí řeší přímo NT kernel a nedostatečně při tom kontroluje registry (a následně adresy paměti) spuštěné aplikace, díky čemuž může aplikace vhodným obsahem registrů provést čtení/zápis do určitých oblastí paměti kernelu, kam by se normálně neměla dostat. Pikantní na tom je, že řada těchto chyb se táhne po celá desetiletí od Windows NT 3.1 po nejnovější Windows 8.1 (64-bitových systémů se to netýká, ty vzhledem k omezení architektury intel x64 nemají NTVDM a musí plně virtualizovat) a některé z nich u Windows XP a starších ani nebudou opraveny, protože skončila podpora. Ve Windows 8.x to Micro$oft vyřešil typickým způsobem - než aby opravoval dílčí chyby, tak prostě NTVDM ve výchozí instalaci systému zakázal. Pokud je pak spuštěna nějaká 16-bitová aplikace, objeví se dialog, že je třeba NTVDM doinstalovat a pokud máte admin práva tak se hned doinstaluje a aplikace se normálně spustí. Totéž je možné povolit z konzole příkazem: dism /online /enable-feature:ntvdm a zakázat příkazem: dism /online /disable-feature:ntvdm

Windows 7 / 8.x a pochybné aktualizace funkcí z Windows 10
      Jak se během poslední doby ukázalo, uchýlil se Micro$oft zase k silovému nátlaku na uživatele starších OS Windows 7 a 8.x, kteří zatím update na Windows 10 odmítli, jimž začal podstrkovat nové spyware/adware funkce skrze automatické aktualizace. Doporučuji proto zvýšenou opatrnost před aktualizacemi: KB2952664, KB2976978, KB2990214, KB3021917, KB3022345, KB3035583, KB3068708, KB3075249, KB3075851, KB3080149 a KB3146449.
      18.5.2016 Micro$oft vydal kumulativní aktualizaci KB3125574 pro Windows 7, která by měla obsahovat všechny záplaty vydané po SP1 (verze pro 32-bit [316 MB] a verze pro 64-bit [477 MB]). Otázkou je, zda-li obsahuje též výše zmíněné GWX a spyware sračky. Namátkovou kontrolou jsem zjistil, že obsahuje např. komponentu "Microsoft-Windows-Unified-Telemetry-Client" version="6.1.7601.23403", jejíž starší verze se nachází ve výše zmíněných KB3080149 a KB3068708. Diskuse k tomuto tématu je na Redditu.
      23.3.2017 Další fintou, kterou se Micro$oft snaží uživatele starších Windows 7 a 8.x natlačit do Desítek je, že zamezil vydávání záplat přes Windows Update pro PC s novými procesory intel Kaby Lake a AMD Ryzen. Ostatně to už sliboval dříve u procesorů intel Skylake, ale ty se nakonec rozhodl podporovat. Avšak neznamená to, že by Windows 7 a 8 na nových procesorech neběžely (AMD oficiálně potvrdilo, že Windows 7 běží na jejich novém Ryzenu), záplaty by mělo být možné i nadále instalovat ručně. Měly by běžet i na Ryzenech 2. generace avšak nikoliv na APU Raven Ridge kvůli ACPI. Další info v článku a diskusi.

---

Pár tipů pro Windows 10
      Windows 10 jsem už řádně vyhejtil zde, ale když už je člověk musí někde používat... Šmírování v systému se zcela zbavit nejde (to by snad mohl řešit vhodně nastavený externí firewall), tak pro začátek alespoň částečná poinstalační sanitizace a odstranění zbytečností pomocí automatického skriptu je popsáno v článku "Jak z Windows 10 udělat desktopový systém". Potíž je v tom, že jak se Windows 10 neustále aktualizují, tak se chování systému mění pod rukama, různá nastavení se mění, přibývají a mizí, takže skript vyžaduje neustálou údržbu, aby držel s M$ krok. Pokud bychom aktualizace úplně vypnuli, tak zas hrozí, že za nějakou dobu přestanou fungovat nové aplikace a ovladače, takže velký update (v podstatě reinstalaci), by chtělo asi jednou za rok provést.
      Klasického Start menu jsem se nehodlal vzdát, takže místo té parodie jsem hned nainstaloval Classic Shell. Bohužel jeho autor už závod aktualizací s M$ koncem roku 2017 ukončil poslední verzí 4.3.1. Zdá se však, že vývoj pokračuje dál jako projekt Open-Shell. Další možnosti úpravy vzhledu a nastavení nabízí utility Winaero Tweaker a CustomizerGod. Při experimentování s vlastním kernel mode driverem jsem potřeboval vypnout vynucení digitálního podpisu ovladačů, což se mi trvale nepodařilo dosáhnout, pouze se mi pokaždé při bootu ukáže menu, kde to volbou č. 7 můžu vypnout. Zde je popsán další postup pomocí commandline utility bcdedit.exe (je nutno vypnout Secure Boot v UEFI). Později jsem zjistil, jak ovladač podepsat alespoň vlastním certifikátem a trvale ho zavést aktivací testovacího režimu, což se též vylučuje s aktivním Secure Bootem.
      Chybějící subsystém NTVDM v 64-bitové verzi Windows lze částečně nahradit lehkým emulátorem MS-DOS Player, který nově implementuje 486 jádro a podporuje EMS, XMS a DPMI, takže umožňuje spouštět např. konzolové programy kompilované v DJGPP. Pro grafické programy a hry je potřeba pustit DOSBox. Nově jsem též objevil 64-bitový port NTVDMx64, který vychází z leaknutých zdrojových kódů původního NTVDM (zde je patch). Zatím co na x86-32 procesorech Windows NT používaly pro NTVDM režim V86, kde naprostá většina instrukcí byla prováděna nativně bez zpomalení, tak na ostatních platformách (Alpha, PowerPC a nově též x86-64) bylo nutno procesorové jádro x86 emulovat. Micro$oft proto kdysi koupil emulátor SoftPC firmy Insignia Solutions, který do těchto ne-x86 Windows integroval. Škoda, že ho neintegroval i do novějších x64 Windows, aby to tam nemuseli uživatelé svépomocí hackovat. Pokud potřebujete spouštět i staré 16-bitové aplikace pro Windows 1.x - 3.x, vyzkoušejte lehký emulátor WineVDM. UPDATE: zkompiloval jsem a vyzkoušel aktuální build subsystému NTVDMx64 z GitHubu od Leechera (9.6.2023). Byla do něj integrována i podpora 16-bitových Windows aplikací, není tedy už třeba zvlášť instalovat WineVDM. Max. velikost DPMI paměti lze nastavit v *.PIF souboru dané aplikace (zde je limit 64 MB) nebo globálně v registru pod klíčem HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW\CpuEnv pomocí proměnné DPMIMEM typu REG_SZ s hodnotou v kB, viz soubor reg\dpmimem.reg v instalačním balíčku. Také přibyla možnost měnit velikost okna v grafickém režimu pomocí proměnné EyeStrain, která definuje kód klávesy pro přepínání velikosti. V souboru reg\eyestrain.reg je nadefinována klávesa ScrollLock, kterou se pak cyklicky přepínají 3 velikosti.       Dalším zajímavým rozšířením by mohla být instalace WSL (Windows Subsystem for Linux) pro spouštění linuxových binárek, zatím jsem to nezkoušel.
      Uživatel ze skupiny Administrators má ve Windows poměrně omezená práva (na rozdíl od roota v Linuxu), takže nemůže mazat systémové soubory (to řeší utilita IObit Unlocker 1.3.0, která funguje na WinXP-11) nebo klíče v registrech. Může se tedy hodit spustit nějaký proces (třeba příkazový řádek či regedit) s právy System. O tom pojednává tento návod. Nejsnáze toho lze dosáhnout pomocí utility PsExec, která je součástí šikovných nástrojů PsTools od Marka Russinoviche. Podobně funguje utilita ExecTI, která spustí proces s privilegovanými právy TrustedInstaller. Zde je popis, jak opravit práva v registrech utilitou SubInACL v případě potíží s instalací programů (error code 5 či 0x80070005) kvůli nedostatečným právům.
      Občas se může hodit prohlédnout si ve Správci zařízení různá skrytá zařízení. Toho lze dosáhnout nastavením systémové proměnné devmgr_show_nonpresent_devices=1. Z příkazového řádku lze Správci zařízení rychle spustit příkazem devmgmt. Pokud potřebujete ze systému vymazat všechny informace o enumerovaných USB zařízeních (co jste kdy k PC připojili), tak to lze provést např. utilitou USB Oblivion.
      Do nové verze Windows 10 byla v rámci NTFS přidána podpora case-sensitive filesystému (souvisí s WSL), tak jak je zvykem na Linuxu. Tato vlastnost jde zapnout pouze selektivně pro vybraný adresář (u podadresářů se automaticky nenastaví) a provádí se programem fsutil.exe. Jako zajímavou kuriozitu jsem objevil toto video, kde se uživateli NTDEV podařilo nainstalovat Windows 10 na 2GB FAT16 oddíl (z kapacitních důvodů patrně nějaký ořezaný image). Oddíl vytvořil a naformátoval z DOSu a pomocí instalačky Windows 2000 na oddíl nainstaloval NTLDR a pak z instalačky Windows 10 pomocí DISM rozbalil na disk instalační image install.wim a aplikoval další hacky (WIM soubor lze rozbalit též pomocí 7Zipu, stačí přejmenovat příponu souboru na .7z). Patrně by to mělo fungovat i s Windows Vista a 7.
      Jak se zbavit otravného adresáře System Volume Information, který Windows 10 opakovaně automaticky vytváří v rootu každého disku, jenž najdou (včetně přenosných médií)? Pokud např. potřebujete z nějakého úložiště obnovit smazaná data, tak asi poslední, co chcete je, aby vám Windows hned při připojení úložiště data přepsaly dříve, než stihnete spustit nástroj na obnovu dat. Tento problém řešilo více lidí a popsali více způsobů řešení. Postupně jsem vyzkoušel nepovolit přidání vyměnitelných medií do knihoven v šablonách politik přes gpedit.msc, změnu v registru HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search na DisableRemovableDriveIndexing=1 a pomohl až zákaz služeb Windows Search a Služby Úložiště. Pozor na to, že zákaz Služby Úložiště může mít negativní vliv na instalaci aplikací z M$ Store, což mi nijak nevadí. Už od dob Windows 95 vykazují M$ OS virulentní tendence neustále někde něco bez vědomí uživatele přepisovat a měnit, tehdá šlo o problém s přepisováním pole OEMName v bootsektoru disket, které nebyly chráněny proti zápisu.
      Jak nabootovat jiný OS či libovolný nepodepsaný UEFI modul na PC se zapnutým UEFI Secure Bootem bez nutnosti jeho vypnutí jsem popsal zde. Pokud používáte Secure Boot spolu s šifrováním disku BitLockerem, může být občas potřeba Secure Boot vypnout (např. kvůli zavedení nepodepsaného ovladače) a BitLocker na takovou změnu reaguje požadavkem na zadání recovery klíče. Šikovnější je před takovou změnou BitLocker dočasně v nastavení suspendovat, přičemž se po restartu automaticky znovu aktivuje.

---

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.

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 (zde je postup využívající GRUB pro boot Windows XP), 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

---

Jak obnovit smazaný videosoubor z SD karty (FAT32)?
Pro obnovu smazaných souborů a nabořených oddílů z disku (nejen) pod DOSem jsou k dispozici 2 novější programy GNU TestDisk (DOS / Windows / Linux / MacOS) a free verze DMDE (DOS / Windows / Linux / MacOS).

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