Vlákno názorů k článku Staticky linkovaná distribuce Stali, kterou svět (zatím) neviděl od trdlo_makove - mohol by mi niekto prostým sposobom vysvetliť čo...

Ad knihovny... jsou zpětně kompatibilní ... Což není vždy jednoduché - souhlas, někdy to není jednoduché.

Ad nejlepší dokumentací je zdrojový kód - ano, to je omyl rozšířený v linuxové komunitě, obecněji nepochopení rozdílu mezi dokumentací (které je daná) a konkrétní implementací (která se může kdykoliv změnit, zvlášť v turbulentním světě Linuxu).

Problémy s různými verzemi knihoven jsou poměrně vzácné. Co bohužel naopak není vzácné je spoléhání autorů aplikací na nedokumentované vlastnosti knihoven, nebo obecněji systému.

Jo. Kdysi na škole jsem programoval něco do Widlí a týden utekl jak voda, když jsem se snažil dohledat, jak v dialogu pro výběr adresáře přednastavit svůj datový. Nakonec jsem rezignoval, furt to nějak haprovalo... Udělal jsem si dialog vlastní s použitím tree view a skenováním adresářů. Bylo to rychlejší.

Aha, takže za týden neumíte napsat ani použití standardního dialogu? Ale zato zvládnete naklikat vlastní dialog, za který vám uživatelé jistě poděkují?

V ranných devadesátých to skutečně mohlo být jednodušší. I po vydání MS Windows 95 bylo informací velmi málo. Microsoft zdarma neposkytoval informace žádné a i za peníze zpřístupňoval jen něco. V roce 1995 bylo naprosto běžné programovat Win32 podle informací pokoutně získaných na BBS a od lidí, kteří se pokoušeli o reverse engineering.

Dnes už se tomu ani nechce věřit, přístup MS se hodně změnil, dokumentaci doplnil a už se k ní dostanete i bez předplatného MSDN. To ale nic nezmění na historii, kdy MS používal mizerné specifikace k posílení své konkurenční výhody.

Jestli výběr defaultního adresáře pro file dialog je zrovna jedna z věcí, která byla v nějakém období nedokumentovanou funkcí, to netuším. Ale věřit by se tomu dalo.

V roce 1995 bylo naprosto běžné... V ČR samozřejmě ano, protože tam většina SW byla nelegální. Za komoušů se běžně psalo "na divoko" bez oficiální dokumentace (protože embargo), lidé na to byli zvyklí, a MSDN si asi nikdo kupovat nechtěl. V US bylo běžné si koupit MSDN, bylo to skoro zdarma. Plus samozřejmě existovala spousta literatury.

Bavíme se o vysoké škole v ČR. Předplatné MSDN bylo, stejně tak byl legální veškerý SW. Dokonce se psalo i na helpdesk a přednášející nám ty dopisy pro pobavení ukazoval. Obvykle to byla korespondence typu:

dotaz: Jak udělám A?
odpověď: Bohužel, A udělat nejde
dotaz: Ale MS Word A naprosto běžně dělá, takže jak?
odpověď: Váš dotaz byl přesměrován na helpdesk MS Office
odpověď od helpdesku MS Office: K provedení A se používá standardní funkcionalita OS
dotaz: Jaká funkcionalita OS se používá v MS Word k udělání A?
odpověď: Váš dotaz byl přesměrován na helpdesk MS Windows
odpověď od helpdesk MS Windows: Tato funkce není podporována a nedoporučuje se ji používat. Prosím používejte pouze dokumentované funkce
atd. atd.

Zkrátka MS Windows měly v API mraky funkcí, které ve svém SW běžně používali. Ale nikdo jiný se k jejich dokumentaci nedostal. Ovšem když jste informace někde podloudně zjistili, tak to fungovalo. A po pár letech se funkce i objevila v dokumentaci a to dokonce s informací, že je v tom API už dob MS Windows 3 apod. Historie stavu dokumentace se dá dohledat například i díky projektu WINE.

Ano, MS při vývoji SW napsal spoustu věcí, které byly určeny pro interní potřebu, a nebyly dokumentované. Nakonec to tak dělá každá firma. Některé z těch funkcí přetrvaly a byly zdokumentovány. Nicméně to asi není případ nastavení výchozího folderu v SHBrowseForFolder, protože to bylo popsané v MS KB, jak jsem psal zde:
http://www.root.cz/clanky/staticky-linkovana-distribuce-stali-kterou-svet-zatim-nevidel/nazory/490271/

Nekde na disku se mi povaluje softik, kterej obsahuje popis funkci DOSu. Tak 30% z nich je oznacenych jako "nezdokumentovana funkce" - samo vsechno velmi zajimava funcionalita. Ve widlich takovy veci byly v meritku daleko vetsim. A nedelal bych si iluze - jsou tam dodnes. Ostatne, ktere jina aplikace si pri instalaci prepisujou systemove knihovny? Krome tech od M$ zadne neznam.

Asi vám nedochází, že spousta funkcí systému je zcela záměrně nedokumentovaná. Když je nějaký interface zdokumentovaný, musíte ho podporovat v současné i dalších verzích systému, jinak rozbijete zpětnou kompatibilitu.

Chcete příklad, jak použití nedokumentovaných funkcí působí problémy?
- Home adresář uživatele NENÍ v C:\Windows\Pro­files\jméno, ani v C:\Documents and Settings\jméno. To umístění se mění podle verze Windows i lokalizace. Použijte environment variables, nebo API SHGetSpecialFol­derLocation.
- Desktop NENÍ v adresáři pod profilem uživatele v podadresáři Desktop, a Start Menu NENÍ v podadresáři Start Menu. Liší se to podle verze Windows a lokalizace. Použijte API SHGetSpecialFol­derLocation.
- Větev Shell Folders v Registry NEOBSAHUJE lokace shell folders. Tato větev Registry byla odstraněna z dokumentace před uvedením Windows 95, existuje jen pro kompatibilitu s aplikacemi psanými pro betu Win95, a plní se hodnotami jen za určitých okolností. Použijte env values nebo API SHGetSpecialFol­derLocation.
- Pořadí Window Messages je buď popsané v dokumentaci, nebo na něj nelze spoléhat. Pokud si ho vyzkoušíte a spoléháte na to, že bude vždy stejné, řítíte se do problému.
- Nedokumentované Window Messages nepoužívejte, a to se ze stejného důvodu - zítra tam nemusí být, nebo mohou mít úplně jiný význam.
- Pokud návratová hodnota Win32 funkce není ERROR_SUCCESS (tj. nula), volání selhalo. Pokud dokumentace netvrdí něco jiného, návratová hodnota pak nehraje roli, protože se liší podle verze Windows, driverů a kdo ví čeho ještě. Takže se z ní nesnažte vykoukat příčinu problému, a zavolejte API GetLastError(), které nám řekne více.
- Nekraďte resources (ikony, animace apod.) z knihoven shellu. Ty resources tam v příští verzi Windows nejspíš nebudou, případně budou mít jiný formát. A protože krádež resources provádějí jen prasata, asi neošetří ani situaci kdy tam daný resource není, a aplikace pak spadne. Ikony i animace jsou součástí SDK, takže je odtamtud zkopírujte do své aplikace.

Raymond Chen občas zveřejňuje nějaké perličky na blogu. Nabídněte si.
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2004/03/26/96777.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2004/10/26/247918.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/18/355177.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2010/03/11/9976571.aspx
http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.aspx
http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/03/26/96777.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/01/18/355177.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/09/01/459023.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/26/485133.aspx
http://msdn.technetweb3.orcsweb.com/oldnewthing/archive/2008/01/11/7065021.aspx
http://technet.microsoft.com/en-us/magazine/2006.11.windowsconfidential.aspx
http://www.microsoft.com/technet/technetmag/issues/2006/10/WindowsConfidential/

Nezdokumentovana funkce nema v systemu co delat!

System je od toho aby poskytoval API aplikacim, a ne od toho, aby byl jejich soucasti. Jenze to by dobytci v M$ muselli aspon tusit, jak se programuje. Pak se totiz neni co divit, ze se widle kazdou chvili slozej, a ze casem vyhnijou k nepouzitelnosti.

Předsně tak. Synonyma k "nezdokumentovaná" je "nepoužitelná", "zbytečná" a "netestovaná".

Pokud je něco v systému nedokumentovaný a jenom jako obezlička pro vývojáře aplikace, aby to výrobce systému mohl použít ve svých produktech, je to z principu blbě. Systém dělá tým A, aplikaci tým B, pak to v další aplikaci použije tým C.

A jak znám manažery:
A: "Tuhle funkci si vymyslel tým B, potřebujeme ušetřit čas, tak to nebudeme testovat. Je to jejich, tak ať si s tím dělají co chcou."
B: "Jsme ve skluzu. Ta funkce je sooučást systému, vyhoďte její testy a získáme tak pár hodin k dobru."
C: "Je to týmu A, tým B to používá normálně, takže je to otestovaný. Nebudeme ztrácet čas, vedení nás tlačí do release..."

Takže je v zájmu M$ samotnýho, aby veškerá funkcionalita systému byla dobře dokumentovaná, plně testovaná a stabilní. A co tohle nesplňuje, měli by fixnout nebo vyhodit.

Kdybyste vy věděl jak se programuje, tak byste věděl, že řada věcí je specifických pro konkrétní implementaci, a v příští verzi se mohou řešit jinak. Takové věci pak nejsou dokumentované.

Systém by naopak časem vyhnil k nepoužitelnosti, kdyby byly dokumentované věci typu intenríách datových struktur, pořadí položek v menu, konkrétní resources v knihovnách shellu apod., a aplikace takových věcech byly závislé.

Jeden příklad za všechny: FS poskytuje své funkce přes API. Interní struktury a funkce FS nejsou dokumentované, protože se mohou změnit. Když na ně budete spoléhat, dostanete se do problémů.

Preste takhle si to taky pamatuju. Kdyz jsem se pak potkal s nekym kdo pro MS pracoval, tak mi vysvetlil, ze dokumentaci prochazeli pravnici a ti rozhodli, ze jakykoliv kus kodu je intelektualni vlastnictvi MS a proto dokumentace nesmi obsahovat zadne fragmenty kodu.

Takze MS referencni prirucka obsahovala popis pro kazdou funkci, ale jak to dat dohromady, tak na to si musel prijit kazdy sam.

1. Byla to semesttrálka. Nešlo to nikam komerčně do světa, účel splnila a UI bylo co do použití stejný. Dovolilo to navíc přidat další ovládací prvky.
2. M$ "standardní dialog" chce jako referenci odkaz na instanci s popisem adresáře, ale nikde není popsáno, jak se k té instanci dostat - minimálně jsem to nikde nenašel.
3. Když standardní komponent systému pro práci s adresářem NEPODPORUJE zadání cesty v textové formě, je problém na straně dodavatele (= M$). Toto je fundanmentální požadavek, asi jako u tlačítka fakt, že na něj jde kliknout. A pokud to náhodou podporuje, tak to NENÍ NIKDE DOKUMENTOVÁNO.
4. S tímhle dialogem patrně nemám potíže jenom já.
a) Když se podíváte na celou řadu programů, tak se dialog pro výběr adresáře buďto nahrazuje standardním dialogem open/save. Proč asi?
b) Tento dialog se používá pro výběr adresáře, klasicky edit ss tlačítkem vedle. Ve většině programů skočí na "tento počítač" bez ohledu na to, co bylo vybráno. Proč asi?
c) Jaký je asi důvod, že tenhle dialog není třeba ve VCL apod.? Jeho nepoužitelnost?

1. Přidávat další prvky můžete samozřejmě i do standardního dialogu. SHBrowseForFolder má callback BFFCALLBACK, v něm dostanete handle na okno (HWND). Pak už si to okno můžete prakticky libovolně předělat. Obdobná technika používá i pro customizaci dalších dialogů, například když chcete preview u file dialogu.
2. Výběr adresáře v SHBrowseForFolder? To je přece dokumentované:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762598(v=vs.85).aspx
3. Specifies the path of a folder to select. The path can be specified as a string or a PIDL. Mimochodem příklad je i v MS KB.
http://support.microsoft.com/kb/179378
4.a Ti lidé na rozdíl od vás čtou dokumentaci: For Windows Vista or later, it is recommended that you use IFileDialog with the FOS_PICKFOLDERS option rather than the SHBrowseForFolder function. This uses the Open Files dialog in pick folders mode and is the preferred implementation.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762115(v=vs.85).aspx
4.b Nechápu. "Tento" je SHBrowseForFolder nebo IFileDialog?
4.c Máte na mysli nepoužitelnost VLC? Jo, to by mohl být důvod :). Jinak .NET má třídu FolderBrowser­Dialog.
http://msdn.microsoft.com/en-us/library/System.Windows.Forms.FolderBrowserDialog(v=vs.110).aspx

Ono jde take o to, ze v dobach Windows 9x nemel ani samotny MS dvakrat jasno v tom, jestli je vlastne SHBrowseForFolder (a obecne velka cast SHneco veci a zejmena window classy pouzivate explorerem) je vlastne verejne a dokumentovane API windows nebo spis interni funkce pro explorer. Cele je to jeste z praktickeho pohledu komplikovane tim, ze je to "Browse for folder" a ne "Browse for directory", protoze priznejme si to, vetsinu programu koncept windowsiho folderu fakticky nezajima (a to v te dobe platilo jeste vice).

Jo, to je možné, takových případů bylo víc. Z hlediska vývojáře je to jasné: pokud to není v dokumentaci, tak to nepoužívám.

Directory je kontejner na soubory na FS.
Folder je node v namespace shellu, zjednodušeně node stromu v Exploreru. Například Printers nebo (My) Computer nejsou directories, ale folders. Podobně ve Windows máme folders pro zařízení komunikující protokolem MTP, ZIP soubory, Recycle Bin apod. Folders jsou nadmnožinou directories. Folders - directories = virtual folders.
http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

On ve škole i v práci je jeden problém - málo kdy si člověk může vybírat techmologie. Tam, kde se teď cpe M$ s licencema pro studenty zadarmo, byl tehdy nasáčkovaný Inprise. Takže .NET byl mimo hru, ať je v něm co chce. V tu chvíli to nebylo relevantní.

A nejedná se o VLC (přehrávač), ale VCL (Visual Component Library) v Delphi nebo CPP Builderu. On totiž existuje i svět, kde se nepoužívá M$VS...

Dalí problém byl, že v té době jsme na vesnici neměli Internet a hledat to po chvílích ve školní knihovně s kvantovaným časem nebylo to pravý ořechový. Sedět pět hodin denně v internetové kavárně se studentským kapesným taky nebylo nejkvalitnější řešení, ono 40Kč/hod. když člověk nepracuje je docela poznat. Takže se člověk musel spolehnout na tištěnou dokumentaci (knížka o WinAPI), nějaký PDFka vypálený na CD a help k používanýmu prostředí. Tím to prakticky končilo. A na argument, že každá potíž se dá řešit - dá, ale je to o kompromisu. V rámci možností jsem vyzkoušel, co bylo dostupný offline a vyhodnotil, že náhrada dialogu bude efektivnější, než shánění další dokumentace.

U tučňáka by to bylo jednodušší, stačilo by projít zdrojáky a hned bych věděl, co tam nacpat. Nebo si t tam jednoduše dopsal...

VLC je samozřejmě překlep. Myslel jsem ten framework od Borlandu, který nikdo nepoužívá.

Pokud používáte Win32, potřebujete k tomu dokumentaci. Předpokládám, že MSDN byste na škole našel, stejně jako nějakou kvalitní knížku.

U tučňáka byste mohl předvést hned dvě špatnosti:
1. Koukat do zdrojáku místo do dokumentace. Cokoliv není popsané v dokumentaci, je pouze implementační detail, a může se v příští verzi jakkoliv změnit.
2. Zasahovat do zdrojáků mimo vaši aplikaci. Asi by vám ani ve škole neprošlo změnit zdroják common controls a vytvořit v programu závislost na té změně jen proto, abyste mohl otevřít brouzdání folderu nad určitým adresářem. Když v Oraclím PL/SQL nebude nějaká funkce, také se ji nedopíšete do zdrojáku. A nedopíšete si ji tam ani v PostgreSQL, přestože máte zdrojáky. Kdybyste to udělal, musel byste tu změnu otestovat, zdokumentovat, a trvale ji udržovat a retestovat s každou novou verzí (zahrnutí do upstreamu vám totiž nikdo negarantuje).
Takže máte svým způsobem štěstí, že jste se ve škole (minimálně v této věci) nenaučil prasárny, protože jste tam neměl Tuxe.

1. Jak jsem psal - používat pouze co je dokumentované. Pokud dokumentace vůbec není, tak použít jinou platformu.
2. Pokud je to hackování založené na koukání do zdrojáku, je to problém, stejně jako v prvním případě.

používat jenom co je zdokumentované nejde. Protože pak polovičku věcí musí člověk udělat sám - to stojí další prachy a čas při uvedení na trh. Málo kdo si může dovolit ten luxus, aby znovu vyvíjel to, co už v systému je.

Jediným důvodem tajení dokumentace není zpětná kompatibilita, ale fakt, že M$ tak má ohromnou konkurenční výhodu, když polovička jeho sofru už je v systému, ale jejich konkurence se k tomu nedostane. Anebo s k tomu dostane až ve chvíli, kdy je aplikace se stejnou funkcionalitou na trhu od M$ nebo mají vlastní řešení.

Z konkrétního případů jste zatím ukázal jen nastavení výchozího adresáře v dialogu výběru adresáře, což je věc, která ve skutečnosti zjevně byla popsaná. Takže zatím nic moc argumenty.

Ultimate trolling level: Argumentovat sucasnou dokumentaciou na kritiku nedostatkov dokumentacie niekolko rokov dozadu.

Tady vidím v MS KB příklad ve francouzštině s roku 1996. Anglická verze má dnes jiné číslo KB, a není tam vidět původní datum, nicméně bude zjevně starší než ta francouzská.
http://support.microsoft.com/kb/466839/fr

Těžko mi pak někdo může tvrdit, že tohle nebylo dokumentované. Bylo to v MS KB, bylo to v hlavičkových souborech (jinak by ten příklad nekompiloval), a nejspíš to bylo i v MSDN (tam nemám link, MSDN je aktualizovaná průběžně - možná bych někde vyhrabal CD).

jiste, nejlepsi dokumentace je ta od M$ ... podle ktere nefunguje temer nic. A zdrojaky jaksi nejsou ....

Velmi dobre si pamatuju, jak sem se znamym stravil nekolik dnu (a noci) nad rozchozovanim bootu widli po siti - presne dle dokumentace ... az sme (v te dobe jeste inet nebyl defakto dostupny) metodou pokus omyl dosli ke spravne konfiguraci - uplne jine, nez v te oficielni dokumentaci od M$.

Dtto dokumentace vsemozny "neznamych" chyb. Ta je primo uzasna ... pokud teda widle uz omylem neco zalogujou, a neslozej se bez rozlouceni.