Přechod z Windows na Linux z pohledu vývojáře

Na Anteru’s blog vyšel článek o zkušenostech vývojáře, který dosud pracoval s Windows, s přechodem na Linux (a především s přenosem veškerého vývoje na jinou platformu): Switching to Linux: A Windows developer’s view.

17.9.2009 10:57 | Robert Krátký | Zajímavý článek

Komentáře

[Luboš Doležel (Doli)]

Souhlasím s autorem zápisku. Přechod C++ programátora z Windows na Linux je obrovská úleva. Linux má dokonale jednoduché API, které si člověk i pamatuje nazpaměť. U WINAPI jsem si nezapamatoval ani CreateFile. Nejlepší funkcí celého API je pak CloseWindow, které minimalizuje okno.

[linear]

to je cena za pevne API. MS bude muset emulovat a podporovat chyby Win32 AP za do konce sveta. Proto take nemuze zasadne predelat bezpecnost, uzivatelska prava apod. - starsi aplikace vyzaduji administratorska prava a Windows jim to MUSI tak ci onak umoznit, jinak uzivatele budou kricet (zdrojaky nikdo nema, opravit to nejde. argument "Predtim to fungovalo" vitezi).

[Kvakor]

To je jeden z důvodů, proč Microsoft zplodil dotNet. A nejspíš bude muset udělat to samé, jako už udělal Apple u OS X - kompletně zahodit staré jádro, použí nové a veškeré obludnosti typu Win32 API navěky věků uvěznit do nějakého druhu emulátoru či virtuálního stroje.

[Yenya]

A UNIX nema pevne API? To neni cena za _pevne_ API, ale za spatne navrzene API. Koneckoncu to UNIXove taky neni bez chyb (kdyz pominu vtipky o chybejicim e v nazvu creat(2), tak treba chybejici fbarrier(2) a tim nutnost vyuzivani fsync(2) vic nez je zdravo). Kazdopadne UNIXove API je daleko starsi nez Win32, a je taky pevne.

 

-Yenya

[linear]

 UNIX ma pevne minimalisticke API (POSIX) a Linux to API podporuje. Nicmene, Linux ani vetsina knihoven pevne API nemaji a neni to ani zapotrebi. Kdyz je v API nejaka nekonzistence nebo chyba, API se opravi a dotcene programy opravi a znovu prelozi. Jelikoz se jedna o open source, to lze. Pokud by v repozitari byl freeware, adware anebo sharewere, pak by to neslo.

[dsdds]

mas spatne informace, linux ma pevne api a kernelovych vyvojaru by ses hluboce dotknul, kdybys tvrdil ze ne

[Ivan]

 Zrovna ted mam uplne obracenou zkusenost. Posledni mesic jsem stravil portaci svyho programu na wokna. Cela ta COFF architektura je uplne silena. Pro Linuxare je nepochopitelna prace s knihovnama (staticky/dynamicky), exportovani symbolu(i kdyz to uz je ted v gcc mozny taky), debug build ma jiny ABI nez release build. dumpbin je hodne chaba nahrada za nm a ldd. A minifest soubory? To je naprosta silenost. Chybovy hlasky MSVC jsou strohy a nekonkteretni - no proste neni to zadna sranda. Na druhou stranu bych chtel MS pochvalit za perfektni interagraci debugeru do Visual Studia, to se jim opravdu povedlo.

Trosku me zarazi, ze autor clanku nezminuje problemy s GDB.

 

[Jardík]

BTW co je tohle za blbosti? Pokud ti nevyhovuje MSVC, který na rozdíl od GCC umí pořádně optimalizovat, spouští se ve zlomku času, co podobně nabušené prostředí v linuxu, tak si stáhni gcc pro windows, stáhni si gnu-make pro windows, stáhni si pkg-config pro windows, cmake pro windows a jánevím co, nebo si to ručně zkompiluj, a můžeš se vyblbnout. Ani jedno nemá závislost na cygwinu, takže netřeba instalovat sra*ky. Jestli však tvůj projekt používá zastaralé a omezené autotools závislé na interpretech skriptů tak máš smůlu a pořiď si cygwin (poue 32bit šmejďárna), nebo si zůstaň u linuxu.

[aaaa]

RE: tak si stáhni gcc pro windows, stáhni si gnu-make pro windows, stáhni si pkg-config pro windows, cmake pro windows a jánevím co, nebo si to ručně zkompiluj, a můžeš se vyblbnout.

... linux kernel pre windows...

[huhu]

Jardíka pro Windows

[aaaa]

RE:Jardíka pro Windows

Toho vacsinou nespustis pod beznymi Windowsami - on je kompletne skompilovany dynamicky pre 64b a uz sa podla neoverenych sprav pracuje na 128b verzii Jardika...

[l4m4]

Che, kupovat si kompilátor, který je v podpoře standardů C/C++ většinou 100 let za opicemi, je poslední stupeň zoufalství...

A všechny build systémy jsou založeny na spouštění skriptů. Kupříkladu v Pythonu nebo ve vlastním výmyslu toho build systému. Jmenuj nějaký, který není.

[Jardík]

Proč kupovat? Ve Windows SDK je ten kompilátor úplně zdarma i pro komerční použití, včetně 64bit verze bez GUI, pokud chci GUI, stáhnu si Visual Studio Express (také možno používat komerčně, což sice opravdu dříve nešlo, ale minimálně od verze 2008 ano), které pouze nemá jen nějaké extra fíčury, které běžný programátor stejně nikdy nevyužije. MSVC kompilátor je v podpoře standardů na dostatečné úrovni. Jelikož to není primárně C kompilátor, ale C++, tak se mu dá odpustit i nějaká ta nepodpora něčeho z C99, co v C++ stejně nemá co dělat. Navíc podporuje většinu věcí z TR1 a verze 2010 (což je teď beta) má i podporu C++0x na lepší úrovni než GCC.

[l4m4]

Jmenuj nějaký, který není.

[Jardík]

Co kdo není?

[Dvorak]

U tebe jsem si celkem jist, že jsi pod Windows nikdy neprogramoval. Prosím piš o tom, o čem něco víš. Dík.

[Jardík]

BTW BTW víte, že řešit takovýhle stupidity není ani třeba? Windows API je totiž poměrně soběstačné a obsahuje většinu toho, co vývojář potřebuje - grafika, multimédia, gui, soubory, xml. Co jiného člověk vlastně potřebuje ... to není jako na linuxu, že aplikace zbytečně závisí na 50 knihovnách a ty na dalších 50 jenom proto, že v linuxu takové API není.

Dáme příklad - vezměme v úvahu programování komprimačního programu. Co asi potřebuje. Je to program zaměřený na jednu danou věc, takových budeme mít v systému ... správně. Jeden, né 50 jako na linuxu. Takže vývojář stáhne pár knihoven ke kompresi, popř. chce-li si je napsat sám (např. zlib není použitelný kvůli nepodpoře deflate64), támhleto kvůli licenci, tak si je napíše. Jelikož takový program je v systému jeden, nepotřebují být knihovny sdílené a prasit nám tak systém, můžou být ve složce s programem, aniž by bylo nutné prasit nastavení ld či hardcodovat cesty do binárky. S použitím knihoven se napíše nějaké to jádro a na to se napatlá GUI - k tomu však nepotřebujete libstokravin závislých na libstokravin-2.0, ale pouze WinAPI. Kompresní program jistě nebude mít složité GUI, takže netřeba nějakých hackoidních layoutů, které přidávají overhead. O DPI se vám postará systém a pokud není programátor prase a nehardcoduje velikosti fontů v pixelech a správně používá WinAPI k správnému pozicování ovládacích prvků, nemůže nastat, že se text nevejde, kam má.

[x]

Nj, a pak to vypada tak, ze proto aby vam fungoval programek velky 100k potrebujete instalovat 200MB .NET a potrebujete mit na disku 20+GB dll. Kdezto u toho tuxe si muzete ric co ano a co ne a pokud si to sam kompiluju (napr Gentoo), tak mam v systemu jen a pouze to co potrebuju a ne tuny nepotrebnych sracek. Nejuzasnejsi je, ze i w7 obsahujou knihovny z dob win 3.1, kvuli "kompatabilite", ktera stejne neexistuje.

[Jardík]

Windows 7 z Win 3.1 žádný sračky nemají, protože to byl 16bit systém a Windows 7 x64 žádnou 16bit podporu nemá. Ve Windows sice mám 10 GB sraček, ale když pak v linuxu nainstaluju 5 aplikací, každou pro jiný desktopový prostředí, tak jsem u těch 10GB stejně, hlavně když aplikace není v repozitáři, musím si ji ručně zkompilovat = 10GB zbytečných hlavičkových souborů, vývojových knihoven, kompilátor, pak kvůli dementnímu build systému potřebují různé aplikace jen kvůli sestavení/konfiguraci další build závislosti - např. perl, python, k nim další kýbl modulů a pak nejen, že máme zprasený systém, ale je to instalační peklo. Ve Windows stáhnu a nainstaluju, popř. rozbalím. Díky UAC mi to ani nemůže zesrat systém, maximálně profil (což může i configure skript v linuxu, stačí zapomenout dá uvozovky k argumentu rm a buildit ve složce s mezerou), můžu si vybrat složku, kam instalovat, např. když mi dochází místo, nainstaluju prostě na druhý disk - to v linuxu nelze s použitím balíčků, aniž by mi to rozesralo funkčnost aplikace (kromě pár výjimek, který nehardcodují cesty, např. firefox).

[joker]

che cha cho cho, why so serious.

Linux sa moze chvastat x vecami ze ma lepsie ako windows (aj ked v mnohych je to sporne) ale v jednej urcite je na tom linux stale biedne - developerske nastroje.

Bez urazky ale firmy ako Borland, Sybase  a ostatne to vzdaly a naozaj MS dev nastroje su na urovni a z linuxom sa to neda ani zrovnavat. Prve buildy Kdevelopu boli otrasne a ani

dnes to neni zrovna ziadne kakao.Linux ma roztriestene api (nemyslim teraz cisto kernel ale skor cely os ako taky), dokumentacia je tiez dost nejednotna o MSDNku mozem iba snivat.

Nehovoriac ze kazdy nainstalovany linux je jedinecny (co je brane ako velke plus pre uzivatelov a stale sa to vyzdvyhuje, ale pre developera je to peklo).

A k .NETu ,porovnavajme porovnatelne. Java vam tiez zavlecie do systemu kopec bordelu, nehovoriac z vas nikto nenuti robit v .nete. Osobne si myslim ze .NET neni najstastnejsia volba a hodi sa skor

na prototypovanie a testovanie pripadne na male a stredne aplikacie skor ako na vyvoj niecoho velkeho (netvrdim ale ze sa to neda).

[linear]

kazdy kdo vyviji multiplatvormni aplikace v C/C++ a chce delat v IDE, dnes musi pozit Eclipse/CDT, protoze nic jineho (prakticky) neexistuje. Visual Studio je vysmech - funguje jen na Windows. V C/C++ se navic dnes vetsinou vyvijeji embedded aplikace (spise tedy potrebuji gcc, nez co jineho). Pro "obycejne" a podnikove aplikace se pouziva spise Python/Java/C# (ten posledni hlavne pro Windows-only) a tady je zase IDE (Eclipse/Netbeans) na Linuxu naprosto spickove. Takze: nevim o cem mluvis.

[Jardík]

Eclipse/Netbeans a špičkové? Vždyť to laguje při všem, co děláte, je to pomalé, tam se vyvýjet fakt nedá. Možná chvilkově, než vás z toho klepne. Když si verzeme VisualStudio, tak tam můžete dělat v C/C++/VB.NET/C#, je to stále rychlé, neloudá se to, všechno reaguje hned, nežere to kýbl paměti. Eclipse a netbeans jsou opravdu pro zoufalce. A jelikož to není multiplatformní, tak můžete použít cmake, který vám vygeneruje projekt pro MSVC, když jste zrovna ve Windows, nebo pro eclipse, když jste v linuxu. Instalovat si takové pomalé molochy ve Windows, to je fakt ostuda.

[linear]

Vyvijet v Eclipse se neda? Potom se svet se riti do zahuby!

[Jardík]

Já jsem to zkoušel jednou, asi před rokem. Ta pomalost GUI mi opravdu bránila ve vývoji dokonce i blbé hello world aplikace!

[finc]

Toto je samozřejmě nesmysl. Tyto javovské IDE je pouze nutné umět nastavit. Defaultní instalaci Eclipse nebo Netbeans je potřeba přizpůsobit pomocí jvm argumentů (viz napr google: tuning Netbeans).

[linear]

 Jo a ten MSDN.... to je HODNE nepovedeny vtip. Porovnavat neprehlednou haldu smeti (kde stejne kazdy vyhledava radeji Googlem) kterou museli v Microsoftu nejake cvicene opice nacvakat s moznosti se na kazdou knihovnu a funkci zeptat primo vyvojare(u) knihovny, upozornit na chyby (kde se to dela v MS? Mel jsem tu potrebu a nenasel jsem) a podivat se do zdrojaku... neuveritelny !

[linear]

 a jak to budes distribuovat? Jo, vytvoris instalator (zbytecna prace navic) a ten setup.exe pak nekdo bude slozite hledat na webu (plus potrebujes domovskou stranku s nejakou propustnosti). Anebo to umistis "nekam" na internet a zadny uzivatel nebude vedet jestli to nahodou neni trojsky kun (bohuzel, vetsinou je). V Ubuntu Linuxu (ktery pouzivam) bys oznamil spravcum Ubuntu ze mas zajimavej programek o ktery je zajem, a pokud tvuj program neni shit o zadne dalsi veci by ses nemusel starat (knihovny, zavislosti, umisteni, instalace). Cili, jsou to 2 ruzne pristupy, kazdy ma svoje plusy, ale me prijde ze ten z Ubuntu ma MNOHEM vic plusu nez v pripade Windows, zejmena z hlediska bezpecnosti (coz se ve Windows pravidelne i projevuje - lide instaluji .exe z neduveryhodnych serveru protoze neni zadny overeny centralni repozitar).

[Atrament]

Neviděl bych to tak jednoznačně ve prospěch repozitářového řešení Ubuntu (a samozřejmě i ostatních distribucí). IMHO je mnohem jednodušší pro vývojáře vytvořit aplikaci, k ní nějaký jednoduchý instalátor (na to jsou nástroje, to není žádná přílišná práce navíc), celé z toho udělat jeden exáč a ten si vyvěsit na homapage odkud si to uživatel stáhne a nainstaluje sám. Nebo na SourceForge, či podobý server. Ostatně spousta věcí v linuxovém světě se takto šíří taky - zrovna včera večer jsem instaloval TuxGuitar, pěkně stažený ze stránek vývojářů, zabalený v *.run s instalačním průvodcem ne nepodobným tomu na jaký se dá narazit v prostředí windows. Hromada her se takto distribuuje taky. Nevidím na tomto modelu nic špatného, přijde mi mnohem pružnější a logičtější a tak nějak svobodnější než centrální repozitáře. A co se týče bezpečnosti - kde máš záruku, že to co je v repozitářích je v pohodě? Co když tvůrci balíčku přeskočí a přihodí ti tam nějaký moc vtipný post-instalační skript?

[Filip Jirsák]

Pro vývojáře to jednodušší je, zbavuje se tím zodpovědnosti za instalaci toho programu. Pro uživatele, kterému to v mnoha případech nepůjde nainstalovat nebo nebude fungovat, a který kvůli tomu musí každý rok přeinstalovávat Windows, to už tak jednoduché není. Ostatně balíčky pro linuxové distribuce zase nemusí dělat jen vývojář, pro většinu používaného software to dělá distribuční správce daného balíčku – a to je pak pro vývojáře ještě jednodušší, stačí, když dá k dispozici rozumně napsané zdrojové kódy a postup buildu.

rovna včera večer jsem instaloval TuxGuitar, pěkně stažený ze stránek vývojářů, zabalený v *.run s instalačním průvodcem ne nepodobným tomu na jaký se dá narazit v prostředí windows. Hromada her se takto distribuuje taky. Nevidím na tomto modelu nic špatného, přijde mi mnohem pružnější a logičtější a tak nějak svobodnější než centrální repozitáře.

Ten model je hlavně mnohem náchylnější k chybám a k rozvrácení systému. Schválně, jak ten program asi odinstalujete? Jak ho budete aktualizovat?

[Jardík]

Např. gamesy od LGF (či jak je ta zkratka) si s sebou tahají uninstaller a na rozdíl od různých balíčkovačů odstraní i prázdné adresáře, co si vytvořil.

[Filip Jirsák]

A myslíte, že bude lepší, když se o správu softwaru bude starat jeden program, nebo když na to budete mít v počítači tisíc různých instalátorů a odinstalátorů, které o sobě navzájem nevědí? Docela by mne zajímalo, jak si takové odinstalátory poradí s nějakou sdílenou knihovnou – instalátor A ji nainstaluje, B zjistí, že už tam je, tak ji nechá být, A při odinstalaci vyvěští z koule, že ji používá i jiný program, tak ji nechá na místě, B při následné odinstalaci nechá knihovnu být, protože ji sám nepřidával – a najendou vám v systému nějak přebývá knihovna, ke které se nikdo nehlásí.

Chybějící mazání prázdných adresářů není principiální vlastnost všech balíčkovačů, ale nějakého jednoho, na který jste náhodou narazil. A pořád lepší, když v systému zůstávají prázdné adresáře, než když tam zůstávají nevyužívané knihovny a další soubory.

[Jardík]

Jak jsem již 100x řekl - programy pro windows nepotřebují kýbl cizích sdílených knihoven, protože winapi je svými funkcemi dostatečné. Když si někdo chce používat zbytečný nadstavby přidávající jednu funkci, tak si hold program tu knihovnu přitáhne s sebou, ale dá si ji do své složky a nebude s tím prasit systém.

[Jardík]

Chybějící mazání prázdných adresářů není principiální vlastnost všech balíčkovačů, ale nějakého jednoho, na který jste náhodou narazil. A pořád lepší, když v systému zůstávají prázdné adresáře, než když tam zůstávají nevyužívané knihovny a další soubory.

Minimálně rpm si je tam klidně nechává a vůbec ho to netrápí, přitom zabírají inody.

A pořád lepší, když v systému zůstávají prázdné adresáře, než když tam zůstávají nevyužívané knihovny a další soubory.

Keci. Každý solidně napsaný program si po sobě všechno uklidí. Pokud ne, není to chyba systému, ale programu. A to, že vám zůstane na disku v uživatelské složce, popř. uživatelově části registru, nastavení je normální, v linuxu a ostatních systémech se to děje zrovna tak.

[Filip Jirsák]

Můžete nám prozradit ten tajemný algoritmus, kterým program pozná, zda jeho sdílené programy používá ještě jiný program, nebo zda je má také odinstalovat? Kecy o tom, jak se ve Windows sdílené knihovny nepoužívají, si nechte pro někoho jiného – pořád pějete ódy na MS Visual Studio, tak jste snad už zaznamenal, že VisualBasic, C++ i .NET mají své sdílené runtime knihovny, například.

[Jardík]

Ano, ty sdílené knihovny mají a je na uživateli, aby si je nainstaloval, popř. na instalátoru programu, aby si o ně daný program řekl - lze to v msi instalátorech udělat poměrně snadno. Ale žádný program nemá nárok na to, aby mi je svévolně odinstalovával.

Jáký program používá sdílené knihovny, které si nainstaloval do systémového adresáře? Algoritmus samozřejmě žádný není, když je program prase a místo ve svém se hrabe v systému ... v linuxu mi balíčkovací program taky nepozná, že program blablabla, který jsem nainstaloval potřebuje libble.so, protože ho balíčkovač neinstaloval, protože nebyl v repozitáři a protože nechci mít kýbl develop sraček, abych si dělal ble.rpm/deb/cokolijineho.

[Filip Jirsák]

Většina správců balíčků v linuxu samozřejmě závislosti řeší. Pokud si každá aplikace instaluje sdílené knihovny k sobě, máte pak v systému akorát spoustu kopií téže knihovny, v různě starých a nezáplatovaných verzích. Pak se všichni diví, proč jsou ty programy ve Windows tak děravé. Pokud si každý prohram nějaké knihovny nainstaluje, ale při odinstalaci je neodinstaluje, musí se v systému hromadit nepoužívané knihovny, ne?

[Jardík]

máte pak v systému akorát spoustu kopií téže knihovny

Tohle není úplná pravda. Když máte ve Windows od každého programu určitého zaměření jeden (což je obvykle pravda), tak každý používá úplně jiné knihovny (a společně WinAPI) a knihovna tam je jednou, takže je přípustné, že ji má program u sebe.

Většina správců balíčků v linuxu samozřejmě závislosti řeší

Tohle nikdo nepopírá. Ale když si, jak jsem řekl, nainstalujete program jinak, než přes balíčkovač (balíček v repozitáři není (nebo být nemůže), daný typ balíčku není kompatibilní s vašim balíčkovačem) a zároveň nechcete kompilovat, instalovat tooly balíčkovače a psát skripty pro balíčkovač (což se běžným uživatelům fakt nechce), tak balíčkovač ví jouby, že to tam je, odebere někdy závislou knihovnu a program pak nejede.

[Filip Jirsák]

Tohle není úplná pravda. Když máte ve Windows od každého programu určitého zaměření jeden (což je obvykle pravda), tak každý používá úplně jiné knihovny (a společně WinAPI) a knihovna tam je jednou, takže je přípustné, že ji má program u sebe.

Třeba runtime knihovny programovacích jazyků, MFC a podobné věci, kompresi a dekompresi, JPEG – to všechno asi bude používat víc programů.

[Jardík]

Bože, s vámi je to těžký. Kompresi i dekompresi JPEG zvládne např. WinAPI a dokonce i poměrně slušně, není třeba 3rdparty knihoven. Takovéhle bláboly vznikají neznalostí něčeho, na co nadávám ... K MFC runtime je instalátor, aplikace si to s sebou tahat nemusí, stačí, podobně jako to dělá balíčkovač, houknout "vole, potřebuju MFC, chceš stáhnout a nainstalovat?". MSI instalátory takový věci umí, ale neznalost, ta toho umí opravdu málo.

[Filip Jirsák]

Tak si tam dosaďte třeba JPEG2000, a hlavně mi netvrďte, že to už je ve WinAPI taky už od Windows '95.

Instalátor umí říct, odkud se má ten instalátor MFC stáhnout, nebo si to laskavý uživatel má vygooglit? Pokud to instalátor umí říct sám, co když dvě různé aplikace použijou různé cesty k instalátoru knihoven (jedna třeba odkáže na MS, druhá na web autora), nebudou si pak knihovny přepisovat? Nebo existuje nějaký centrální seznam těch knihoven? Pokud ano, zbývá dopsat už jenom tu odinstalaci knihoven, pokud se odinstalují všechny balíčky, které na nich závisely, a bude z toho celkem slušná verze správce balíčků. Je hezké, že to po těch letech MS také vynalezl.

[Atrament]

odinstalace - smažu adresář /opt/tuxguitar-1.1 a .tuxguitar-1-1 ve svém home adresáři. Případně použiju uninstall, kterým TuxGuitar disponuje. aktualizace - stáhnu novej balík a nainstaluji, přičemž pokud bude fungovat správně a bude se mi líbit a stará verze se tak stane nepotřebná, provedu její odinstalaci - viz odinstalace

Kde a jak mi to může rozvrátit systém? To by byl hodně špatný systém kdyby mi ho prostá instalace nějaké drobné aplikace rozvrátila :)

[Jardík]

setup.exe, to je vtip? Existuje něco se jménem msi a na rozdíl od setup.exe to není závislé na architektuře.

[1john2]

msi je nezavisle na architekture? to me zajima... muzete to rozvest? jak moc nezavisle to je?

[Misomim]

Má na mysli Windows 32bit/Windows 64bit - takovou nezávislost, žádnou jinou.

[Filip Jirsák]

„Nezávislé na architektuře“ znamená, že nezávisle na tom, zda máte Windows 2000, Windows XP nebo Windows Vista, vždy na tom něco nebude fungovat

[dark]

Připadá mi to spíš jako zápisek člověka, který nikdy nebyl zvyklý psát pro více OS, a najednou objevil cmake a Qt - řekněte Wow. Navíc ty problémy, co tam popisuje, jsou způsobené jen jeho návrhem aplikace, nemá to co dělat s Windows.

Sečteno a podtrženo, kachna jak prase :)

[Jardík]

To je ubohý, poslal jsem mu tam komentář, že o nepřítomnosti x64 kompilátoru ve visual studiu lže, o tom, že neumí programovat ve WindowsAPI, že ve Windows nepotřebuje kýbl 3rdparty knihoven a pod. a ten blb ten komentář zcenzuroval. No co, napsal jsem mu tam další. Nechápu lidi, co si napíší veřejný zápisek a pak cenzurují komentáře, které se jim nelíbí. Sám ze sebe dělá vola, tak jsem ho (pouze slušně) upozornil na chyby, kterých se v zápise dopustil a blablabla. Tímto jeho zápis považuji za ubohý, nepodložený a bezpředmnětný a jeho osoba pro mě neznamená nic, když si ani neváží názoru ostatních.

[linear]

pokud jsi mu napsal ze v Linuxu potrebuje nejaky "3rd party knihovny", tak se nedivim ze takoveho pablba zcenzuroval

[Ondra]

Přesně tak. Windowsové api umí narozdíl od linuxového víc, než otvírat soubory a fork(). Programátor vyvíjející aplikace c++ má tak k disposici téměř vše, co potřebuje, navíc excelentně dokumentované v MSDN. V základním API je obsažena správa procesů, vláken (pro linuxáře možná překvapení, že něco takového existuje), gui, multimédia, kryptografie a PKI atd. atd. V práci jem například potřeboval dekódovat ASN.1 strukturu - obsaženo v jádře (CryptDecodeObject), na linuxu by muj kód musel být závislý na 3rd party knihovně. Práce s vlákny a synchronizací to je kapitola sama o sobě, před x lety lidé kolem linuxu konečně pochopili, že aplikace se programují vícevláknově namísto forkování a zbastlili libpthread = další závislost navíc pro vyvíjené aplikace. Ve Windows je jednotný model synchronizace a čekání na objekty viz http://msdn.microsoft.com/en-us/library/ms686353(VS.85).aspx. Objekty ve windows podporují jednotný propracovaný model autorizace pomocí access control listů, takže lze nastavit přístup jak k souboru, tak například ke gobálnímu mutexu, nebo pipě. ACL umožňují nastavit nebo odepřít přístup libovolnému uživateli, nebo skupině, lze definovat komplexní pravidla. Myslím si, že systém, který na začátku 21. století podporuje řízení přístupu stylem "u+rw,g+r,o+r" je výsměch technickému pokroku. Funkce Windows API jsou designovány tak, aby podporovaly množství nastavení namísto jen základní funkčnosti. Proto se mohou zdát na první pohled nešikovné, ale pokud se vývojář naučí je plně využívat, dost si jimi ulehčí práci. Příkladem je nastavení sdílení přístupu k souboru přímo při otevření CreateFile. Vzpomínám si, jak složité bylo docílit to samé v linuxu. Pročítání manuálů, advisory lock, neadvisory lock, polovona přepínačů kdoví kde dokumentovaných .. hrůza. Osobně jsem nikdy neměl problém najít přesný popis chování jakékoliv funkce Windows API v MSDN včetně všech vstupních i výstupních datových struktur, u většiny jsou i názorné příklady použití. Takhle má podle mě vypadat dokumentace.