Názory k článku Staticky linkovaná distribuce Stali, kterou svět (zatím) neviděl
-
Zajímalo by mne, jak dlouho by takovému bazmeku trvalo pustit ls.
A vůbec, jak může suckless projekt linkovat do něčeho tak hnusného, jako je ELF, plný relokačních tabulek, relokovatelného kódu a talších zbytečností. Vždyť ELF je obezličkou z dob, kdy adresní prostor měl jen 2GB, a musely se tam vejít všechny knihovny. Knihovny!
Stali žádné knihovny nemá, tak proč neoprášit aout?
A vůbec! K čemu relokace? Proč neukládat rovnou binární obrazy paměti? Někdo by měl konečně zpropagovat XIP nad mmap().
Když tak nad tím přemýšlím, k čemu je vlastně remapování adres virtuální paměti? Každá binárka by mohla být zkompilovaná od určité adresy. A procesory by mohly být jednodušší.
-
stalin (neregistrovaný)
podle me jsou stali, suckless jen polovicaty radikalismus a pokrok v mezich zakona.
kdyby ti frajeri meli koule tak by hned sli do plan9.
ten ma totiz minimalismus v sobe od zacatku, vsecko fs, zadne sockety, miliony radku kodu v kernelu.
takze radsi meli dopsat soft pro plan9 a neohybat linux. -
Petr M (neregistrovaný)
Ok, takže slinkujeme všechno staticky. Spustím si text editor, natáhne se staticky slinkovaný kolos třeba 2MB velký (jenom kvůli omu, že do něho někdo staticky zalinkoval binárky na vykreslení memo boxu, aby si je nemusel zbytečně dynamicky linkovat z OS). Vedle spustím web browser, otevřu na stránce formulář a ejhle - stejný editační pole, ale staticky zalinkovaný do web browseru, požere dalšího 0,5MB RAM. Místo toho, aby jeho "chování" bylo popsáno na jednom místě a různý programy tu samou binárku pustily na svoje data...
Statickým linkováním programy porostou ještě víc, protože každý program bude mít v sobě napevno kopii toho samýho, co ostatní programy.
-
"Statickým linkováním programy porostou ještě víc, protože každý program bude mít v sobě napevno kopii toho samýho, co ostatní programy."
To je pravda pouze za podmínky, kdy programy budou skutečně využívat stejné části kódu. Potom ale nastává otázka, zda by se ty programy neměly rozdělit a z té společné části kódu udělat samostatný program.
Pokud by tahle granularita byla dostatečná, potom by žádný sdílený kód nebyl.
-
Palo (neregistrovaný)
Tak toto je pekna blbost, co ti hovoria kniznice? To akoze vznikne nejaky standardizovany interface medzi dvomi programami ci stdin <-> stdout?
A co potom to staticke linkovanie riesi. Ako vyriesim problem ze dva rozne programy potrebuju dve rozne verzie programu. To uz mozu rovno zostat dynamicke kniznice, nie? -
"To akoze vznikne nejaky standardizovany interface medzi dvomi programami ci stdin <-> stdout?"
To už dávno existuje. V praxi máme také ls | grep. Toto je místo, kde se aktuálně ona granularita zastavila, taky nemáme jeden program, který umí totéž co ls | grep, máme tyto dva. Dále, například grep úplně zbytečně umí pracovat se soubory. To se také dá řešit jinými existujícími programy. Tato funkcionalita by se dala z grepu odstranit (a tím i závilosti na jedné z mnoha knihoven. Takových tam bude.).
-
Petr M (neregistrovaný)
Jenomže potom jsou jenom tři možnosti.
1) Jeden program proběhne a předá data dalšímu. Potom jeden musí skončit a předat komplet data dalšímu. To znamená uložit data na pomalý disk, skončit, uvolnit resourcy, načíst druhý program (pomalý disk), alokovat prostředky, načíst data (pomalý disk),... a uživatel je akorát tak nas..., že kompl nic nedělá a jenom hrabe po disku.
2) Program vytvoří další proces a bude komunikovat prostřednictvím named pipe. Jenomže ten proces pojede ve vlastním kontextu a musí být reentrantní, takže od systému potřebuje přepínání kontextu, musí se synchronizovat vlákna,... a výkon aplikace jde do kytek.
3) Sdílený kód se natáhne přímo do paměti hlavního procesu, takže není potřeba synchronizovat vlákna víc aplikací, přepínat kontext, furt hrkat po disku,... Prostě se předá modulu ukazatel na data a instrukce, co s nima dělat a všechno proběhne často přímo ve volajícím vlákně bez další režie. Jediná obrovská nevýhoda je, že tomu někdo dal smrdutý název "dynamický linkování", takže je to v praxi nepoužitelný... -
1 a 2 jsou v podstate stejne. Porad se predavaji data pres nejakou formou souboru/streamu a chytry OS to udela tak, ze to zustane v pameti.
Jinak takovy pristup ma i nekolik vyhod - automaticka sprava pameti (GC), automaticke paralelni zpracovani, lazy eval...
Dovedu si predstavit, ze nejake jednoduche streamove zpracovani dat nebude pomalejsi nez monolytickym programem. -
"Dovedu si predstavit, ze nejake jednoduche streamove zpracovani dat nebude pomalejsi nez monolytickym programem."
To si nemusíte představovat. Jinak to má i další výhodu. Zatímco udělat víceprocesový program není až tak úplně jednoduché, tak pomocí pipe tohle máte zadarmo. Každý jednotlivý program může zůstat jednoduše singlethread, přičemž po spojení pipou tyhle programy poběží všechny současně (tak jak budou přicházet data).
-
lojza (neregistrovaný)
Precte si neco o Erlangu, pokud jste to jeste nevidel. Tam se vasim myslenkam podobne postupy jiz nejakou dobu aplikuji. Akorat misto operacniho systemu maji svuj virtual machine co bezi nad prakticky libovolnym operacnim systememe.
Kod se zde vykonava v procesech (ve smyslu Erlangu) jejichz beh je rizen shedulerem co bezi nad kazdym procesorovym jadrem co to najde (jako vlakno procesu ve smyslu operacniho systemu).
Sdilena pamet neexistuje (zdroj tezko nalezitelnych chyb a problemu). Procesy komunikuji zpravami (soucast jazyka a prislusneho VM, nikoliv nejaka nadstavba).
Vytvorit proces ve smyslu Erlangu je lacine a vyplati se to delat pro kazdou konkurenci akrivitu co se vyskytne (i kdyz transakce co ji to obsluhuje trva par milisekund).
Pripadna komunikace s vnejskem se da udelat necim cemu se tam rika Port (pusti se binarka a komunikuje se s ni pres STDIN/STDOUT jistym binarnim protokolem).
Ma to hodne zajimavych vlastnosti (napr. reload kodu aplikace za behu bez nutnosti restaru a prislusne ztraty dat u rozpracovanych transakci) a nejedna se jen o nejaky experiment, ale v praxi vyuzivany a overeny nastroj.
Nevyhodou je ponekud jiny pristup k programovani za ktery dostatete zajimavy vykon a pomerne kratke zdrojovky k programum (zajimava efektivita vysledneho dila ale i programatora). Nevyhodou je zmineny jiny pristup, ktery se musite naucit (tak mesic). Pro lepsi seznameni doporucji pouzit nejakou knizku, nejen uvodni tutorialy. A pozorne delat RTFM, snadno se da dulezity detail prehelednout :-)
-
Palo (neregistrovaný)
> jednoduche streamove zpracovani dat nebude pomalejsi
ALE BUDE, obzvlast N krat opakovane s malym mnozstvom dat. Priklad nasobenie matic ktore sa pouziva pri vykreslovani objektov. To si mam ako skompilovat program co bude nejako 'jednoducho' parsovat matice z input streamu a potom celu scenu co idem vykreslit budem prehanat bod po bode cez externy programcek. BLBOST AKO TRAKY. -
Obávám se, že například balit a komprimovat data určitě nezvládnete naprogramovat rychleji, než já napíšu tar | gzip. Dále tohle má neomezenou volnost, pokud budu chtít ty data opravdu důkladně šifrovat, tak tar | gzip | rot13 (:-D). Výsledný program sice jistě budete schopen naprogramovat také, ale mnohem obtížněji budete řešit věci jako multithreading apod.
-
Samozřejmně ;-)
Jinak v praxi se všechny 3 přístupy používají. Na bod 1 se často používají tmpfs (nebo prostře jakýkoliv fs v ram), a do stávající fs se dávají heuristiky na detekci takovýchto dočasných souborů.
Dvojka se používá úplně běžně na proudová data. Asi každý zná tar | gzip, dá se použít i ten nc na uložení na jiný stroj.
Trojka se používá, samozřejmně přehození jednoho pointeru je nejrychlejší způsob "předání" dat.
Každopádně, myšlenky Sali, Suckless nejsou úplně špatné (nesmí se brát dogmaticky a do extrému) v době, kdy dneska kdejaký programátor ke svému programu přibalí i celý framework, přičemž kdyby se zamyslel, tak by to šlo udělat mnohem úsporněji.
-
Jasne. No ty pipy jsou dost nesikovne kdyz chcete znat vysledek toho procesu (hodi se pro streamy). Takhle skoncite s tim, ze z kazde funkce udelate program a pak uz to muzete skladat v nejakym shellu protoze to bude tak jak tak silene pomaly. Tim dostanete dokonaly unix. Tak z tech programu udelate servisy a tim dostanete neco jako hurd. A pak si reknete, ze to je porad dost pomaly, tak to zacnete linkovat. A tim jsme na zas na zacatku, vse uz tu bylo...
-
Petr M (neregistrovaný)
Rozhraní se samozřejmě může měnit jenom rozšířením a kvůli backward kompatibilitě to bude udržovat i obsolete funkce. Takže to bude bobtnat o funkcionalitu, kterou už používá třeba jenom 1% klientů jak u widlí. Jak znám suckless, tak i ten unit test jsou řádky navíc a nevešli by se do limitu. Takže obsolete funkcionalitu nebude nikdo testovat, protože "je to tam už roky a nikdo do toho přece nesahal". Když se najde potenciálně nebezpečná funkce, nedá se jednoduše vyhodit a v systému budou zadní vrátka pro hackery...
Jedinou "výhodu" vidím v tom, že black hat si u multiaplikačního řešení může tu obsolete nebezpečnou funkci komfortně zavolat z CLI a nemusí se snížit na binární úroveň.
-
deda.jabko (neregistrovaný)
> To uz bylo vynalezeno, rika se tomu knihovny.
Myslim, ze tobe i Tomáši Crhonkovi uniká jedna hezka a podstatna vlastnost statickeho linkovani.
Tim, ze bude program staticky slinkovany, nehrozi jeho rozbiti, pokud nekdo zmeni nekterou cast systemu, at uz je to knihovna nebo program komunikujici pres rouru. Modularita systemu je pak zajistena na urovni zdrojovych kodu stejne, jak je tomu treba v jadre. Dokazu si predstavit pouziti takoveho reseni u systemu, ktere potrebuji mit zajistenou opravdu vysokou miru stability kvuli nakladnemu testovani, certifikacim, atd. napr. v prumyslu, letectvi/kosmonautice, medicine, ...
On to zase neni tak uplne neproveditelny napad. Windows de facto tak dnes funguji. Ty sice pouzivaji ve velkem DLL, ale temer kazda aplikace si taha svoje verze a kopie knihoven, ktere zabiraji misto v pameti tak jako tak, takze je to pomalu jak staticke linkovani.
-
... (neregistrovaný)
ano rika se tomu winsxs a je to neco jako mapovaci tabulka (adresarova stromova struktura instalovanych aplikaci s hardlinkovanymi soubory konkretnich verzi knihoven)
a treba se k tomu casem nekdo dobere... dependency hell uz se resi treba tady: http://developerconference2014.sched.org/event/bdfb5804fb8e00691ec45f817d9102ce?iframe=no&w=100&sidebar=yes&bg=dark
-
„Statickým linkováním programy porostou ještě víc, protože každý program bude mít v sobě napevno kopii toho samýho, co ostatní programy.“
Pokud linkujete staticky, ve výsledné binárce zůstane (obvykle) jenom malá část kódu jinak běžně dynamické knihovny. Není žádný důvod, proč by kompilátor měl v binárce nechávat podprogramy, které nikdy aplikace nepoužije. Tedy statické linkování zalinkuje jen použitou podmnožinu knihovny.
Kromě toho statické linkování je efektivnější, protože je možné efektivnější volání, a také odpadají režie toho, že je to samostatná knihovna (např. nutnost vyřešit alokaci paměti zvlášť pro knihovnu a zvlášť pro hlavní program). A řada dalších věcí, optimalizace kompilátoru bude optimalizovat binárku jako celek, což bude efektivnější, než program a knihovna zvlášť.
Klidně se může stát, že když z jedné knihovny, která v dynamické podobě má 100 MB použije program pouze jednu malou funkci, že při statickém linkování se binárka zvětší o několik kilobajtů, protože není třeba linkovat to, co se nepoužívá.
Osobně si myslím, že glorifikace dynamických knihoven se přehání. Ušetření paměti není nic moc. Data v knihovnách stejně víceméně musí každý program duplikovat znovu a znovu. Sdílení kódu je možné jen za předpokladu stejném bázové adresy, na kterou je knihovna natáhnuta, což je zase silně proti bezpečnosti.
Ostatně už jenom to, že program linkuje dynamickou knihovnu přes nějaké API, je bezpečnostní díra jako hrom. Velké možnosti cracknout daný program.
Dynamická knihovna byla odjakživa především možnost prodávat kód třetích stran bez zdrojáků. A možnost vyvinout několika týmy samostatné knihovny, aniž by bylo nutné sdílet kódy. To byl účel dynamických knihoven především.
Sdílení dynamických knihoven různými aplikacemi je problematické, pokud se nejedná o čisté C. Obvykle u vyšších jazyků musí být program i knihovny zkompilovány stejnou verzí kompilátoru se stejnými optiony, jinak nastávají problémy.
Nehledě na to, že dynamické knihovny toho moc neumí, v podstatě jen sdílet tabulky skoků. Jakmile chcete mít v knihovně třídy, objekty, a další, pak musíte něco nadstavovat, což znamená další režii oproti statickému linkování a nebo minimáůně požadavek stejné verze kompilátoru, stejných optionů a dalšího. Není proto divu, že některé jazyky si raději vytvořily vlastní formát knihoven.
Já bych dynamické linkování neglorifikoval. Kdybych tvořil vlastní systém, určitě by statické linkování bylo přednostní a dynamické linkování by – pokud vůbec – bylo někde daleko vzadu. Chápu, že dogmata bez rozumného zdůvodnění, jako třeba dogma „dynamické knihovny = pouze velké dobro a mír po celém světě“ jsou hodně rozšířené, ale myslím si, že v reále je tomu skoro naopak.
Miloslav Ponkrác
-
deda.jabko (neregistrovaný)
> např. nutnost vyřešit alokaci paměti zvlášť pro knihovnu a zvlášť pro hlavní program
Proc? Knihovna i program prece mohou pouzivat volani stejne knihovny (libc) ...
> Sdílení kódu je možné jen za předpokladu stejném bázové adresy, na kterou je knihovna natáhnuta, což je zase silně proti bezpečnosti.
To je problem hlavne Windows. V Linuxu se knihovny natahuji na ruzne adresy, ale vzdy jsou data ulozena ve stejnem ramci, ale mapovavana na ruzne stranky, takze rezie 0.
> Ostatně už jenom to, že program linkuje dynamickou knihovnu přes nějaké API, je bezpečnostní díra jako hrom. Velké možnosti cracknout daný program.
Tenhle argument je zhruba tak validni jako: ,,Uz jenom to, ze program je nahrany v pameti je bezpocnostni dira jako hrom.''
-
„Proc? Knihovna i program prece mohou pouzivat volani stejne knihovny (libc) ...“
V tom případě ale knihovna nezávisí jen na API, ale také na dalších předpokladech.
Jako programátor používající knihovnu nemůžete předpokládat, že libvolný zdroj vzniklý v knihovně (alokovaná paměť, otevřený soubor, thread, síťové spojení, …) vznikla jakoukoli cestou, a jediné čisté řešení je nechat tento zdroj ukončit knihovnou.
Nehledě na tom, že alokace paměti je velmi drahá operace a funkce malloc není nejlevnější, a ani se nejlépe nechová vůči multithreadovým programům, atd. Mnohokrát je lépe si alokaci řídit sám.
„To je problem hlavne Windows. V Linuxu se knihovny natahuji na ruzne adresy, ale vzdy jsou data ulozena ve stejnem ramci, ale mapovavana na ruzne stranky, takze rezie 0.“
Řekněte prosím, že si děláte legraci. V opačném případě bychom museli přijmout teorii, že tomu vůbec nerozumíte.
-
„Nezní to moc jako legrace. Spíš to zní jako docela dobrý popis Position-Independent-Code. Uchází mi něco?“
Ano.
1) Position-independent-code má určitá omezení, tedy je méně efektivní, než normální kód, protože určité optimalizace nejsou možné.
2) Veškeré position-independent-code jde do háje, jakmile se vám v kódu či datech objeví jeden jediný pointer na libovolnou globální či statikcou funkci či data.. A to zejména v těch datech, o kterých v té legraci mluví.
A přiznejme si a neljme si čistého vína, ony se ty pointery v C i jinde docela používají.
Házení termínama typu „position-independent-code“ a dalšími abrakadabra slovy nevyřešíte nic, jen zmírňujete některé palčivé problémy používání dynamických knihovny, abyste za ně získal jiné problémy.
-
deda.jabko (neregistrovaný)
Toto uz je fakt moc.
(1) Efektivita PIC na AMD64 se diky relativnimu adresovani blizi nePIC kodu. Jediny problem je dvojita dereference u globalnich dat. To se da ozelet, vetsinou to nejde ani poznat.
(2) Sdilene knihovny jsou mapovany s MAP_PRIVATE... z cehoz plyne: (a) kod (i data) se sdili mezi jednotlivymi procesy, (b) pokud nekdo neco zmeni, je to osetreno pres copy-on-write
(3) Pouzivat v knihovne globalni (mutovatelne) hodnoty, stavy, atd. je prasarna.
(4) Vase argumentace je vylozene detinska. Ve vasem prispevku jste psal: "Sdílení kódu je možné jen za předpokladu stejném bázové adresy", kdyz jste byl upozornen na to, ze se veci maji jinak, jedine, co jste zvadl byly urazky...
-
Biktop (neregistrovaný)
ad 1) Obecně máte pravdu, prakticky to bývá dost marginální.
ad 2) Hm, mohl byste to nějak rozvést? K těmto účelům snad slouží Global Offset Table, ne?Samozřejmě, že dynamické knihovny s sebou nesou různé kličky a nešikovnosti, ale otázka je, zda převažují výhody či nevýhody. A já bych se klonil spíše k té první variantě. Nakonec - autor se v naprosté většině případů může sám rozhodnout, jakým způsobem svůj výtvor sestaví.
-
JSH (neregistrovaný)
"Házení termínama typu „position-independent-code“ a dalšími abrakadabra slovy nevyřešíte nic, jen zmírňujete některé palčivé problémy používání dynamických knihovny, abyste za ně získal jiné problémy."
Budete se divit, ale vyřešil jsem. Jedním anglickým termínem jsem z vás vyrazil argumety, o kterých se dá bavit, místo házení žvástů typu "vůbec tomu nerozumíte".
Mimochodem "zmírňování palčivých problémů výměnou za jiné problémy" je dobrý popis veškerého výzkumu a vývoje.
-
deda.jabko (neregistrovaný)
> V tom případě ale knihovna nezávisí jen na API, ale také na dalších předpokladech.
A je na tom neco divneho? Je normalni, ze knihovny zavisi na dalsich knihovnach, atd. Rika se tomu abstrakce.
> Mnohokrát je lépe si alokaci řídit sám.
A mnohokrat ne. Ale to neznamena, ze kazda knihovna si nutne musi delat vlastni spravu pameti, jak jste tvrdil.
> V opačném případě bychom museli přijmout teorii, že tomu vůbec nerozumíte.
A nejaky argument by se nenasel?
-
Efektivni volani muzete mit i u dynamickeho, jen to vyzaduje stejnou base nebo prijdete o sdileni kodu mezi programy.
Myslim ze dynamicke linkovani nezavadi nejakou dalsi bezpecnostni diru ktera by bez toho neexistovala.
Dalsi vyhoda dyn knihoven je pri vyvoji - nemusim po kazde zmene sestavovat cely program.
-
„Efektivni volani muzete mit i u dynamickeho, jen to vyzaduje stejnou base nebo prijdete o sdileni kodu mezi programy.“
A právě ta vedlejší věta začínající u Vás „jen“ není velmi často splněna.
Kromě toho volání je u dynamické knihovny vždy horší, než u statické. Obvykle se volání dynamické knihovny překládá přes mezivrstvu zvanou tabulka skoků.
Nicméně jakékoli přizpůsobení externímu API, v tomto případě dynamické knihovně, snižuje efektivitu. To je cena za abstrakci. V tuto chvíli navíc kompilátor nemůže příliš optimalizovat, jako to dělá u statického volání.
Nemluvě o tom, že se skáče do jiných stránek paměti, jak v kódu, tak v datech, což snižuje účinnost procesorové keše, atd.
Osobně vůbec nechápu obhajování dynamických knihoven jako super cesty. Mám pocit, že v linuxové komunitě je spíše soupis „věcí k věření“, které jsou „pravda“, bez ohledu na realitu. Vůbec mi to připomíná náboženství více, než selský rozum. Dynamické knihovny mají spousty ale a spousty problémů, a samozřejmě jsou případy, kdy jsou výhodné, a kdy je to cesta do pekel. Ale kněží a biskupové linuxu nepsali, že dynamické knihovny jsou jedině dobré, a tak to lidé bez hlubších znalostí papouškují jako fakt. A snaží se to prosadit stylem „100 × opakovaná lež se stává pravdou“.
-
Já jsem záměrně vytvořil protiváhu k názoru, že jedině dynamické knihovny a nic jiného.
Většina lidí neví, proč dělá co dělá. Většina lidí se to bezhlavě od někoho naučila, aniž ví o tom něco více.
Stačí si projít tuto diskusi a zjistíte, že lidí, kteří by o dynamických knihovnách versus statickém linkování věděli něco více, je minimum. Většina z nich tu jenom papouškuje to, že jejich víra (nepodložená jakýmikoli znalostmi) je udivuje, že by snad nebyly dynamické knihovny jen dobré a pouze dobré.
Netvrdím, že dynamické knihovny jsou pouze špatné. Ale jejich používání má mnoho problémů. Pro některá nasazení je to ok, pro jiná je lepší staticky linkovat.
Schválně si tu spočítejte příspěvky těch, kteří o tomto problému napíší něco hlubšího. Odečtěte „názor“ bez zdůvodnění a házení prázdnými termíny. A pochopíte, jak „vědomě“ a „podloženě“ je ten názor utvořen.
Pravda se nedá odhlasovat. Když seženete milión lidí, co budou tvrdit, že voda díky gravitaci teče vždy do kopce – budete mít jen milión lidí s mylným názorem, nic víc.
-
Ales Hakl (neregistrovaný)
Vzhledem k tomu, ze na vetsine platforem, kde ma o nejakem Unixu smysl se bavit (vyznamna vyjimka je i386 pred amd64) je mozne adresovat jak data tak kod oproti PC/RIP, tak pro volani a pristup k datum uvnitr stejneho sdileneho objektu neni pouzivat mechanizmy jako GOT a PLT. Volani pres hranici sdileneho objektu nebyva az zas tak kriticke (navic ten skok pres PLT trampolinu je na dnesnich CPU daleko efektivnejsi nez to na prvni pohled vypada, prakticky vzdy to ma mensi overhead nez volani C++ virtualni metody), pristup k datum pres hranice sdilenych objektu vede na GOT ci spise obecne na problemy (rozumne vyuziti je inicializace neceho v .data na pointer do jine knihovny, coz ma vtipnou vlastnost, ze neni zrovna dvakrat portabilni, protoze nektere formaty sdilenych objektu maji dost omezene schopnosti vyjadrovani relokaci).
Jinak staticka bazova adresa (+ pripadna privatni relokace, v zavorce proto, ze opravdu existuji pouzivane OS, ktere pri kolizi reknou "smula, nejde to") a PIC nejsou jedine dve mozna reseni. Treba Windows 9x umi sdilet mezi procesy i ty relokovane stranky, princip je ten, ze dynamicky linker je v kernelu a umi relokaci v pripade potreby provest pri obsluze vypadku stranky (nechci rict, ze je to nejak "dobre" reseni, ale je to take mozne reseni).
Jeden z problemu je ze cely ten mechanizmus sdilenych objektu/dynamickych knihoven je omezen tim, ze minimalni granularita mapovani je stranka a tudiz aby se to vyplatilo musi byt ten sdileny objekt vetsi nez alespon tolik stranek kolik ma segmentu, coz muze byt pro opravdu jemne modularni veci malo (hezky priklad veci co v systemu normalne je jsou vselijake moduly do jazyku typu python/perl/ruby ktere jsou jenom tenky wrapper kolem C knihovny a maji jednotky az desitky kB, takovy hypoteticky priklad by bylo treba rozsekat glib nebo Qt po tridach do samostatnych knihoven).
-
klokan (neregistrovaný)
Modulární i statický kernel mají identická vnitřní i userland rozhraní, takže to nehraje roli. Vámi popisovaný efekt je známý a vysvětluje se tím, že modulární ovladač (ve vašem případě zvuku) leží v paměti "daleko" od zbytku kernelu a na takovém 486 se holt s oním zbytkem pere o cache.
-
Ivan (neregistrovaný)
Jeste dodam, dalsi. Spousta lidi si mysli, ze dynamicke = .so (staticke = .a) jako Linuxu - tak jak to podoporuje format .ELF. Pokud ovsem pisete multiplatformni aplikaci tak zjistite, ze:
- Windows maji format COFF a moznosti .DLL knihoven jsou dost omezene. (Na druhou stranu zase resi nektere veci jinak)
- Mac OSX rozlisuje mezi dynimickou knihovnou a pluginem. Kod pro statickou inicializaci knihovny je potreba explicitne "oznacit"
- Na Solarisu neni mozne vytvorit statickou binarku, nektere knihovny se linkuji POUZE dynamicky
- AIX pouziva format XCOFF, veskery kod je PIC. Rozdily mezi statickou a dynamickou knihovnou jsou tu taky, funguje to jinak nez na .ELF Unixech.
-
Martin Kopta (neregistrovaný)
U těch staticky linkovaných distribucí jsem zapoměl zmínit ještě Alpine - http://alpinelinux.org/. Moc zajímavý projekt. A taky jsem chtěl zmínit jazyk Go, ve kterém se kompiluje staticky.
-
noname (neregistrovaný)
Nejlépe asi Google. Co jsem si na něm dnes našel, tak statické linkování znamená, zahrnutí veškerých knihoven do jednoho programu, kdežto dynamické umožňuje volat již zkompilované knihovny, které jsou součástí operačního systému, díky čemuž se nenačítají pro každý program zvlášť. Toto jsem objevil na Google dnes ráno, pokud jsem to správně pochopil.
Teď se tak dívám na Wikipedii a vidím článek, který je ještě lepší než informace z Google, takže...
http://cs.wikipedia.org/wiki/Knihovna_%28programov%C3%A1n%C3%AD%29 -
j (neregistrovaný)
= vemes vse co SW potrebuje aby bezel, a integrujes to do nej.
dynamicky = sw se podiva po systemu, a pouzije jeho knihovny, ktere ovsem mohou byt v ruznych verzich, a SW to nejak musi resit. Navic ty knihovny velmi casto umi hromady veci, ktere nanic onen sw nepotrebuje, ale do pameti se to nacte cely.
-
Karel (neregistrovaný)
Pokud vytváříte program, který nevyužívá žádné knihovny, tak vám vznikne spustitelný soubor a je hotovo. Jenže takových programů je minimum, pro cokoliv většího je běžné, že chcete využít nějaké knihovny funkcí. Kupříklad pro vstup z konzole, výstup na obrazovku, pro přístup k síti atd.
Knihovny použijete tak, že do svého programu vložíte definici rozhraní té knihovny. Typicky použijete její .h. Když program přeložíte, budou v něm volání té knihovny vložena jako link - tedy nebude tam vlastní kód té knihovny, jen odkaz na nějakou její funkci.
Posledním krokem je pak slinkování vašeho programu s knihovnou. Statické linkování spočívá v tom, že se soubor s knihovnou vezme a do vašeho programu se přibalí. Vznikne tak větší soubor, ale knihovnu máte přibalenou a nejste tak odkázán na to, co má uživatel nainstalováno.
Dynamické linkování pak spočívá v tom, že se do vašeho programu nepřibalí knihovna jako taková, ale jen instrukce pro operační systém, že ji chcete linkovat. V souboru pak tato knihovna není. Program spoléhá na to, že po jeho spuštění si řekne operačnímu systému, že potřebuje danou knihovnu v dané verzi, a že operační systém ji někde najde a programu zpřístupní.
-
trdlo_makove (neregistrovaný)
dakujem za vysvetlenie (samozrejme aj predoslym ludom)..
mam dalsie otazky:
- ako sa potom riesi ked chcem pouzit s mojim programom presnu verziu knihovny (v systeme je novsia alebo starsia)
- ako sa riesi ak 2 programy naraz vyzaduju 2 rozne verzie tej istej knihovny... -
Lael Ophir (neregistrovaný)
Na prvním místě se knihovny píšou tak, že jsou zpětně kompatibilní. Pokud zavádíte novou funkcionalitu, tak ji prostě přidáte k té stávající. Tím je zajištěno, že vaše aplikace poběží i s každou novější verzí dané knihovny. Minimální verzi pak můžete ověřit při instalaci.
Na druhém místě se pak knihovny verzují. Aplikace může v manifestu uvést, kterou verzi knihovny akceptuje. Typicky to bývá cokoliv novějšího než pro co byla napsaná, ale může také vyžadovat specifickou verzi.
-
„Na prvním místě se knihovny píšou tak, že jsou zpětně kompatibilní.“
Což není vždy jednoduché.
Je poměrně snadné zařídit, aby se API chovalo podle dokumentace. Ale spolu s názorem, že nejlepší dokumentací je zdrojový kód – tak často rozšířený v linuxové komunitě – tedy vykouká se zdrojového kódu, jak se to chová, případně teste nějakým pokusným programkem – takovou zpětnou kompatibilitu je fakticky nemožné udržet.
„Pokud zavádíte novou funkcionalitu, tak ji prostě přidáte k té stávající. Tím je zajištěno, že vaše aplikace poběží i s každou novější verzí dané knihovny. Minimální verzi pak můžete ověřit při instalaci.“
Škoda, že v praxi sa to stává poněkud problematičtějším.
Když je to tak jednoduché, proč je takový rozšířený a obecný problém s různými verzemi knihoven?
Lakování na růžovo je oblíbená disciplína směrem k začátečníkům.
-
Lael Ophir (neregistrovaný)
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.
-
Petr M (neregistrovaný)
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ší.
-
Karel (neregistrovaný)
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.
-
Lael Ophir (neregistrovaný)
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.
-
Karel (neregistrovaný)
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.
-
Lael Ophir (neregistrovaný)
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/ -
j (neregistrovaný)
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.
-
Lael Ophir (neregistrovaný)
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\Profiles\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 SHGetSpecialFolderLocation.
- 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 SHGetSpecialFolderLocation.
- 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 SHGetSpecialFolderLocation.
- 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/ -
j (neregistrovaný)
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.
-
Petr M (neregistrovaný)
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.
-
Lael Ophir (neregistrovaný)
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ů.
-
Ivan (neregistrovaný)
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.
-
Petr M (neregistrovaný)
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? -
Lael Ophir (neregistrovaný)
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 FolderBrowserDialog.
http://msdn.microsoft.com/en-us/library/System.Windows.Forms.FolderBrowserDialog(v=vs.110).aspx -
Ales Hakl (neregistrovaný)
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).
-
Lael Ophir (neregistrovaný)
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 -
Petr M (neregistrovaný)
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...
-
Lael Ophir (neregistrovaný)
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. -
O kvalitě VLC se samozřejmě můžeme bavit, ale prohlašovat, že to nikdo nepoužívá, no, to prostě neodpovídá realitě.
Předpokládat můžeš, ale dotyčný ti to popsal dostatečně na to, aby tvé tvrzení bylo už předem vyvrácené.
1. Souhlasím. Ale neodpovídá to na otázku, co v situaci, kdy ta dokumentace chybí.
2. Já ho nepochopil tak, že by si chtěl upravovat zdrojáky těch knihoven. Předpokládám, že chtěl prostě mrknou do zdrojáku, a podle toho to potom nějak hacknout podobně jak jsi to doporučoval ty. Samozřejmě je lepší, když je apka na něco takového připravená, třeba jako tebou zmiňovaný PostgreSQL. -
Petr M (neregistrovaný)
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í.
-
Lael Ophir (neregistrovaný)
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/frTěž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).
-
j (neregistrovaný)
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.
-
„Pokud vytváříte program, který nevyužívá žádné knihovny, tak vám vznikne spustitelný soubor a je hotovo. Jenže takových programů je minimum, pro cokoliv většího je běžné, že chcete využít nějaké knihovny funkcí. Kupříklad pro vstup z konzole, výstup na obrazovku, pro přístup k síti atd.“
A ty knihovny funkcí si právě můžete staticky přilinkovat, takže ergo kladívko vám vnzikne přesně ten jeden jediný spustitelný soubor, který nevyužívá žádné knihovny s výjimkou API operačního systému.
-
jdsulin2 (neregistrovaný)
Je to blbost, staticky linkovat ma smysl u malych systemu, kde se prehraje cely system (embedded zarizeni) misto celeho systemu. Ale problemy v jinem pripade jsou naprosto silene:
1) bugfix v knihovne -> je nutne prekompilovat zavisle programy -> pokud je to nejaka zakladni knihovna, je to docela dlouha doba kompilace vzhledem k poctu balicku na soucasnych distribucich a jejich velikosti
2) dejme tomu, ze toto nebude problem - pravidelna rekompilace na rychlem stroji (strojich) -> chceme dostat aktualizace k uzivatelum -> stazeni GB datTohle je zasadni problem, ktery vyresi dynamicke linkovani. Tze na windows, kde si kazdy program taha svoje knihovny je to asi lepsi zkompilovat staticky. Jenze tam je problem s licenci LGPL, ale na to tady mate docela jasny nazor :)
