Názory k článku ReactOS: svobodná náhražka končících Windows XP

http://www.osel.cz/index.php?clanek=5747

Wine máte na Linuxu. V ReactOS máte z Wine jen některé programy a některé knihovny.
Jinak nároky má ReactOS skutečně minimální (to mi věřte). Stačí si stáhnout nějakou verzi pro VM a vyzkoušet. I při 64MB nabíhá svižně a je plně použitelný (tedy co se rychlosti týče). Na disku zabírá nějakých 312MB.
Když to srovnám s mnou oblíbeným xubuntu, tak to si žádá 512MB a 6.1 GB přičemž při 512MB to k používání zrovna není.

Nič v zlom, ale prázdny Windows je tiež svižný. Ale po takom roku používania, inštalovania atď. je nutné čakať ešte aj po nabehnutí plochy, kým sa počítaču uráči uvoľniť procesor. Proste nabaľujú sa registre a nabaľujú.

Ja moc neinstalujem a xp sa mi aj tak casom spomalovalo, mam podozrenie ze to robili aktualizacie. Uvidim teraz po skonceni podpory xp.

Pokud vám stroj po roce startuje pomaleji, souvisí to se službami a programy spouštěnými při přihlášení, které jste si nainstaloval. "Nabalování Registry" je blbost.

Dokonce bys měl za tu dobu kompletně nainstalovaných několik strojů s Windows. Jen by asi chyběly jiné než základní aplikace (stejně jako na těch Linuxech).

Bohužel, na rozdíl od různých LiveCD Linuxu, nemáte u Windows možnost stahnout si novou verzi, zasunout do mechaniky, spustit, nainstalovat nejnovější software od GPS, zaktualizovat ji, a pak systém vypnutím uvést do předchozího stavu. (S tím Linuxem by to šlo, kdyby dodával prodejce ovládací SW pro linux.)

Ještě nikdy jsem neaktualizoval Windows déle než hodinu. Je ale pravda, že používám slušný HW.

Ani na systémech s HDD jsem nikdy neviděl update delší než hodinu.

Windows Update funguje transakčně. Pro každý soubor ověří jeho aktuální verzi, provádí zálohy toho co změnil, a v případě selhání aktualizace se umí vrátit k předchozímu stavu. Databáze Registry je pekelně rychlá, takže tam problém nebude :). BTW RPM používá jako lokální databázi Berkeley DB; v případě přerušení procesu aktualizace se věci nenavrátí k původnímu stavu, a DB se může rozsypat. Wow.

Ta databaze je tak pekelne rychla ze spolehlive odstavi cely widle. Na terminal serveru(kde muzou byt potencielne registry tisicu profilu) to doslo tak daleko, ze se musel cely reinstalovat ... protoze spusteni naprosto cehokoli trvalo minuty ...

Win update funguje tak genialne, ze pokud se behem klidne desitky minu trvajici aktualizace neco stane, stroj uz nikdy nenastartuje. Navic se neumi widle opatchovat jednim vrzem, a je to vzdy na nekolik zcela nepredvidatelnych "muze vyzadovat" restartu.

Vubec nemluve o tom, ze M$ netusi co to znamena "need/vyzaduje", takze uzasny a genialni rozhrani pro wsus vesele tvrdi, ze widle potrebuji dalsich 30 aktualizaci, coz jiste kazdeho admina potesi ... kdyz ty widle tvrdi, ze zadne nepotrebujou ... aby nasledne zjistil, ze jde o (nejen) jazykove balicky a spol, pricemz totalni trotlove u M$ na M$DN se samozrejme biji v prsa ze takto to je spravne a tak to ma byt, protoze tomu nikdo nerozumi (je tam thread s cca tisicovkou v mnoha pripadech velmi trefnych a velmi neslusnych pripominek).

FYI Registry uživatelů jsou udržované pro každý účet zvlášť. Reinstalace je řešení matláků. Předpokládám že byste reinstalací řešil i docházející místo na disku :)

Aktualizace by měly po rebootu navázat. Naopak když patchujete distro Linuxu, a aktualizace se nepovede, tak vás to prostě vyklopí s rozjebaným systémem. Nemluvě o upgradu distra - to je jen pro silné povahy.

Jelikoz samozrejme vubec netusis jak probiha patch tuxe (samo zcela za chodu) tak chapu ... stejne jako vubec netusis, jak vypadaji registry widli ...

Vis, narozdil od widli kdyz si v tuxovi pres ssh patchnu prave to ssh, a restartnu ho .. tak me to pro tvoje velke prekvapeni ... ani neodhlasi. Kdyz se atktualizace v 90% z nejakyho duvodu ukonci (coz se samo stat muze) tak zcela vpohode mam zcela bezici a fukcni system, nebot se nikde nic nezmenilo. Aktualizace se totiz pripravuje nekam do /tmp ... a teprve kdyz je vse hotovo, tak se doslova lusknutim prstu preklopi. Narozdil od widli, kde zcela bezne nastava stav typu pulka dll z nove a pulka ze stare verze, pripadne jeste lepe ... zadne dll. Vubec nejlepsi je pak instalace nejake (specielne M$) appky ktera si zcela vpohode prepise systemovy DLL.

Ale sranda najvetsi (a specielne pro ty kteri netusi) ... mejme rekneme takove M$ SQL 2005, i nainstalujeme trebas jen cisty srv ... (bez vsemozny bizuterie kolem) ... nasledne to jako spravny zodpovedny admin opatchujeme ... a pak si dodavatel nejake te appky vzpomene, ze potrebuje doinstalovat nejaky ten tool ... voiala, spustime instalator ... a ten nam vynada, ze je nainstalovana jina verze SQL serveru ... a odmita delat naprosto cokoli, samozrejme vcetne odinstalace SQL .... moc krasne ...

BTW: upgrade verze widli je takova ta krasna vec, o ktery vsichni mluvi, ale nikdo ji nikdy nevidel fungovat, ze? Neznam totiz vubec nikoho, kdo by se neco takovyho odvazoval praktikovat, a jakysi polonefunkcni system po upgrade sem videl vseho vsudy mozna 2x. Nakonec to stejne skoncilo cistou instalaci.

BTW: Prave mi zaclo mngmt studio SQL 2k12 hlasat, ze expirovala licence ... chmm... rada M$ ... preinstalovat to ... nejspis to za dalsi 3 mesice expiruje znova ... ze. Zjevne maji pocit ze admini maj malo prace ... du hledat crack, to totiz bude asi tak 1000x efektivnejsi.

Aha, takže na Linuxu používáte podobný mechanismus aktualizací jako ve Windows. Akorát že instalační databáze RPM se při přerušení aktualizace může zhroutit... Jinak ten přesun "doslova lusknutim prstu" mě pobavil :D. Samozřejmě to není atomická ani transakční operace.

Přidávání komponent po instalaci SQL Serveru a Service Packu se provádí naprosto běžně, a ještě jsem neviděl problém.

Upgrade Windows na novou většinou funguje. Zvlášť když si před ním sjedete Upgrade Advisor, který vás upozorní na případné problémy. Velmi dobré je to, že když upgrade nefunguje, tak se stroj vrátí do původního stavu.

Jasně. Když vám Management Studio hlásí, že expirovala licence, tak najděte crack. A nezapomeňte ho stáhnout i s nějakým malwarem, který se s cracky běžně šíří. Jistě pak budete 1000x efektivnější, a zaměstnavatel vám poděkuje.

Ne, ty aktualizace fungují dost jinak. Všechny nově spuštěné programy jsou již aktualizované, všechny běžící pokračují ve staré verzi. Samozřejmě, pokud chcete mít jistotu, že je to všechno aktualizované, tak to jako ve Windows restartujete, ale důležité je, že to (např. u malých aktualizací) dělat vůbec nemusíte.

Nevím, jak instalační databáze RPM, ale instalační databáze DPKG se zhroutit nemůže, protože to není databáze, ale mnoho textových souborů ;-) Ty soubory se tam vytvářejí jako .dpkg-new a až po nahrání se jim ta koncovka odstraní. Což je atomická operace, viz man 2 rename.

Btw. který blb z Roota změnil značku <code> na blokovou?

Btw. který blb z Roota změnil značku <code> na blokovou?

Asi opět nějakej studentík ze Žižkova... (viz "antispam") Mimochodem, asi před týdnem jsem hlásil neustálé problémy s Internal server error. No, vyřešilo se samozřejmě velký kulový.

Takže nainstalujete například aktualizaci Firefoxu, ale dál vám běží stará nepatchovaná verze. Ještě lepší situace nastane, pokud například ten nový Firefox má jiné resources nebo pluginy, a ten starý si s tím neví rady. U serverového SW je to ještě výrazně větší problém.
Ve Windows samozřejmě také po aktualizaci nemusíte restartovat, ale nese to podobná rizika. Nakonec proto vás k tomu instalátor vyzývá.

OK, DPKG se vám asi nezhroutí, RPM databáze může (a stává se to). Ten přesun souborů je zajímavý hlavně u aktualizovaných binárek, případně konfigurací. Když lehne uprostřed akce, tak smůla.

Ad který blb z Roota - asi ten samý, díky kterému se všichni registrovaní uživatelé zobrazují jako "Uživatel si v profilu nezvolil přezdívku". Případně ten samý, který způsobil, že při otevření rubriky a následném kliku na článek se zobrazí hláška "stránka nenalezena", i když článek existuje (generuje to špatné URL). Ale co chcete, běží to na open sourcu ;)

Ad který blb z Roota - asi ten samý, díky kterému ...

Přidáno do vlákna o katastrofálním stavu serveru zde

Díky

Ano, a redakční systém ve Wordu. Jo a poslední zhasne. :-)

Právě jsem se to chystal navrhnout. V MS Azure to bude běhat svižně a spolehlivě. Už jsem také začal kreslit dlaždice a ribbon. A dobrá zpráva nakonec: budou nová barevná schémata. Už jsem vybral barvy :)
http://www.mobiletechworld.com/wordpress/wp-content/uploads/2011/01/themestitch.jpg

Aaa... zase mr plkalista ...

V tuxovi jakmile dobehne aktualizace, tak se pouziva nova verze SW - kazde dalsi jeho spusteni spusti vyhradne novou verzi. Jak toho docilim u widli? Aha, nijak.

Jak ve widlich patchu rekneme IIS bez toho, abych musel restartovat cely widle? Aha, taky nijak ... na tuxu zcela bezne patchu libovolnou sluzbu ... a restartu jen tu. S bonusem vejs, ze pokud nechci, neodpojim ani stavajici uzivatele.

Ale co bych nechtel od placeneho SW, ze ...

Zkusíme to ještě jednou. Dopatchoval jste, na stroji vám běží stará verze SW, a na disku máte novou verzi. Ta nová verze SW má nové pluginy, nové knihovny, nové verze resources. Jak zajistíte, aby vám ta stará běžící verze fungovala s novými pluginy, knihovnami a resources? Odpověď: nijak, a váš SW si nejspíš nabije čumák.

Ve Windows samozřejmě můžete zastavit službu, pak jí opatchovat, a poté znovu nastartovat. Pokud službu před patchováním nezastavíte, vyzve vás instalátor k restartu. Někdy si to zkuste.

Na stanici je ta minuta naprosto nezajímavá. Na serveru musíte stejně službu zastavit před patchováním i na Linuxu, protože nechcete riskovat, že něco zmršíte díky tomu, že zbytek souborů nesedí verzí s běžící binárkou. Koukněte se třeba na patche na MS SQL Server - před instalací službu zastaví. Kupodivu instalace netrvá půl hodiny :)

Instalátor vás vyzývá k restartu celého stroje proto, že není triviální určit všechny procesy, kterých se změna může dotknout. Pokud nemáte čas na pár minut plánovaného downtime, tak použijte HA cluster.

Pokud mám jen GPRS připojení a server je v Hong Kongu... tak se o něj nejspíš stará někdo kdo je blíž :). Jinak round trip do regionu APAC je cca 150ms, což se dá v pohodě přežít.

Jo ... to slysim ceklem pravidelne ... predevsim notebookari jsou pokazdy kdyz dorazej nedseny, ze pripojej notes do site, a muzou jit na cely dopoledne na kafe ... nez se jim nainstalujou widli aktualizace a 10x restartne komp.

Instalace patche na M$ SQL trva klidne nekolik hodin.

Resi se to tak, ze se widli servery proste neaktualizujou vubec ... a to samozrejme taky znamena, ze naprosto nepripada v uvahu je pustit kamkoli mimo interni site. Ona totiz jeste prichazi dalsi prdel, ze nikdy nevis, co a proc se vlastne aktualizuje, takze se ti naprosto sklidem stane, ze ti srv po widlich aktualizacich uz nenastartuje. Info ktery se doctes je tak ve smyslu "bezpecnostni aktualizace".

Ad Resi se to tak, ze se widli servery proste neaktualizujou vubec - to děláte možná vy, poté co na SQL Server aplikujete crack, jak jste tu psal :)

Ad Info ktery se doctes je tak ve smyslu "bezpecnostni aktualizace" - to proto, že původním popisům uživatelé nerozuměli. Když ve Windows Update kliknete na More Information,

Vyjma toho MS vydává Security Bulletin, kde jsou vydávané patche popsané na jednom místě. K tomu tam mají i webcast.

Dost mě překvapuje, že se snažíte administrovat Windows, a neznáte tyhle základy. Asi byste si měl dát školení.

Ad protoze jsou uzivatele debilove - ti "debilové" jsou manageři, účetní, důchodci, žáci ZŠ apod. Nestudovali informatiku, nerozumějí a nechtějí rozumět popisům jako "fixes buffer overflow in protocol handler library ABC version 7.22.33.4". Chtějí popis, kterému rozumí. A popisu "security update for Windows 8" rozumí.

Ad kdyz mam padesat updatu, stravim pul dne lezenim po webu - četl jste i tuhle část mého příspěvku? Vyjma toho MS vydává Security Bulletin, kde jsou vydávané patche popsané na jednom místě. K tomu tam mají i webcast.

"To základní" přece vidíte po kliknutí na patch. Bezpečnostních updatů bývá za měsíc pár a jsou v bulletinu.
http://technet.microsoft.com/en-us/security/bulletin/ms14-apr

Pokud jste uživatel a nikoliv IT specialista, máte zaškrtnout automatickou instalaci.

Ty se hlavne na tom webu nic vic nedoctes. Stejne jako u chyb se tam doctes ze takovou neznaj, tak v pripade patchu se tam doctes, ze je doporucovano ji nainstalovat a ze muze vyzadovat restart. Pripadne pak kdyz po instalaci toho patche zjistis, ze to neco zkurvilo, tak mozna ... pokud je dostatecny mnoztvi nadavajicich/rvou­cich ... najdes nejaky clanek na tema, ze kdyz si o to napises, tak ti do mailu poslou odkas na nejaky hotfix, ktery to mozna spravi a mozna taky zmrvi jeste vic.

Apropos, kdybys mel z wsusu prolejzat vse, co se chce nainstalovat kazdej mesic, tak nedelas celej mesic nic jinyho. Jen nez se ti otevre z ty nepouzitelny konzole info o jediny zaplate, trva to klidne 10 minut ...

laeli ... tohle je vec vyresena uz tak asi 30 let ... a naprosto vpohode to funguje. Proste stara sluzba uplne vpohode pobezi libovolne dlouho po aktualizaci.

Ve widlich samozrejme nic takovyho nefunguje.

Stará služba běží po updatu neaktualizovaná. Navíc to přináší riziko, že natáhne aktualizovaný resource nebo aktualizovanou knihovnu, což může mít vést k velkému problému. Jak se to řeší na Unixech? Spoléhá se na štěstí :)

Ve Windows samozřejmě můžete po většině aktualizací pracovat s běžící službou či aplikací, dokud nerestartujete. Pochopitelně to obnáší stejná rizika, jako na Unixech. Proto se serverové aplikace (SQL Server, Exchange) před většinou patchování shazují.

Od toho jsou knihovny verzované, a služba vyžaduje i verzi (major). Minor verze musí zachovat kompatibilitu. Pokud tomu tak není, je prase programátor.

A u resourců.... většina služeb nemá resourcy závislé na verzi služby. (Webservery májí jen textové konfiguráky, a podobně je na tom většina ostatních služeb).
Postgresql se nechají instalovat různé verze vedle sebe (major.minor) a admin pak udělá migraci až mu to přijde vhod. Změny v třetím čísle verze jsou skutečnými updaty a tam se prostě provede restat postgresu. V debianu je to tak, že se připraví všechny soubory, a i když se aktualizuje více balíčků, tak teprve při aktualizaci vlastního postgresu se služba na chvíli zastaví ale pak se zase spustí a teprve potom se pokračuje v aktualizaci ostatních balíčků. (Ale neznám administrátora, který by aktualizoval databázový server za plného provozu, pokud by už nedocházelo k "havarijnímu" stavu.)

Tiskové servery a mailové servery musí umět přežít restart počítače včetně nezpracovaných úloh, úlohy si zapisují v obousměrně kompatibilním formátu (většinou textovém).

Btw. zrovna instaluju W7 (nějaké starší cd). První update 100 aktualizací a restart, druhý update SP1 restart, třetí update 100 aktualizací a nevím co přijde pak. Každý update trvá půl hodinu stáhnout (UPC v Praze) a pak čtvrt hodiny instalace. A to před tím ještě půl hodiny příprava a instalace vlastních widlí.

I minor verze knihovny samozřejmě přináší odlišné chování - jinak by to nebyl update :). U některých serverových aplikací se resources nemění, u jiných se měnit můžou; u desktopových aplikací se nejspíš změní.

Jistě, tiskové a mailové servery přežijí restart počítače, to snad není nic zvláštního.

Ad instalace Windows 7: pokud instalujete ze 4 roky starého média, tak se nedivte, že se vám pak dotahuje spousta aktualizací. Příště použijte instalační média se Service Packem. BTW kdybyste si nainstaloval 4 roky staré distro Linuxu, také byste musel dotáhnout spoustu updatů.

V rámci MSDN Subscription, kde najdete instalačky Windows 8.1 včetně Update 1 (ovšem bez dalších aktualizací). Nebo alternativně tady:
http://windows.microsoft.com/en-US/windows-8/upgrade-product-key-only

V takom pripade treba pouzivat solaris, ZFS a snapshoty.

PS: komentare sa citaju ovela lepsie ak tam nie su vulgarizmy

Souhlas, komentare sa citaju ovela lepsie ak tam nie su vulgarizmy

Moja reč ty zmrd.

Bohužel s Vámi nemohu souhlasit. Snad pokud jde o XP, ale u Win 7 je to opravdu zoufale pomalé. Nemám-li zapnuté automatické aktualizace a dělám update jednou za tři měsíce ručně, tak to běžně trvá i půl dne (včetně stažení na 17 Mb/s lince). Zkušenost s několika průměrně výkonými NB, kde samotné WIN 7 běhají velice svižně.

To záleží na tom, jak je update velký (Service Packy jsou velké), jak rychle se tahá (17mbps neznamená že tou rychlostí opravdu taháte update), plus samozřejmě na rychlosti instalace. Teď jsem nechal běžet aktualizace na Windows 2008 R2. Bylo to nastřádané za rok a půl, a update trval hodinu.

A ted tu o hurvinkovi ... za hodinu se nainstaluje tak mozna prvni varka s prvnim .NET patchem .... pak nasleduje restart a objev dalsich 30 aktualizaci ... a po 1/2 roce to zcela vpohode hodi nejakcy 150 kousku a 5 restartu => 4+ hodin aktualizaci. A to kdyz se nahodou instalator nerozhodne zahlasit, ze se nepovedlo nainstalovat protoze #9082734928734# ...

Včera jsem po roce a půl instaloval stovky aktualizací, byly u toho tři restarty a trvalo to okolo jedné hodiny. O vaší neschopnosti přeložit si chybový kód a kouknout se do logu dané aktualizace jsme tuším už mluvili.

Jiste ... jak se preklada "doslo k nezname chybe 1654687" ... "o chybe nejsou zadne blizsi informace k dizpozici" ???

Utilita err.exe (ke stažení v MS Download Center) umí přeložit chybový kód na hlášku. Navíc najdete hlášky v logu aktualizace.

Volané funkce vracejí error code, a ten je číselný. Pokud situaci máte ošetřenou, tak kód chyby přeložíte na text, a případně podle toho kódu něco provedete. Pokud jde o neošetřenou situaci (což chyba zpravidla bývá), tak máte jen to číslo.
Utilita err.exe je kompilát hlavičkových souborů, které obsahují čísla, kódy a chybové hlášky. Na jedno číslo může vylézt víc hlášek, protože to číslo může pocházet z různých zdrojů. Naštěstí to v praxi není tak velký problém. Přesto to zjevně není nástroj pro koncového uživatele, ale pro admina.

Tak přestaň kupovat ruský hodinky.

Otázka: pokud potřebujte Windows jen na aktualizaci map GPSky (Garmin, pokud si pamatuji), proč automaticky instalujete aktualizace po bootu? Vždyť vám přece stačí si stáhnout mapu z Linuxu, a zabootovat Windows odpojené bez síťového adaptéru.

Blbosti tu pises leda ty ... videl sem zcela in natura registry velky temer GB ... a systemu trvalo hodinu, nez nastartoval ...

Pokud je databáze Registry velká 1GB, asi do ní nějaká aplikace zapisuje něco, co tam nepatří. To se samozřejmě dá zjistit, stejně jako se dá zjistit, proč systém dlouho startuje (ne, hodinový start není normální). Jenže to chce umět Windows administrovat.

Zapisuji se tam jen a pouze profilova data useru ... ale to chce aspon tusit o cem placas. Ja terminal server neprogramuju a hovadinu jako registry sem si nevymyslel.

Ještě jednou: Registry jsou pro jednotlivé účty oddělené. Pokud vám server nebo programy startují dlouho, admin hodný toho jména by měl být schopen zjistit příčinu problému a odstranit ho. Lamy reinstalují.

A demagogove plkaji hovadiny, ze ... samo, nekteri magori maji naisntalovany terminal server pro kazdyho usera zvlast. Mozna jim to pak i funguje.

S tím Word 2013 a Excel 2013 šlo o to Wine a Linux.

fdasfasdfasf (neregistrovaný) 81.91.210:word a excel v poho beha ve wine, manzelka je chtela, tak je ma v linuxu :-)

Jinak Office 2013 vklidu běží na netbooku Fujitsu Amilo Mini Ui3520 což vzhledem k Atom N270 a 1GB ram je dnes výkonově značný podprůměr.

Souhlas - když něco opisujete, tak v tom nemůže být moc kreativity. Proto jsem konstatoval, že za kreativitu mají nula bodů.

Funkčním OS na starý HW pro domácí použití mohou být ty původní Windows. Samozřejmě s jiným browserem, a nejlépe úplně odpojené od inetu. I tak ale odvedou daleko lepší práci, než ReactOS, na kterém ani po 18 letech nerozchodíte prakticky nic.

Obávám se, že ReactOS na tom bude ještě hůře, než popisujete. Btw. sám windows nepoužívám (na pracovním počítači i na osobním notebooku mám jen Linux. Pouze na domácím stolním jsou windows...), přesto mám s Windows XP od začátku celkem dobré zkušenosti. Uživatele totiž nezajímá jestli mu spadl celý OS (časťejší u Windows), nebo jen jedna aplikace (časťejší u Linux), výsledek je stejný - uživatel nemůže pracovat. Já mám rád Linux proto, že software, který používám, nemá ve Windows dostatečnou náhradu, u většiny uživatelů je to naopak.

Už dlouho se mi nestalo aby widle lehly a rozbily disk. Když spadne aplikace tak jdou do kelu i data, která jsou v paměti té aplikace, takže tam žádný rozdíl není. Rozdíl je jen tam, kde má uživatel otevřeno víc aplikací najednou a shodí mu to zrovna ta kterou momentálně nepoužívá pro vytváření dokumentu.

To že aplikace nemůže poškodit systém je pěkný koncept, ale v praxi to tak zdaleka není. Pokud aplikace obsahuje driver nebo kernelový modul, může provést prakticky cokoliv. Pokud jede čistě v user mode, může například provést DoS, změnit nebo smazat data, donutit jakoukoliv běžící GUI aplikaci k libovolné akci posláním window message/eventu atd.

Všechno to samozřejmě může, ale běžné linuxové aplikace (co si uživatel nainstaluje z distibuce, nebo zkompiluje) to nedělají. Běžné windowsové aplikace (co si luzr postahuje z netu) to dělají.

Fakt? Zdroj?

Aha. Takže když použijete driver modemu usbser.sys na zařízení, na které není stavěný, tak to driver nerozdýchá. A z toho podle vás plyne, že jde o chybu driveru. Další problém spočívá v tom, že musíte informace hledat v DDK a MSDN Library. Plus samozřejmě musíte zkoušet drivery na ReactOSu, i když Windows mají checked build a kernelový debugger. No comment :)

Podle mého názoru to, že driver se zařízením jiným, než pro které je zamýšlen nefunguje, je v pořádku. Ale to, že shodí jádro, v pořádku není. Zvláště pak u USB, kde se počítá s připojováním i potenciálně zlomyslných zařízení.

Driver je kernelový modul, a jako takový může shodit jádro. Jestli je to nebezpečné, to záleží od konkrétního problému.

Driver nema co shazovat kernel, to je chyba systemu.

Boha. Driver tohoto typu je kernelový modul, a v principu může shodit systém. A pokud se driver snaží přistupovat k zařízení typu A jako by to bylo zařízení typu B, tak se můžete dočkat překvapení v podobě BSOD.

Driver neschodí kernel přímo. Co jsem viděl chybné drivery, tak ty schazovaly HW. Přepsaly paměť, poškodily tabulku přerušení atd. Pokud ovladači dovolíte přístup k HW, tak bohužel může HW poslat do kytek.

Ovladac = zcela konkretni HW je nefunkcni. Kdyz mi nebude fungovat ovladac ... cojavim ... klavesnice, tak mi nebude fungovat ta klavesnice. Ze to prepise pamet nekde jinde, je chyba kernelu, ten mu nema co dovolovat prepisovat nekde nejakou pamet.

Ale jelikoz je ve widlich samo mozny vsechno, tak se neni cemu divit.

Videl sem trebas driver k nejaky externi krabici na seriovym portu, po jehoz instalaci se widle dostaly do stavu, ze uz proste nenastartovaly (vubec). Takhle se proste nemuze chovat normalne navrzenej system.

To si představujete dost naivně. Když natáhnete driver pro nějaké zařízení, tak s ním bude zkoušet pracovat jak se zařízením daného typu: psát do paměti tam kde zařízení má mít buffer, psát na porty které zařízení má mít, atd. Pokud se zařízení chová jinak než se chovat má, může to v některých případech dopadnout dobře; v jiných případech to může vést k výjimce v driveru, a tedy pádu kernelu.

Ad Videl sem trebas driver... o jehoz instalaci se widle... proste nenastartovaly - znovu opakuji, že kernelový driver má možnost provést v systému prakticky cokoliv (ve Windows stejně jako v Linuxu, AIXu, Solarisu). Takhle se chovají normálně navržené systémy.

Na USB je plná separace přístupu k paměti od zařízení. Vše je tvrdě pod kontrolou driveru. Souhlasím, že v případě bus master PCI/PCIe nabo FireWire to může být problém. Stejně tak v případě driveru řadiče EHCI/OHCI/UHCI/XHCI. Ale opravdu ten jednoduchý polling rozbočovač zvaný USB koncová zařízení separuje kompletně.

Jinak mikrojádra mohou dokonale separovat drivery a to i pro případ PCI/PCIe, pokud je k dispozici IOMMU. Linux to umí pro tunelování zařízení do virtuálů. Vlastní OS, stejně jako Win NT, je naneštěstí/naštěstí (prof Tadembauma sem teď tahat nebudu a sám jednoznačný názor nemám) monolitický.

Souhlas, na USB nemají zařízení přístup k paměti stroje. Ovšem driver přístup má.

Diskusi ohledně monolitického, mikro- a modifikovaného mikrokernelu považuji za neplodnou. Pokud přes to co jsem tu už psal a linkoval pořád nevíte, jak vypadá typický monolitický kernel, tak s tím nic nenadělám.

Opakuji otázku: se kterou verzí Windows jste pozoroval ten problém s víceportovými konvertory USB-RS232?

Dobrý den,

omlouvám se za velkou prodlevu v odpovědi. Ale s Windows se osobně potkávám opravdu strašně málo a na fyzickém stroji jen když někomu přímo nějaký problém pomáhám řešit, např ve firmě, pro kterou zajišťujeme vývoj kompletních laboratorních přístrojů a to jen tehdy, pokud nám vše chodí při připojení pod Linuxem a jsou problémy specifické pro Win. Přitom shazovat takový stroj s připojeným zařízením za více než 1M kč s rizikem ztráty dat je nepřípustné. I Windows na pro účely kontroly některých projektů ve škole Virtuálu mám k dispozici jen na jednom školním počítači, kde Win7 64 instalovalo do QEMU naše IT.

Report o padání od našeho partnera se mi v nějaké solidní podobě nepodařilo získat. Je to pro něj podprahová věc, vyřešil to tím, že požaduje ACM bezdrátové seriáky v režimu single channel. Ale nespíš to byly Win7.

Konečně jsem našel čas a získal správně podepsaný INF a varianty Firmware, abych to otestoval na tom školním virtuálu.

Inf k VID:PID, které byly avizované jako Winows standardně podporované se automaticky v MS službách nevyhledal. Takže jsem nakonec device přeflashoval zpět na naše VID:PID v režimu single. Nainstaloval se a fungoval.

Zkusil jsem předělat firmware se stejnou identifikací na multi a připojit ho k již nainstalované-enumerované instanci driveru.

Souhlasím, že to je drsný test, nedivil bych se chybovým hláškám a nefunkčnosti zařízení. Ale přišel okamžitě ukázkový pád.
win7-64-acm-multi-after-single.png. To jednoznačně svědčí o špatně napsaném driveru, který při specifické chybě ve čtených datech (záměna deskriptoru) ze zařízení shodí systém.

Vrátil jsem single firmware a systém běžel. Provedl jsem kompletní odinstalování driveru vřetně jeho vymazání z /Window/inf/o­emX{.inf|.pnf}. Přešel na multi firmware.

Windows se po restartu korektně pustily, inf nenašly a vytvořili zařízení bez obladače s popisem že se jedná o ACM. Při požadavku o update ovladače došlo okamžitě k pádu.

win7-64-acm-multi-fresh-install.png

Souhlasím, že inf pro multi v pořádku není. Pro single však odpovídá doporučení od MS. Opět upozorňuji, žádný kernelový kód, který by byl od někoho jiného než MS, ve hře nebyl.

Ověřil jsem tedy, že MS má chybu v ovladači. Neověřil jsem, že lze takto napadnout počítač bez vědomé instalace infu, protože na VID:PID, co by Windows měly umět, se mi nepodařilo vyvolat automaticky instalaci. Opravdu překompilovávat firmware na všechny možné VID:PID jsem nezkoušel.Pokud ale existuje nějaký USB ACM, který skutečně MS podporuje, tak jsem přesvědčený, že multi firmware bude chodit jako spolehlivý vypínač Windows. I pokud MS vůbec žádný USB ACM nepodporuje, tak pokud si uživatel jakýkoliv takový modem pořídí a s ním dostane v MS doporučeném stylu vytvořený INF, tak lze takový počítač okamžitě shodit vložením zařízení se shodnou identifikací, ale mírně změněnými deskriptory.

Jinak USB ACM serial class je opravdu velmi jednoduché rozhraní přímo definované v USB specifikaci. To je, pokud nemají být aktivovaná nějaká proprietární rozšíření výrobce daného zařízení, tak opravdu stačí enumerace na CLASS a INFy k jednotlivým VID:PID jsou zcela zbytečné. Na Linuxu to takto chodí běžně a spolehlivě. Na Windows by to vedlo díky mizerné kvalitě ovladačů k nepěkným překvapení a je tedy nakonec dobře, že je použití jakýchkoliv zařízení komplikované a musí to vždy pro každou verzi výrobce testovat a pevně dávat VID:PID. Ale overhead na straně tvůrců zařízení je to extrémně velký. Kdyby věnovali jediné procento úsilí nutného pro podporu MS produktů podpoře Linuxu, tak by obecná podpora všech zařízení byla na Linuxu nádherná. A i přesto, že podpora výrobců je ještě menší, tak na tom je dnes GNU/Linux systém s bezproblémovostí podpory mnoha zařízení lépe.

Bohužel Vaší reálnou identitu neznám, abych mohl poslat notifikaci e-mailem, tak třeba se zde časem objevíte.

S pozdravem,

Pavel Píša

e-mail k dohledání na mojí webové stránce
http://cmp.felk.cvut.cz/~pisa/

Zdravím,

bohužel těch informací je málo, a upřímně HW není úplně moje specialita. Windows podporují USB ACM. BTW existuje několik patchů, které by vás mohly zajímat:
http://support.microsoft.com/kb/918365 (pro XP)
https://technet.microsoft.com/library/security/ms13-081 (možné řešení toho BSOD)

Popsaný problém může být způsobený jak problémem driveru ve Windows, tak problémem na straně microcontrolleru na druhé straně. To že něco funguje s jedním USB stackem zdaleka neznamená, že je to bezchybné. Například existuje (existovala) řada USB klíčenek s bezproblémovou funkcí ve Windows, které ale nešly na jiných OS. Typicky se chyba projevila po změně pořadí operací, nebo prostě Windows chyby dané implementace skously, na rozdíl od jiných OS. Na Linuxu koukněte na unusual_devs.h, je to dost poučné čtení.

Pokud chcete problém opravdu řešit, na prvním místě bych se kouknul, jestli existují nějaké patche pro USB stack na straně microcontrolleru. Pak bych na zařízení pustil USB Compliance Test.
http://www.usb.org/developers/tools/usb20_tools/
http://compliance.usb.org/resources/GoldSuite%20Test%20Procedure.pdf

Pokud testy projdou v pohodě, můžete odinstalovat ve Windows drivery zařízení (nejprve musíte nastavit environment variables devmgr_show_non­present_devices a devmgr_show_details na hodnotu 1), nainstalovat NetMon a zachytit USB frames.
http://msdn.microsoft.com/en-us/library/windows/hardware/jj151572(v=vs.85).aspx

Pokud se vám nepodaří najít zjevnou příčinu chyby, můžete se vrhnout na debugging kernelu. První přiblížení je tady:
http://blogs.technet.com/b/askcore/archive/2008/11/01/how-to-debug-kernel-mode-blue-screen-crashes-for-beginners.aspx
Z toho dostanete minimálně stack trace. Pak můžete nastavit breakpointy, kouknout na kód a frames, a zjišťovat jak dál. Zkusil bych debuggovat ve virtuálním stroji - ušetříte si spoustu restartů.

Pokud ani tohle nepovede k výsledku, ČVUT má v rámci smlouvy se společností Microsoft zajištěnou podporu. Můžete se obrátit na ně. Je důležité jim sdělit, že je vaše zařízení USB compliant (pokud tedy opravdu je).

Mimochodem nemusíte přece řešit všechno sám. Pokud působíte na ČVUT, máte po ruce lidi, kteří mají zkušenosti s psaním driverů a debuggováním kernelu. Namátkou Zdeněk Čulík, Filip Kroupa, možná Jan Kravar... a jistě přibyli nějací noví. Na MFF UK působí třeba Martin Děcký, jeden z autorů HelenOS. Já také nedělám všechno sám. Pokud mám k dispozici odborníky, který jsou v dané oblasti produktivnější, svěřím práci jim.

Dobrý den,

za odpověď děkuji. Co se týče USB stacku, tak zrovna ten konkrétní pochází od kolegy z firmy http://mujweb.cz/porazil/zload.html . Mohu to zkusit alternativně s dalším stackem, který prvně psal můj diplomant pro 8051, ale postupně jsme ho s dalšími kolegy hodně přepsali a rozšířili o podporu LPC2148, 1768 a dalších. Mohu zkusit stejný profil naimplementovat nad tímto druhým naším používaným stackem. Zdojákay zde: http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/usb/ Nebudu tvrdit, že nemáme v našich implementacích chybu. Komplianci proti Windows nástrojům jsme zatím netestovali. Ale odladěné to máme i s vlastním driverem pro vlastní protokol včetně uspávání jak na Win8 tak na Win2k. Mezi verzemi jsou celkem nepříjemné rozdíly v tom, které Power IRP se volají mimo kontext threadu a tak, ale jde to zvládnout napsat tak, že to chodí všude.

Určitě děkuji za odkazy na testování, zkusím, co je z toho opravdu free a užitečné. Roční členské příspěvky USB konsorcia neplatíme - nejsou potřeba, ale k některým nástrojům tak možná přístup mít nebudeme. USB vendor ale máme koupené.

Časem zkusím i ty aktuální záplaty. I když to mi připomíná, že máme teď (po mnoha letech bezproblémového provozu) podezření, že se v případě našeho vlastního driveru pro naší řídicí síť a zařízení začalo u zákazníků s poslední verzí Win7 a Win8 nejspíš po nějakých updatech dít cosi velmi podezřelého. Když nastavím logování uvnitř našeho driveru, tak přes DebugView na vzdálené ploše u zákazníka občas odchytím divnou chybu URB/IRP, která neodpovídá žádným popsaným kódům a vypadá na nějaký overrun/chybný management bufferů a téměř bych čekal, že je to chyba OHCI/UHCI nebo EHCI driveru po update. Takže spíš budeme muset řešit jak u zákazníka zařídit zatím návrat k verzi driverů, která chodí a pak hledat jaké obezličky na straně našeho driveru nebo zařízení pomohou s tímto novým divným chováním Windows žít. Ale upozornění na masivní update USB infrastruktury je dobré vodítko.

Co se týče debuggingu Windows tak za poslední roky zkušenosti nemám. U vlastního KMD a WDM kódu jsme až tak moc pádů neměli a na vše stačil DebugView (tak jak říká Linus, kód se má psát tak, aby debugovat nepotřeboval nebo aby všechno potřebné pro testování vypsal sám).

Jak je to s debuggováním Windows jsem již roky nezkoumal. Naposled, když jsem měl ještě sériový terminál a Window NT 4 na dalším počítači. Ideální by to bylo přes GDB-stub v QEMU. Ale zatím jsem nezkoumal jaké jsou možnosti. Teda krokování a další věci přes GDB půjdou určitě, ale problém bude s debugovacími informacemi z MS kompilátoru. Pro ReactOS to jde. Před lety jsem si někde měl možnost pohrál i se SoftICE, ale to nevím, jestli ještě žije a ať legální nebo nelegální shánění uzavřených nástrojů mě moc neláká a pro vlastní vývoj je nepotřebuji.

Takže toto jsou naše aktuální problémy s Windows a za pomoc bych byl jistě rád. Na Linuxu veškerá naše zařízení byla testovaná týdny v kuse a proti mnoha verzím a počítačům, vše bez potíží, stejně jako nebyly roky potíže u zákazníků s Windows.

Ale všechno toto má minimum společného s tím, že Windows spadnou na své vlastní drivery u zařízení, které nemá možnost do systémové paměti sahat. Ale třeba máte pravdu a v těch updatech je to již opravené. Pokud ale není, tak si stále myslím, že je to informace zajímavá především pro MS.

Backtraky pádu Windows jsme svého času analyzovali, bohužel Win8 v QEMU se sice tváří, že se o uložení dumpu snaží, ale procenta přibývají tak pomalu (odhaduji to na mnoho hodin možná den), že jsem nikdy nevydržel. Možná nějaké nastavení MiniDumpu? Asi to budu muset znova hledat.

Tak zdravím a díky za odkazy i na kolegy, o některých jsem ještě nevěděl, jinak na předmět k Martinu Dětskému jeden můj bývalý student nedávno chodil, ale že se zabývá i Windows jsem nevěděl,

Pavel Píša

Ještě když se dívám na ty Bulletiny, tak cítím marnost nad marnost. Kdyby to bylo na Linuxu, tak tam mám GIT hashe a kouknu se u sebe do GITu, vidím, co se změnilo, jak se tomu přizpůsobily ostatní drivery a nebo třeba i najdu chybu v té změně a mám přímo e-mail člověka, který na dané řádce změnu provedl a kterého mám kontaktovat.

Přestávám vůbec chápat, jak je možné tak kritickou věc jako je jádro OS vyvíjet jiným stylem a pokud bych jako autor měl zájem, aby pro mé jádro někdo jiný drivery vyvíjel, tak mu tento nástroj nedat cítím jako něco zrůdného. Před 20 lety mi to až tak hrozné nepřipadalo, ale teď už je mi mého času a i ostatních mnohem víc líto a vzhledem k ostatním projektům, na kterých pracuji mi začíná připadat to, že nemám přístup k implementaci API nad kterým stavím obludné.

I když ono i v době, kdy jsem uvažoval o portaci našich driverů na Windows 95, jsem četl konferenci o VxD a i přes opravdu vstřícné a velmi dobře reagující přispěvatele přímo z MS mi to připadalo jako skupina nešťastníků (včetně těch z MS) tápajících ve tmě, bažinách a rozpadajícím se kódu.

Zdravím,

ohledně debuggingu Windows: symboly si můžete stáhnout z webu MS. WinDbg (a nejspíš i ostatní debuggery) umí také použít Microsoft Symbol Server, ze kterého si natáhnou potřebnou část a cachují ji lokálně.
http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
http://support.microsoft.com/kb/311503

Pro debugging driverů se také doporučuje použít checked (debug) build Windows. Ten postrádá řadu optimalizací, a naopak přidává spoustu kontrol. Checked build je k dispozici v rámci MSDN.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff543450(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549603(v=vs.85).aspx

Minidump si můžete snadno nastavit.
http://support.microsoft.com/kb/315263/en-us#method2

Většina firem nedá veřejnosti přímý kontakt na vývojáře, protože u rozšířenějšího SW by pak už vývojáři nedělali nic jiného, než komunikovali se zákazníky (což je mimochodem úplně jiný typ práce). Proto je mezi zákazníky a vývojáře vložené oddělení podpory, většinou s několika úrovněmi eskalace.

Zdrojáky Windows můžete coby univerzita licencovat v rámci Windows Academic Program. Pokud si vzpomínám, ČVUT bylo součástí tohoto programu. Další možnosti jsou Enterprise Source Licensing Program, OEM Source Licensing Program, MVP Source Licensing Program a Government Security Program.
http://www.microsoft.com/education/facultyconnection/articles/articledetails.aspx

Zkusil jsem vás trochu nasměrovat, snad to pomůže. Víc pro vás v rámci svých kompetencí bohužel udělat nemůžu, takže alespoň přeji mnoho úspěchů.

To je zajímavý námět pro tvůrce procesorů a operačních systémů. Vytvořit nějaký systém oprávnění k přístupu k HW, kde by kernel dokázal vymezit, co který ovladač smí a co nesmí. Zatím to možné není, ovladač buď nesmí nic (neprivilegovaný mód) nebo smí všechno (běží v privilegovaném módu).

Linux to pak ještě běžně řeší tak, že ovladač nesmí nic, ale může volat funkce jiného ovladače, který už smí všechno (včetně shození počítače). Taková metoda rozděl a panuj, kde do "privilegovaného ovladače" dáte funkce pro práci s HW a do "userspace ovladače" teprve dáváte nějakou logiku. U grafických karet to funguje výborně.

Jinak vám ještě závidím veskrze pozitivní zkušenosti s jinými OS. Já to štěstí neměl a s Kernel Panic a mrznoucím PC jen kvůli blbě napsanému ovladači jsem si opakovaně užil i s Linuxem.

No jo, jenže kdo řekne, co ovladač smí a co nesmí? To je u každého zařízení jiné. V důsledku to musí říct driver.
Ve Windows driver nepoužívá přímo přístup k HW; volá I/O Manager. Jenže I/O Manager samozřejmě nemůže vědět, jestli je volání správné.

Rozdělení driverů na kernel-mode part a user-mode part je fajn, ale přináší overhead. Ve výsledku je způsob toho rozdělení tak trochu černá magie, s tím že pro různé scénáře (včetně různých typů zátěže při přístupu na stejné zařízení) mohou vítězit různé modely.

Opravdu by me zajimalo, co je zajimaveho na tom, ze kernel neumozni ovladaci zapisovat do pameti, kterou mu nepridelil. Pak se totiz dost tezko muze stat, ze by prepsal data nebo dokonce kod neceho jineho. Tak nejak bych cekal, ze kernel po svem startu zacne zjistovat co vidi za HW, a podle nejakych pravidel sacuje sadu ovladacu. Kdyz najde, tak ovladac nacte a spusti. Ovladac si potom rekne co potrebuje (namapovat pamet, pridelit preruseni ...) a kernel se podiva, zda muze nebo nemuze splnit jeho prani.

Samozrejme chapu, ze kernel muze dost tezko ovladaci zabranit v tom, aby rekneme dal pokyn svemu HW "a ted zkratuj sbernici". Ale to, ze ovladac prestane komunikovat mi prijde jako zcela stadardni a snadno predvidatelny stav, pricemz neni duvod k tomu, aby se z toho system posr..

Samo, asi tezko chtit, aby zapsal log na disk, kdyz prave disk neni dostupny, ale porad nejak nevidim duvod k modry smrti s vypisem registru.

Seznamte se s konceptem hierarchical protection domains, aka protection rings. Normální aplikace běží v ring 3, aka user mode. Kód v user mode nemá možnost pracovat s I/O, a jednotlivé procesy mají oddělený paměťový prostor. Veškeré operace vyžadující I/O nebo manipulaci s paměti mimo adresní prostor aplikace končí výjimkou. Pokud aplikace chce takové operace provést, musí provést volání kernelu.
Kernel běží v ring 0, aka kernel mode. Kód běžící v kernel mode může provádět I/O operace, přemapovat paměťový prostor, zapisovat do paměti atd.

Kernelové drivery běží v kernel mode. Mají tedy možnost zapsat prakticky kamkoliv a udělat cokoliv. Kernel nemá možnost driveru zabránit například v zápisu do paměti libovolné aplikace.

Kernel navíc netuší, jak se k danému zařízení přistupuje. Každé zařízení má jiný interface, a jenom driver ví, kam se má vlastně zapisovat.

Pokud jde o selhání zápisu na disk, to samo o sobě systém nezboří. Zboří ho například to, že se snaží načíst stránku paměti ze swapu, a disk neodpovídá. V takovém případě totiž nemůže pokračovat v práci žádný program, který tu stránku paměti požaduje ke své funkci (a načtení té stránky ze swapu probíhá zpravidla právě proto, že ji nějaký program potřebuje).

Odborníci jistě odpustí zjednodušení, která v kontextu byla nutná. Vy byste ovšem potřeboval minimálně kurz základů OS.

A placal lael nam tu vysvetluje, jak M$ neumi napsat system, a proto jim to nefunguje. Mimochodem, ve widlich zcela libovolna aplikace muze zapisovat do pameti aplikace jine ... o nejaky ochrane si muzou uzivatele widli nechat leda zdat.

Mimochodem, dik zes potvrdil, ze widle bez swapu fungovat neumi.

...A placal lael nam tu vysvetluje...

+14
:D

Dodatek: teď se omlouvám Laeli, ale prostě ta věta je suprově napsaná (jde tam o tu souhru pismen L). Jde mi fakt jen o tu větu.

Na tuxovi pokud mi skleroza slouzi napr nefungovalo wotko, protoze ve wine nefungovalo ovladani mysi ... kdyz se resilo proc ze to, tak proto, ze wg si proste mys cet naprimo nekde z pameti ... coz je samo prasarna, ale ve widlich to funguje.

Samo, na jejich foru je hromada "reseni" problemu se hrou typu "tak to spustte jako admin, a musite jeste "as administrator" " ... a kupodivu, to mnoha lidem zafungovalo. Osobne taky na widlich pouzivam admin ucet - bez nej se na widlich delat da ... ale jen presne vyjmenovany ukony. Chudak neadmin si ani nezmeni casovou zonu nebo nepripoji tiskarnu.

Ad ve widlich zcela libovolna aplikace muze zapisovat do pameti aplikace jine - nesmysl. Běžte a zkuste si to.

Bezim a zkousim kazdej den ... naprosto vpohode. Jeste nejaka pripominka?

Super. Napíšete k tomu nějaké technické detaily? Vaše "naprosto vpohode" toho moc neřekne.

Vždyť to tady ti lidi píšou :-) Takhle fungují třeba trainery pro hry - modifikují údaje v paměti běžícího procesu:

https://answers.yahoo.com/question/index?qid=20071013004822AAH74YC

Tyhle techniky lze provést pomocí debugovacího interface, případně pomocí code injection. To ale samozřejmě neznamená, že procesy nemají oddělené adresní prostory.

Podobně byste mohl tvrdit, že Linux nemá oddělené adresní prostory, protože můžete použít LD_PRELOAD. A úplně stejně by to byl nesmysl.

Tady nikdo nenaznačoval, že procesy nemají oddělené adresní prostory. To je zase jeden z Vašich pokusů uhnout od tématu?

Myslím, že tato část vlákna už žije vlastním životem a vznikla z citace:
"Údajně je wine na prd ... hráči ve Widlích jsou zvyklí běžet s právy admina a ještě jsou zvyklí na to, že jeden proces zasahuje do paměti procesu jiného. Hezké ne?".

Což by se (asi) dalo shrnou jednou větou. Ano, z toho pohledu je wine "na prd", protože asi neumí (buď vůbec, či spíše ne úplně shodně jako u XP (XP!) /rozložením procesu v paměti/) implementovat OpenProcess a PROCESS_VM_WRITE a podobné meziprocesní aktivity.

To opravdu může být, v určitých případech, problém. Naneštěstí zrovna v takových případech, kvůli kterým část (část!) lidí zůstává na XP a nepřechází na novější systém (a to ani warez).

Pokud bychom to měli komentovat obecně ke článku, nikoli jako odpovědi v rámci vlákna, tak pro tuto sortu lidí není ReactOS či wine adekvátní náhradou. Pro ní prakticky neexistuje žádná náhrada.

Tuším, že XP povolí OpenProcess s PROCESS_VM_WRITE a PROCESS_VM_OPE­RATION /pro zdrojová admin práva/ na cizí procesy. Takže pak asi bude fungovat např. WriteProcessMemory. Nezkoušel jsem, odhaduji.

Ale, je-li používán tento způsob pro trainery (netuším), tak je to IMHO zcela legální postup (pro admin konta, admin práva, na XP). A emulátor by si s tím měl umět poradit.

Ano, to je jeden ze způsobů. Pokud máte SeDebugPrivilege, můžete otevřít jakýkoliv proces, číst a zapisovat jeho paměť, vytvářet nové thready, nastavit mu kvóty atd.

Dá se obdobným způsobem dostat z aplikace i k paměti, kterou si alokoval kernel /driver/, spuštěný v ring 0? To by snad jít nemělo. Ovlivnit by se tím měly dát jen procesy ring 3, spouštím-li OpenProcess z aplikace (ring 3) a ne z kernelu /driveru/. Nebo se mýlím a ring ochrání jen před execute a I/O?

O možnosti číst/zapisovat paměť kernelu tímto způsobem dost pochybují. Ovšem můžete natáhnout driver (který může být poměrně jednoduchý), a ten může použít objekt Device\Physical­Memory. Pokud si pamatuji, ve starších verzích Windows šel ten objekt použít i z user mode.

I pomerne velky blb by moh pochopit, ze driver a predevsim OS by se jaksi pri nalezeni neznameho zarizeni mel zahovat tak, ze nebude delat nic (a v idelanim pripade neco zaloguje) ... a ne ze system sejme.

Zato expert vaší erudice by si mohl všimnout, že zařízení jsou identifikovaná přes hardware ID. Autor původního příspěvku vzal HW nepodporovaný driverem, a vynutil zavedení nesprávného driveru tak, že změnil hardware ID v inf souboru. V druhém případě nastavil HW hardware ID neodpovídající modelu zařízení, takže došlo k zavedení nesprávného driveru.

Než budete psát o blbech, měl byste se vždycky třikrát zamyslet, co vlastně píšete. Jinak to totiž nutně vyvolává jistou asociaci.

To, že kernelový driver při neočekávaném deskriptoru zařízení, shodí celý systém, svědčí o cedníkovitosti driveru a neserioznosti jeho tvůrce (MS) nebo špatné implementaci celého systému.

Jinak rádi zařízení zapůjčíme k otestování, ať si to u MS spraví. Pokud by za to předvedli, jak má nad jejich usbser vypadat inf pro multiport, tak by nás to vysloveně potěšilo. Nemusíte mi psát vy, předejte to podpoře. Vy nejspíš svojí pravou identitu tajíte, když jsem Vám při vašem nepodloženém vychloubání před lety nabízel veřejnou diskuzi, tak jste se stáhl. Můj e-mail na FEL ČVUT najdete opravdu velmi rychle, tak můžete ukázat, že Vaše řeči myslíte vážně a pomoc zásadní bezpečnostní díru Windows opravit.

Za tím, že je driver usbser nepovedený, si stojím. Přitom jeho blokoce na konkrétní VID:PID již úplná zvrácenost. protože od toho, aby nebylo potřeba kvůli standardizovaným zařízením pořád přepisovat drivery a INFy, byly vymyšlené classy (u vzniku standardu USB přímo MS byl, takže by to mohl vědět) a slušné operační systémy raději připraví obecný driver spravovaný v mainline než aby nutily každého výrobce skládat vlastní bastl z milostivě utroušených zbytků.

Na druhou stranu mám velkou úctu Dave Cutlerovi za návrh koncepce NT jádra, i když je vysloveně škoda, že moderní OS nenavrhoval pro někoho jiného, např. IBM nebo DEC, od kterých většinu znalostí stejně načerpal. Ale to, co s tímto bezesporu slušným základem dělá MS, je spíš jen ke škodě. Další problém je, že některé věci, které byly koncepčně v roce 1992 revoluční jsou již dnes poněkud nevýhodné a koncept komunikace ovladačů přes interní, často nedokumentované IOCTL také moc k přehlednosti nevede. Takže mnohem flexibilnější a ze začátku možná i adhoc naimplementovaný soubor přímo volaných funkcí, jako je v jádře Linuxu, nakonec vede k lepšímu modelu a především výkonu. O RCU a dědičnosti priorit a dalších RT vymoženostech Linuxu si pak může nechat Windows jen zdát.

Ten driver se - jak jste psal - pro dané hardware ID nezavádí. Zavádí se jen pokud ho k tomu donutíte, například speciálním .inf souborem. Pokud například pro grafickou kartu nVidia vnutíte driver AMD, tak vás asi nepřekvapí, že zapíše někam kam nemá, a shodí tím systém. Proč vás tedy překvapuje, že usbser.sys nefunguje s HW, pro který není určený?

MS nemá co opravovat. Nejvýš by mohl přidat podporu pro jiná hardware ID, a provést související změny driveru. To je ovšem feature request, nikoliv bug fix.

Driver zjevně není takový problém napsat. Tady máte převodník USB na 4xRS232C, včetně driveru. Ten driver si zvládnul napsat každý výrobce, a také to každý zvládnul. Dost pochybuji, že u toho musel driver zkoušel na ReactOSu, a nedovedl si najít informace v DDK a na MSDN :)
http://www.ftdichip.com/Products/ICs/FT232BM.htm

Je pěkné, že vám můžu poslat email, ale nějak necítím tu potřebu. Když chcete něco napsat mě, můžete sem. A svůj email jsem tuším také v nějaké diskusi psal.

Souhlas, Dave Cutler vymyslel NT velmi pěkně. Kdyby je ale navrhoval pro někoho jiného, zřejmě by se nikdy neprosadily tako jako u MS. IBM je i proti MS naprosto nepružný mamut, který dovede spoustu produktů utopit v byrokracii ještě interně před uvedením, a samozřejmě zabili i produkty po uvedení (včetně PC a OS/2).

Jo, Linux je prostě super. Například prioritizace interruptů funguje tak, že se po dobu obsluhy interruptu zakážou všechna přerušení (local_irq_di­sable). Design s BKL, který se odstraňuje dodnes (recentně rozbitý na subsystem locky) je také skvělý. A latence je tak skvělá, že dodnes uživatelům chrčí zvukové karty. Sice formálně existuje možnost použít CONFIG_PREEMPT, ale ten kód je odporný hack, a je v takovém stavu, že se k tomu ještě žádné mainstreamové distro neodhodlalo (alespoň když jsem se naposledy koukal).

MS jde podle mě správným směrem. Má modulární a portovatelý kernel moderní konstrukce, plus v šuplíku Singularity OS.

Je hezké, jak přesně dokazujete to, o čem jsem povídal. Při povídání o čtyřportovém ACM seriovém portu odkazujete na driver FTDI. FTDI si raději vymysleli zcela vlastní USB protokol, který je zcela mimo ACM a napsali si kompletně vlastní driver, protože MS se k implementaci ACM standardu neměl a když ho přidal, tak stejně se zařízeními chodí jen někdy. Nakonec v některých případech jsme pro Linux a i Windows použili vlastní HW, který FTDI protokol simuluje, protože je to snadnější, než použít standard a drivery od MS. Přitom ten FTDI protokol je, co se USB komunikace týče, pěkný hnus a za dvojkovými huby, při připojení více zařízení, jsme si opravdu užili - teda na Linuxu. Ale řekl bych, že to bylo spíš vlastností dvojkového hubu a FTDI (v tomto případě originálního). Takže kolem a kolem, s MS systémem dodaný ACM driver je vlastně k ničemu.

O BKL se bavit můžeme, ale již pěknou řádku revizí v jádře není. Lokování a latence v Linuxovém síťovém stacku zatím ideální není. Ale vlastní jádro ve fully-preemptive variantě je opravdu úplně někde jinde než Windows. Teď jsme na několika výstavách ukazovali řízení robota přes I/O kartu pouze s PWM, IRC a ADC přímo na registrech a chodí to spolehlivě. Při použití sched FIFO a mlockall (zakázání odswapování řídicího tasku) drží časování dokonale. Pro jiné aplikace toto řešení s kódem generovaným z Matlabu/Simulinku používáme do 20kHz (problém je jen na deskách BIOSem, který aktivuje SMI a s tím se moc udělat ze strany OS nedá). A to se ve všech případech bavím o normálních tascích v user-space. Žádné kernelové programování nebo dokonce soft-PLC executiva napsaná mimo Windows, která ve volném čase přepíná na Windows. Jinak, pokud to MS neopravil, tak dědičnost priorit na běžných Windows nikdy pro mutexy neimplementoval a pouze později přidal nějaké random boostování pro ošetření těch nejkatastrofál­nějších situací. Něco jsem slyšel, že na WinCE to měl nějak trochu lépe. Také vyčítat Linuxu něco okolo priorit IRQ od zastánce systému, který po celou dobu IRP dispatch blokuje kompletně přeplánování (nebo tomu alespoň tak do XP bylo), je úsměvné. Standardní Linuxové jádro zatím neumí pouštět obslužné rutiny přerušení ve vláknech, ale RT varianta to umí, a to již není, co se týče latencí, jen o level lepší než Windows ale rovnou o několik řádů.

Nevím, jak má poslední MS Win naimplementované mutexy. Linux využívá implementaci na bázi futexů, kdy i robustní mutex s priority inheritencí nepotřebuje v bezkolizním případě volat jádro. Opět bych čekal, že je to lépe naiplementované než Windows WaitForSingle/Mul­tipleEvents (Jejich kód jsem si mohl přečíst jen v ReactOSu, ale při dodržení API se nic moc lepšího nenabízí). A tak bych mohl jít dál a dál.

Jinak ty problémy s hlášenými chybami v URB completion máme v úplně jiném, vlastním driveru a to je ten, který jsem testoval na ReactOSu.

Porovnávat driver grafické karty s PnP zařízením, které může přidat každý kolemjdoucí a pro standardní zařízení se systém ani nikoho na nic před instalací ovladače neptá, je poněkud účelové a prozrazuje jakým způsobem se uvažuje v Redmondu o bezpečnosti. Souhlasím s tím, že bez IO MMU nelze systém spolehlivě ochránit proti záměrnému útoku z PCI zařízení nebo proti jeho závažné chybě, ale na PCI je pouze řadič USB, jím připojená zařízení lze ohlídat dobře a proti jejich chybám by systém měl být odolný nebo se o to alespoň trochu snažit.

Krátká otázka: na které verzi Windows měli kolegové problém s těmi zařízeními, které implementují více než jeden COM port? Předpokládám Windows XP?

V FTDI implementovali ten driver už kdysi pro Windows 2000.

Linus projevil svou genialitu mimo jiné tak, že Linux "navrhl" s BKL. K jeho odstranění došlo dvaceti(!) letech, a to tak, že byl rozbit na několik menších locků.

Jádro ve fully-premmptive konfiguraci žádné mainstreamové distro nepoužívá. Podle diskusí autorů dister je tak zabugované, že to nepřipadá v úvahu. Navíc je jeho výkon v běžném použití dost mizerný.
IRP dispatch ve Windows blokuje interrupty s nižší prioritou (alespoň ve Win2K, kde mě zajímalo). Nicméně jde o rychlou akci, a zbytek obsluhy přerušení je preemptivní. Na Linuxu jsou po dobu zpracování přerušení zakázána všechna přerušení, což vede k příšerné latency.

Pokud chcete RTOS, doporučuji Windows s RTX64, nebo Windows CE.

Windows mají hromadu synchronizačních primitiv, a upřímně to není úplně moje hobby. EnterCritical­Section v bezkolizním případě nepropadá na kernel, na rozdíl od WaitForSingle­Object. Pak jsou tu levné atomické operace: InterlockedIn­crement, InterlockedExchange apod., plus interlocked singly linked list (SList). Velmi rychlé jsou Slim Reader/Writer Locks (v .NETu System.Threadin­g.ReaderWriter­LockSlim). Tady najdete novinky implementované ve Vistě, včetně nějakých čísel:
http://msdn.microsoft.com/en-us/magazine/cc163405.aspx

Obecně platí, že když má útočník přístup k vašemu HW, tak to obnáší rizika. Riziko plynoucí z toho, že modifikuje .inf soubor driveru a pak připojí USB zařízení, mi připadá zanedbatelé v porovnání v možností že vytáhne napájení ze sítě nebo rozmlátí stroj kladivem.

Už to tady někdo psal, že kdysi bývaly Vaše artumenty celkem na úrovni. Vy jste ovšem zamrznul v době před 5 lety. Zatímco tady plkátem v diskusích pořád to samé dokola, okolní svět se posunul značně dál. BKL bylo kompletně odstraněno z kernelu 2.6.39 (pokud se nemýlím) a překvapivě pro Vás linux disponuje hard real time MICROkernelem (nikoliv modifikovaným).

Muzete to prosim upresnit s tim RTOS mikrokernelem, mel jsem za to, ze Linux je monoliticky kernel ,ale pak nechapu to vase tvrzeni.Mozna tak l4linux,ale ten je snad porad monoliticky s vlastnostmi l4.Dekuji.

Třeba: http://en.wikipedia.org/wiki/RTLinux

Jestli tomu rozumím dobře, tak:
1. Máte kus HW, ke kterému nemáte ovladač
2. Dospěl jste k názoru, že ovladač jiného zařízení je natolik podobný, že by fungovat mohl
3. Pracnou úpravou .inf souboru jste dokázal zmást OS natolik, aby se pokusil onen ovladač spustit i pro nepodporovaný HW
4. Po připojení daného HW to teď havaruje a shodí systém

Pokud ano, pak nějak nechápu, proč se tomu někdo diví. Ovladač evidentně s daným zařízením nepracuje, ale ani nemá ambice to zkoušet. V základním stavu se tudíž po připojení daného zařízení nic nestane. OS reaguje korektně (zařízení ignoruje), byť nás tím zjevně nepotěší. Teprve ruční zásah do .inf souboru vede k havárii systému. Trochu mi to pak připomíná stížnost typu "Linux je mizerný OS, přepsal jsem pár řádků ve zdrojácích jádra a teď už to ani nenabootuje".

Kritiku "MS Windows nemají pro velkou množinu HW ovladač" ovšem zcela chápu a sdílím.

Ja to chapu jinak ...

1) ma HW, ktery funguje zcela stejne jako jiny obdobny HW, jen je toho integrovano vice v jedne krabce.
2) veme ovladac, ktery vpohode spolupracuje s nekolika samostatnyma krabkama
3) upravi inf proto, ze ma sice zarizeni stejne kategorie, ale M$ se rozhodl v inf vyjmenovat jen konkretni kusy
4) widle se zhrouti, protoze si nedovedou predstavit, ze bude vice zarizeni integrovano a ohlasi se jediny ID.

Mimochodem, na tohle tema sem se bavil pred chvili s kolegou, rikal ze se mu nekde vali USbcko (flashka), ktera widle spolehlive sejme. To jiste potesi, kdyz nekdo dojde do kramu, tak si proste podle vzhledu vybere (protoze podle ceho jineho, ze ...), prijde domu/do firmy/... a vrazenim do konektoru sejme system.

Vaše představy jsou až dětsky naivní. Pokud máte více COM portů visících na jednom USB zařízení, jsou ty porty vedené jako různé funkce toho samého zařízení. Řekněme jako kdybyste měl více klávesnic na jednom USB zařízení. V takovém případě se driver musí pochopitelně chovat jinak, než kdyby mělo zařízení jedinou funkci.

Ad vrazenim do konektoru sejme system - pokud pustíte někoho k HW, přináší to rizika. Já mám doma velký kondenzátor, a když ho v krámu připojím do USB portu pokladny, tak to v ní pěkně zajiskří, a bude vymalováno. Vyjma toho vlastní také velké kladivo. Jo a zapomněl jsem, že umím odstavit počítač tak, že vytáhnu napájení ze zásuvky :). Opakuji: pokud kohokoliv pustíte ke svému HW, přináší to bezpečnostní (a jiná) rizika.

Srovnávat sejmutí systému zastrčením USB klíčenky do USB portu, tedy to, co by každý očekával, že je správně, s kondenzátorem... prostě ROTFL :-D

Přesněji zastrčení USB klíčenky do portu po modifikaci .inf souboru driveru, který donutí driver pracovat se zařízením, na které není stavěný.

Jak jsem psal, pointa je v tom, že když dáte někomu přístup ke svému HW, obnáší to rizika. Můžete se vám to líbit nebo nelíbit, ale to je tak jediné, co s tím můžete dělat.

Nikoli, bavime se tu mimo jine o strceni scela standardni USB klicenky do zcela standardne nainstalenych widli, pocemz se ty widle se 100% uspesnosti slozej.

No vidis lael, ja kdyz vrazim do USB sroubovak ... tak se nestane ... vubec nic ... jake prekvapeni u dle normy fungujiciho USB portu. Tech maximalnich 500mA co tam tecou totiz tak nejak tu desku nemuze vyvest z rovnovahy ... a presne stejne se chova kazde rozumne zarizeni s porty dostupnymi venku.

A podotykam, ze i kdyz stejny sroubovak vrazim do primarniho vystupu zdroje (ktery je vpohode schopen dodat vic nez 30A - cimz se da celkem vpohode svaret, tak se ... voiala ... opet nestane VUBEC NIC ... protoze jaksi vyrobce toho zdroje nebyl debil ...

Ve finale.. usb klicenka je jaksi primarne svou funkci urcena ke strkani do USB portu.

Jen s tím šroubovákem nesmíte otočit, protože pak se něco stane :)

Odpálit USB port přepětím nebo zkratem většinou bohužel není problém. Při troše smůly to odnese i board. Kde jsou ty doby, kde se I/O porty oddělovaly optočleny.

Pokud vás problematika zajímá, koukněte třeba sem:
http://powerelectronics.com/power_management/power_ics/Overcurrent-protection-IC-limits-PET-810.pdf

Protože ten ovladač i HW odpovídají definici USB organizací specifikované třídy zařízení. Takže na pro OS splňující standard - např. Linux, není třeba žádný nový ovladač psát. Zařízení se rozpozná, nenajde se exact match, tak se vezme class ovladač a vše chdodí. Ale na Windows class driver od MS chodí hůře, než když se strefíte do adhoc protokolu a driveru někoho jiného. A ten class je stejně ještě blokovaný jen na několik VID:PID.

Ten driver prostě podporuje určitě hardware ID. Pokud vynutíte jeho používání s jiným HW, je to váš problém.

Co přesně jsi na myšlence "pro OS splňující standard - např. Linux, není třeba žádný nový ovladač psát. Zařízení se rozpozná, nenajde se exact match, tak se vezme class ovladač a vše chdodí." nepochopil? Aha, vono z toho plyne, že to MS dělá blbě. No to je ovšem zcela nepřípustný závěr, že.

Pokud kritizujete to, že by Windows mohly obsahovat driver s širší funkcionalitou, tak samozřejmě souhlas. Pokud kritizujte to, že driver nefunguje s driverem pro který od výrobce není určený, tak nesouhlas.

Co je specielniho na seriovym portu?

V tomto případě to, že je součástí čipu, který je připojený na USB sběrnici, a proto se s ním nezachází jako s UARTem 16550 na klasickém PC.

Zarizeni muze mit zcela libovolny descriptor od vyroby, a vyvojar systemu stim musi pocitat. Stejne tak jako muze mit sitovka libovolnou MAC adresu. Prekvapive kdyz si vyberu ovladac k jine tiskarne nez jakou mam pripojenou, system to prevazne nesejme ... .

Zařízení má hardware ID, které mu nastavil výrobce. Pokud pro zařízení zavedete driver, který je určený pro jiné zařízení, poměrně logicky můžete systém shodit.
Ovladače tiskárny nejsou kernelové drivery.

Pripojuji se k nazoru s ohledne zpraseneho ubsser.sys, zejmena ve Windows 8.1 (update). Soudruzi tam udelali oproti predchozim verzim dalsi (nebo spis jine) chyby pokud jde o USB CDC komunikaci.