Názory k článku
ReactOS už umí tisknout, ale jen přes paralelní port
-
To si nemyslím, stejně jako existence Nokie 3310 nezvyšuje diverzitu současného trhu s telefony. Něco, co nelze reálně používat, tak se dost těžko dá považovat za konkurenci.
Před 10 lety mi to přišlo zajímavý, dneska se obávám, že i kdyby nějakým zázrakem do 2 let vytvořili verzi 1.0, nebude vůbec k ničemu.
-
Unknown (neregistrovaný)
Pokud to dotahnou dostatecne daleko (a zatim nic nevypovida o tom, ze by to chteli vzdat), pujde na tom poustet libovolny SW pro Win32 (coz znamena miliony programu napsanych cca od roku1995), pokud se tedy drzi dokumentovanych funkci API. O tomhle si soucasny Linux diky neudrzovanym knihovnam muze nechat jen zdat...
-
Ad Ona se totiz dost casto microsoftu ta dokumentace rozchazi s realitou - máte k tomu prosím nějaké konkrétnější informace?
Ad Je to hlavni duvod, proc dost casto aplikace nebezi na novych windows - tam je hlavním důvodem spoléhání na nedokumentované vlastnosti systému. Abych neopakoval co jsem psal někdy recentně, tak to sem pastnu:
Aplikace mají ve skutečnosti v naprosté většině případů problém když jsou špatně napsané (nebo když obsahují kernelové drivery). Typické je třeba vykrádání zdrojů: autor aplikace chce použít ikonu nebo animaci. Takže třeba animaci kopírování souboru vytáhne z knihovny Shell32.dll. V další verzi Windows je ta animace úplně jinde, protože nejde o dokumentovaný interface. Aplikace pak spadne na výjimku, protože se autor ani neobtěžoval ošetřit situaci, kdy tu animaci nedokáže natáhnout. Díky tomu MS nechává v knihovnách shellu i ikony které už léta nepoužívá, protože jinak by špatně napsané aplikace padaly. Animace i ikony se samozřejmě dodávají v rámci SDK, ale autoři aplikací jsou prostě často prasata. Takových příběhů, které ukazuj až neuvěřitelné prasárny autorů aplikací, mají v MS tuny.
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/26/485133.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx
http://technet.microsoft.com/en-us/magazine/2006.11.windowsconfidential.aspx
http://technet.microsoft.com/en-us/magazine/2006.10.windowsconfidential.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/01/459023.aspxDalší problém je v tom, že celý SW průmysl je v dlouhé krizi. SW se často píše v C/C++, což je jazyk který vyloženě svádí k chybám. Koukněte se jen na bezpečnostní zranitelnosti za minulý rok. Android 523 zranitelností, Flash Player 266, linuxový kernel 216, Adobe reader 204, Google Chrome 172. Týmy nejlepších programátorů na světě sedí nad výrobou browserů které parsují pár set HTML tagů, a pluginů pro browsery které umí přehrávat stupidní a obtěžující animace, a výsledek má stovky zranitelností ročně. Nemluvě o počtech bugů, které budou ještě řádově vyšší. V takovém světě bohužel nepřekvapí, že sem tam nějaká aplikace nefunguje s novou verzí OS.
https://www.bleepingcomputer.com/news/security/android-was-2016s-most-vulnerable-product/ -
Martin DrábStříbrný podporovatel
> Ad Ona se totiz dost casto microsoftu ta dokumentace
> rozchazi s realitou - máte k tomu prosím nějaké konkrétnější
> informace?Třeba zde: https://msdn.microsoft.com/en-us/library/windows/hardware/mt764088(v=vs.85).aspx. Pokud se podíváte do WDK, tento callback má pouze tři parametry (parametr Create se zdá být zkopírován z obdobných callbacků, ale pro reportování vzniku/zákinu procesů a vláken). Ano, píšou tam, že části dokumentace jsou pro ještě nevydané verze, ale zrovna tento callback (a funkce PsSetLoadImageNotifyRoutine, kterou se registruje) jsou tu s námi již minimálně od Windows 2000 v tříparametrové formě.
Nebo když se podíváte na dokumentaci týkající se obsluhy požadavků IRP_MJ_POWER, najdete různé názory, jak s takovými požadavky pracovat (ne že by došlo ke sporu, ale na zmatení to stačí). A zrovna u těchto požadavků se chybná obsluha hodně špatně testuje (mnohem hůře než u špatné obsluhy PnP), protože se projeví třeba jen na pár konfiguracích z tisíce, a to ještě náhodně. A Driver Verifier nepomůže.
Ale obecně si na chybovost dokumentace stěžovat nemůžu (minimálně u částí, se kterými přicházím do styku). Spíše s než vyloženě chybným tvrzením jsem se setkal s případy, kdy mi v dokumentaci některé informace citelně chyběly (ale oproti dokumentaci jiných knihoven (často opensource) je to pořád paráda), takže bylo třeba použít metodu pokus-omyl.
Pokud je kernel driver napsaný rozumně a nevyužívá vlastností, které s Windows XP +- skončily (např. filtrování síťového provozu přes TDI), měl by běžet i na Windows 8/10. Naopak mi testování na Windows XP odhalilo problémy, které se na novějších verzích neprojevovaly (rozhodně ne deterministicky).
-
Odkazujete na předběžnou verzi dokumentace, u které je jasně psané, že se před vydáním může výrazně změnit. Nevidím tu rozpor mezi dokumentací a realitou.
Ad obsluhy požadavků IRP_MJ_POWER, najdete různé názory, jak s takovými požadavky pracovat - nevím jaký je zdroj těch různých názorů, ale pokud jsou z MDSN a není mezi nimi sporu, tak může být nešťastné pokud jsou na různých částech dokumentace, ale neviděl bych to jako rozpor mezi dokumentací a realitou.
Ad Spíše s než vyloženě chybným tvrzením jsem se setkal s případy, kdy mi v dokumentaci některé informace citelně chyběly (ale oproti dokumentaci jiných knihoven (často opensource) je to pořád paráda) - souhlas.
-
Martin DrábStříbrný podporovatel
> Odkazujete na předběžnou verzi dokumentace, u které je jasně psané, že se před vydáním může výrazně změnit. Nevidím tu rozpor mezi dokumentací a realitou.
Ony na ní vedou odkazy z popisu rutiny PsSetLoadImageNotifyRoutine (je tu s námi od Windows 2000), protože mnou odkazovaná stránka popisuje právě vlastnosti callbacku, který se výše zmíněnou funkcí registruje. Jen se před nějakým časem z této stránky stala předběžná dokumentace a callbacku přibyl jeden parametr. Pokud se podíváte na definici toho callbacku ve WDK, uvidíte, že má pouze tři parametry (rozhodně od DDK 2003).
Kdyby vytvořili PsSetLoadImageNotifyRoutineEx a k ní popis callbacku a označili to jako předběžnou dokumentaci, tak s tím nemám žádný problém. Takhle se musím spoléhat na hlavičkové soubory a doufat, že je ta dokumentace opravdu špatně a nikoho nenapadlo, že by definici toho callbacku v příští verzi WIndows změnil.
> Ad obsluhy požadavků IRP_MJ_POWER, najdete různé názory, jak s takovými požadavky pracovat - nevím jaký je zdroj těch různých názorů, ale pokud jsou z MDSN a není mezi nimi sporu, tak může být nešťastné pokud jsou na různých částech dokumentace, ale neviděl bych to jako rozpor mezi dokumentací a realitou.
Spíše je to o tom najít si nejkonkrétnější popis obsluhy jednotlivých požadavků, případně si najít popisy všechny a provést jejich sjednocení. Na MSDN máte obecné povídání o obsluze IRP_MJ_POWER, konkrétní informace k obsluze jednotlivých typů power poždavků a ještě pár obecných povídání. Kdyby si někdo dal tu práci a trochu tuto část zrevidoval, bylo by to fajn. Bohužel tady ani příliš nepomůže nahlédnutí do ukázkových či jiných ovladačů, protože každý si power požadavky obsluhuje po svém a má štěstí, že pro daný typ zařízení, pro která je obsluhuje, se nic nestane.
-
Ad Jen se před nějakým časem z této stránky stala předběžná dokumentace a callbacku přibyl jeden parametr. Pokud se podíváte na definici toho callbacku ve WDK, uvidíte, že má pouze tři parametry (rozhodně od DDK 2003) - ve WDK je to správně (koukám na to v Help Vieweru), a na webu je nějaká předběžná verze.
Ad musím spoléhat na hlavičkové soubory a doufat, že je ta dokumentace opravdu špatně - na webu je jasně psáno, že je to předběžná dokumentace, která se může před finalizací výrazně změnit.Ad je to o tom najít si nejkonkrétnější popis obsluhy jednotlivých požadavků, případně si najít popisy všechny a provést jejich sjednocení - ano, jak jsem psal, je to popsané v různých částech dokumentace ("obecné povídání" a pro jednotlivé typy driverů), což není dvakrát šťastné.
-
ehmmm (neregistrovaný)
Hele Laeli, ja chapu, ze te v MS asi dobre platej, ale tak to proste je. (A nejen u MS.) Bylo to tak i v DOSu, tam ty nedokumentovane funkce byvaly i docela dobre zdokumentovane. Dodnes mam cerne svedomi, ze jsem pouzival kradeny Sysman. A jednou jsem snad psal i Microsoftu, kdyz se nejaka API funkce pro prochazeni sdilenych adresaru lisila od dokumentace. Tusim, ze slo o to, ze dokumentace byla opsana z Win NT, ale ve Win 98 to navzdory dokumentaci fungovalo jinak. Myslim, ze dokumentaci tenkrat upravili, coz byla skoda, protoze ja spis potreboval, aby se to ve Win98 chovalo jako ve WinNT.
-
Nedokumentované funkce sice může zdokumentovat třetí strana, ale to nijak nezaručuje, že budou k dispozici i v další verzi OS.
Ad Tusim, ze slo o to, ze dokumentace byla opsana z Win NT, ale ve Win 98... - ehm, opravdu se tu chceme bavit o stavu MS dokumentace před 19 lety, u produktu který je 11 let po ukončení podpory?
-
PPK (neregistrovaný)
Seznam veci na ktere sem pri svem dlouholetem vyvoji pro windows narazil si nedelam. Zdrojaky si schovavam a kdyz neco pouziju znova a ono to nefunguje podle dokumentace tak se kouknu do starsiho zdrojaku jak to opravdu funguje.
Konkretnejsi infomace jsou treba komentare v msdn library. Ani taj zakladni vec jako windows datovy typy nemaj spravne zdokumentovany https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
Tvoje nesmysly o ikonach a c/c++ jsou naprosto smesne. Priste si nech od sveho chlebodarce microsoftu poradit neco realnejsiho. -
Ad Konkretnejsi infomace jsou treba komentare v msdn library - a kolik z těch komentářů je chybných nebo úplně mimo?
Ad Ani taj zakladni vec jako windows datovy typy nemaj spravne zdokumentovany - přijde mi to jako dost dobrá dokumentace. V komentářích vidím věci které jsou dokumentované zvlášť v Large Integers, poznámku že nějaký typ není podporovaný ve VS2010 atd.
Ad Tvoje nesmysly o ikonach a c/c++ jsou naprosto smesne - co je konkrétně směšné na resource stealingu? Bylo to popsané hned v prvním zdroji, který jsem linkoval.
https://blogs.msdn.microsoft.com/oldnewthing/20051026-44/?p=33613/ -
PPK (neregistrovaný)
Jo takze microsoft ma na strance s datovyma typama chyby... ale je to vlastne v poradku, protoze nekde jinde to maji mozna spravne ? A ty komentare pod tim, co na ty chyby poukazujou jsou co ? Pan asi neumi cist... asi absolvent vzlastni skoly. Ukazka jak je na tom microsoft blbe, kdyz nedokaze zaplatit ani slusnyho trolla.
-
robotron (neregistrovaný)
Díky tomu MS nechává v knihovnách shellu i ikony které už léta nepoužívá, protože jinak by špatně napsané aplikace padaly.
To je nahodou naprosto uzasny, neni nad ty nostalgicke chvilky, kdy si clovek prohlizi neumely 4bitovy ikonky k programum jako PC-Tools, dBase, nebo X klientum s napisem [d][i][g][i][t][a][l].
-
j (neregistrovaný)
"máte k tomu prosím nějaké konkrétnější informace?"
Mame lulane, daval sem to sem uz nekolikrat ... specielne pro tebe tedy znova ...
mklink
Vytvorí symbolicky odkaz.
MKLINK [[/D] | [/H] | [/J]] Cíl Odkaz
/D Vytvorí symbolicky odkaz na adresár. Vychozí je symbolicky
odkaz na soubor.
/H Vytvorí pevny odkaz namísto symbolického odkazu.
/J Vytvorí spojení adresáre.
Odkaz Urcuje název nového symbolického odkazu.
Cíl Urcuje cestu (relativní nebo absolutní), na kterou novy odkaz
odkazuje.A ted chci videt, jak presne v souladu s timhle textem udelas ten link.
-
Martin DrábStříbrný podporovatel
Užití je celkem jasné:
mklink <název_linku> <cíl>
(ve Windows 8+ už mají, zdá se, tu chybu v nápovědě opravenou).Pro adresáře použijete
mklink /D <Link> <Cíl>atd. Ono se tady trochu zrácí i při překladu, když se holt rozhodli překládat i výrazy jako directory junction.
-
j (neregistrovaný)
V prekladu se nic neztraci, ta napoveda je jednoduse uplne spatne, protoze to tvrdi presne opacne.
Mas tam jednoznacne napsany, ze prvni parametr je cesta.
Kdyby se mi pak chtelo dohledavat, tak ti najdu samply vzorce do excelu, ktery ... nebudou fungovat. Protoze ti curaci nejen ze ty vzorce prekladaj, ale oni i menej jejich syntax, takze tam, kde v anglickym excelu davas rekneme carky, chce ceskej ... stredniky. Pripadne naopak.
Co hur, da se vpohode sestavit vzorec, kterej fungovat vlastne bude, jen bude delat uplne neco jinyho, nez bys cekal. Coz se opravdu paradne resi, kdyz mas 150 tabu vzajemne se odkazujicich.
At zije dokumentace M$.
-
Už jsem to psal mnohokrát, ale zřejmě je to potřeba zopakovat. Vzorce se v Excelu zadávají a zobrazují lokalizované, ale ukládají se vždy v angličtině. Pokud máte na sheetu nějakou chybějící funkci s cizojazyčným názvem, tak je to nejspíš makro, které má jen jedno jméno ve všech jazycích, a vy ho v souboru prostě nemáte.
Jinými slovy když si německý kolega vyrobí spreadsheet, napíše do něj vzorec SUMME(B5:C7) a soubor uloží, tak český kolega při otevření uvidí SUMA(B5:C7). V souboru bude zapsáno SUM(B5:C7).Pokud německý kolega založí makro KraftfahrzeugHaftpflichtversicherungPreis, tak ho český kolega uvidí pod stejným názvem.
Pokud německý kolega založí makro KraftfahrzeugHaftpflichtversicherungPreis a pošle českému kolegovi soubor bez toho makra, tam český kolega uvidí neznámou funkci KraftfahrzeugHaftpflichtversicherungPreis.
Už je to jasné?
-
Mám za to že v angličtině je ten help k mklink správně, takže jde o problém lokalizace.
Čeští uživatelé používají češtinu protože neumí anglicky. Pochopitelně jsou pak funkce lokalizované, protože uživatel nebude vědět co znamená AVERAGE, ale bude vědět co je PRŮMĚR. Čeština používá čárku jako desetinný oddělovač, takže se jako oddělovač seznamu používá středník. Ale jak jsem psal, tohle se týká zadávání a zobrazování vzorců v lokalizované verzi MS Office. Interně jsou vzorce v angličtině, a soubor se dá použít v libovolné verzi Excelu. Pokud jde o dokumentaci, tak český Excel z hlediska uživatele funguje s českými funkcemi podle české dokumentace, a španělský podle španělské dokumentace se španělskými funkcemi.
https://www.root.cz/zpravicky/reactos-uz-umi-tisknout-ale-jen-pres-paralelni-port/910464/ -
To je na jedné straně pravda. Na druhé straně se Windows rozvíjí, a zjevně je nad síly projektu ReactOS i jenom implementovat starou funkcionalitu, natož pobírat i tu novou. Pokud by zázrakem implementovali Win32 API řekněme na úrovni NT 4 nebo WinXP, tak by pořád zbývalo implementovat řekněme DirectX 10, 11 a 12, WinRT, WDDM-like 3D akcelerace a XAML atd. Navíc to není jen o kompatibilitě na úrovni API. Je potřeba také kvalitní správa paměti, threading, škálovatelnost, high resolution timery, podpora SMP a cc:NUMA, driverů včetně filter driverů atd. Dost pochybuji, že je takový projekt realistický.
-
ehmmm (neregistrovaný)
Muzu te ubezpecit, ze my, co mame pocitac na praci (nedelam grafiku), nic z toho, co jsi jmenoval (myslim DirectX az XAML), nepotrebujeme. Dale mi prosim vysvetli, jak ve Win funguji high resolution timery? Ja mel problem ve Win98 v uzivatelske aplikaci dostat se pod 50 ms, pry vlastnost systemu, pak uz jedine napsat si vlastni ovladac. A existuje ve WinXP citac milisekund od startu, ktery nepretece za 49 dni? Ono to asi nebude tolik slozite udelat to stejne blbe jako MS (diskuter javaman by rekl, ze to je prace pro lopaty), ja jim fandim.
A vubec, programoval jsi nekdy neco pro Windows nebo pro DOS? Myslim neco aspon trochu low-level, ne klikani v .Net?
-
Martin DrábStříbrný podporovatel
> high resolution timers
Ty by mohly být na vyšší úrovni známy jako Multimedia Timers
https://msdn.microsoft.com/en-us/library/dd743609(v=VS.85).aspxInterně to asi bude fungovat nějak takto:
http://mirrors.arcadecontrols.com/www.sysinternals.com/Information/HighResolutionTimers.html> Muzu te ubezpecit, ze my, co mame pocitac na praci
> (nedelam grafiku), nic z toho, co jsi jmenoval (myslim DirectX
> az XAML), nepotrebujeme- Pro nás, co se hrabou v kernelu, zase post-XP éra přináší věci, které jsme do té doby postrádali
- jednodušší filtrování/monitorování sítě (Windows Filtering Platform)
- konečně (téměř) dotažené možnosti kolem filtrování operací nad registrem,
- implementaci socketů pro kernel,
- zjednodušení power managementu,
- dokumentovanou možnost detekce vzniku/zániku procesů, která umožňuje více než monitorování,
- vylepšení Windows Driver Frameworků (ty asi ROS neimplementuje vůbec, na druhou stranu, jsou už open source).
Některé věci zní asi jako maličkosti, které ale velmi ulehčí život.
-
MS-BOSS (neregistrovaný)
Ono je to spíš tím, že ReactOS nedělá schopný tým. Když se kouknete, co dokázal KernelEx (dopředná kompatibilita pro Win98 až do Vist), je jasné, že napsat Windowsy znovu by šlo. Jenže problém je s kompatibilitou - schválně se koukněte do leaknutých zdrojáků Windows, kolik je tam ojebávek kvůli kokotsky napsanému softu. Druhá věc - k čemu to dělat, když jediný důvod, proč používat zrovna Windows, je používání closed-source programů.
-
Ma to zmysel.
ReactOS je v podstate projekt, ktory spaja mingw s wine a pridava vlastnu implementaciu kernelu na ktorej je WIN32 API schopne behu.
ReactOS zdiela s WINE implementaciu API a vzajomne si vymienaju patche, takze ak sa vdaka bugu v reactOS-e narazi na nejaky bug v implementacii Wine, ten je opraveny aj tu aj tam.
Zaroven je AFAIK ReactOS mozne kompilovat mingw, co stimuluje jeho udrzanie pri zivote, resp. rozvoj. Nad mingw, resp. cygwinom su zasa postavene dalsie uzitocne veci ako napriklad MXE, co je prostredie umoznujuce generovat WIN32/64 porty aplikacii bez nutnosti mat prostredie windowsu nainstalovane.
Problemom je, ze ak sa touto metodou portuje nieco, co samotnemu WINAPI slape na krk v zmysle vyuzivania na 100% dojde sa k tomu, ze niektore vlastnosti su vo wine implementovane inac ako na samotnom windowse, alebo ze do niektorych veci kecaju rozne anti-cokolvek blbiny.
-
mhi (neregistrovaný)
Pred rokem jsem cetl nejake diskuse o tom jestli by nebylo lepsi kdyby udelali nejaky merge s Wine ... skoncilo to u flamewar na nejakem foru (vsichni kecali ale nikdo nedelal).
No a potom nejaky chlapik za docela kratkou dobu narouboval jako pokus zdrojaky wine na nezbytne nutne zbytky ReactOSu :-), presto mu to odmitli...
IMHO je blbost se snazit delat dalsi implementaci Win32 API, kdyz je to cele jen o tom "udelat vsechno stejne jako MS" (do puntiku, tech specifickych postupu a vyjimek tam je hodne), daleko rozumnejsi by bylo pouzit uz to co je ve Wine a jen to poupravit aby to bylo blize NT-svetu. ReactOS nezvlada ani spravne vykreslovat okna, z videi je videt jaky maji evidentne chaos v tom jake zpravy oknum posilat...
-
nobody (neregistrovaný)
nevim co kde si cetl, ale autori ReactOS pisou jasne ze s vyvojarema Wine spolupracujou a sdileji co jde
https://www.reactos.org/wiki/WINE
https://cs.wikipedia.org/wiki/ReactOS#Podobn.C3.A9_projekty -
nobody (neregistrovaný)
tady jsou i nejake konkretnosti:
https://svn.reactos.org/svn/reactos/trunk/reactos/media/doc/README.WINE?view=markup -
Martin DrábStříbrný podporovatel
AFAIK je jejich cílem dosáhnout kompatibility s Windows Server 2003, tudíž zprávička je v tomto ohledu zavádějící (jedná se ale pořád o kernel založený na NT).
ČLÁNKY DO MAILU