Odpověď na názor

[120] Zkuste si ještě jednou přečíst, co jsem psal. Opravdu jsem nepsal, že ve Windows je minimum chyb :). Psal jsem, že minimum BSOD je působeno chybami ve Windows. V linku níže se dozvíte, že 85% BSOD je způsobeno drivery. Data jsou z OCA (online crash analysis). Také se dozvíte, že MS nabízí nástroje pro ověřování driverů, včetně dvou nástrojů pro statickou analýzu kódu. V prezentacích z WinHEC se pak dozvíte, že MS shromažďuje data o BSOD pomocí OCA, a výrobci HW dostávají reporty o tom, ke kolika BSOD v jejich driverem došlo, a to i když uživatel nevolá technickou podporu. Vyjma toho Vista sbírá data o problémech (včetně BSOD), a umí je poslat MS pro ověření, jestli pro dané problémy neexistuje řešení. Mimo jiné tento mechanismus umožňuje, aby MS zákazníka požádal o dump a dodatečné systémové informace u problémů, které potřebují další diagnostiku (zákazník samozřejmě může odmítnout).
http://www.microsoft.com/whdc/driver/wdf/wdfbook_intro.mspx

Ano, těch komponent je pět a půl (samozřejmě obrazně, protože půl komponenty nelze). Zkuste se podívat na Windows do Registry, větev HKCR\Classes\CLSID.

K registraci komponent: ve Windows se registruje COM komponenta tak, že zavoláte DllRegisterServer příslušné knihovny. Odregistraci provedete voláním DllUnregister­Server. Obojí umí zavolat utilita regsvr32.exe. Samozřejmě kód registrace komponenty nepíšete sám - o to se vám postará vývojové prostředí. V případě .NETu je to ještě jiné, tam se komponenty registrují v Global Assembly Cache.

sycoca jako obdoba Registry, GConf jako daší obdoba Registry, ale Registry je prý hrozně špatná věc :). Přitom jediný rozdíl je v tom, že autoři těmto dvěma konfiguračním databázím nevěří natolik, aby data nechali jen v nich, a mají hodnoty i na FS. Ve Windows mají ovšem Registry desítky tisíc větví, takže by vydumpování do souborů zbytečně zabralo velikou spoustu místa.

S callbacky se to ve Windows má tak, že zaregistrujete class na událost například pravého tlačítka myši na soubory typu .abc. Když takový soubor stisknete pravou myš, zavolá se daná COM komponenta, a ta řekne, co se má dělat (třeba prohledá executable, jestli v něm není ZIP, a pak případně přidá context menu položku "Extract ZIP"). Podobně jsou implementované property sheets, context menus, preview handlers i vlastní otevírání souborů (soubor umí shell ale otevřít i spuštěním executable s parametry, není nutná COM komponenta).

To co popisujete vy vypadá až s podivem použitelně, na rozdíl od takového MC. Jde sice o opis shellu z Windows, ale jak jsem psal dříve, nemá moc smysl se dohadovat, kdo od koho opisuje.

U názvů souborů je problém v tom, že na FS jsou to C stringy (typ char), kdežto v Qt jsou to UTF-16 stringy (typ QChar). Když čte Qt z disku název souboru, automaticky počítá s tím, že je v UTF-8 (a dnes má zpravidla pravdu). Co se stane, když Qt z FS načte název souboru v 8859-*? To se může lehko stát, pokud jedete v UTF-8, a spustíte aplikaci z roku 1995, která jede v 8859-2, nebo pokud máte starý soubor na disku. Qt potom musí někde selhat při konverzi UTF-8 na Unicode, protože název v 8859-2 je v UTF-8 neplatný. Dojde k výjimce, substituci znaků otazníkem, půjde načíst adresář, půjde soubor otevřít? Celé je to samozřejmě způsobené tím, že unixy se o code page jména souboru nestarají, což ve Windows odpadá, protože tam jsou jména vždy v Unicode (i ve Win9x).