Vlákno názorů k článku Jan Jirkovský: pro indie vývojáře je nejvýhodnější vyvíjet multiplatformně od pravdokop - ... že je lepší vyvíjet multiplatformě pro všechny...
-
... že je lepší vyvíjet multiplatformě pro všechny vývojáře na světě.
Krapet větší rozsah práce (o cca 5-10 %) je bohatě vyvážen mnohem lepším ošetřením chyb (na každé platformě se projevují jinak a jindy), koncepčnějším návrhem (nutno zapracovat potenciální platformní rozdíly) a samozřejmě také větším trhem pro odbyt.
Pro mne neméně důležitým argumentem je i fakt, že se tím snižuje moc mamutích kvazi-monopolních producentů OS, nadšených z každého vendor-lockingu. -
Rax (neregistrovaný)
Je třeba se na to dívat z hlediska celého řetězce, tedy návrh+vývoj+testování+obchod. Nativní klikací aplikačku pro Windows uplácám za chvíli a mám tak pokryto 90 % trhu v ČR. Abych pokryl těch zbývajících 10 %, musím jít do multiplatformnosti, to mě stojí až 2x tolik času a těchto 10 % mě ani nepokryje zvýšené náklady kvůli multiplatformnosti, natož že by se realizoval nějaký zisk.
-
"Nativní klikací aplikačku pro Windows uplácám za chvíli"
S dnešními frameworky máte za chvíli multiplatformní klikací aplikačku. ;) A máte pokryto 99% trhu. A nedtvrďte mi, že pokud provádíte vývoj pro Widle tak další testovaní pro Linux vám sežere tolik prostředků. (U Maca veřím, že je to minimálně ze začátku dražší, protože pořizovací cena je taky mnohem vyšší).
-
Chlup (neregistrovaný)
Buďte konkrétní jaké frameworky mám použít, abych ukliklal multiplatformní aplikačku s malým nárůstém práce oproti win-only aplikačce.
A pochopitelně, aby to splňovalo nějaké základní podmínky se kterými to má smysl.
Tedy bude to svižné a bude to k něčemu vypadat - nebudou se od uživatelů při spuštění ozývat výkřiky jako "nééé, to je java" (což neznamená, že to nesmí být java, jenom to nesmí mít typický javovský desktopový "look nad feel").
A pokud si ta aplikace chce stahovat ty balíky frameworků, tak to musí proběhnout tak, aby uživatel do toho zasahoval jenom minimálně.Moje otázka je myšlenka trochu ironicky - protože si myslím, že neexistuje žádný framework, který by tohle splňoval. Ale budu se hrozně rád mýlit a hrozně rád se dozvím, že něco takového už existuje.
-
Chlup (neregistrovaný)
Slovo "uplácám" jsem nahradil slovem "uklikám". Nevidím v tom žádný rozdíl. V Gamemakeru jsem v životě nedělal, hry jsou na okraji zájmu mého profesionálního zaměření, hry jsem zkoušel dělat ze zábavy a pouze na win platformu. Do diskuze jsem se zapojil, protože mám za sebou několik multiplatformních neherních projektů.
ClanLib a SDL jsem zkoumal i když jsem v nich přímo nevyvíjel - nejsou to špatné věci, ale řeší jenom ČÁST problému a rozhodně to nejsou balíky, se kterými získám multiplatformní aplikaci za 5-10% času navíc oproti win-only (jak píše na začátku vlákna pravdokop).
-
Já v tom vidím sakra rozdíl. Je něco jiného si "namalovat" aplikaci a dopsat několik událostí jako například v Gambasu (něco jako VisualBasic) a je něco jiného si celé okno poctivě napsat (tedy umístit každý widget a ošetřit jejich vzájemné vztahy, polohu, vykreslování, atd...) jako třeba ve Fox Toolkitu v C++. Oboje má svoje výhody a nevýhody. gameMaker nebo Game Editor je vhodný pro ty co se nechtějí moc piplat z herní aplikací, nebo si to alespoň vyzkoušet. Výsledky podle toho pak ale taky odpovídají.
Bavíme se o jednoduchých aplikacích? předpokládám, že se nebavíme o vývojáři, který se teprve rozhoduje jaký jazyk se bude učit, ale o někom kdo zvládá minimálně C (SDL, Allegro) nebo C++ (Allegro, SDL, ClanLib). Já jsem schopný programovou stránku zvládnout jednoduché hry v ClanLib velmi rychle a předpokládám, že profesionál to zvládne mnohem rychleji. Pokud nejsem dežo a nevkládám do aplikace platformě závislé věci (jaké by vlastně hra, notabene jednoduchá hra, tak asi potřebovala platformní závislosti?), a mám všechno co potřebuji: grafiku (images, drw rutiny, polygons, particles, atd..) matematiku/fyziku, zvuk, přístup k filesystému, přichystané herní objekty. Stačí to jen mírně poupravit a poskládat do fungující aplikace jak si představuji a pak už jen hru přeložit pro každou platformu (min Win a Linux zvládám na Linuxu) a mohu se směle pustit do testování. Co je na tom složitějšího?
Upřímně, věřím že napsat jednoduchou hříčku např. pod LOVE zvládne kde jakej křupan, který je schopný pochopit základy programovaní a jazyka Lua. Navíc má hned podporu pro několik platforem (a to i mobilních) a nemusí ani hnout prstem. - to jen k těm frameworkům a jejich vyspělosti.
-
Chlup (neregistrovaný)
Tak bohužel vám nerozumím. Budete se točit na tom, že jsem použil jiné slovo, než jste zvyklý?
Prvně se opovržlivě vyjadřujete o gamemakeru a následně jako příklad uvedete tvorbu hříček pod LOVE?Měl jsem za to, že SDL a ClanLib nejdou zdaleka tak daleko jako Qt - a i při použití Qt (s tím mám praktické zkušenosti) je pořád ještě dost práce s tím "mírně poupravit a poskládat do fungující aplikace".
To je to, co je na tom složetější a hlavně pracnější. O samotném vývoji pod knihovnou, která neumí zdaleka tolik, jako nativní knihovny jednotlivých systémů nemluvě. -
"Budete se točit na tom, že jsem použil jiné slovo, než jste zvyklý?"
Jestli vám příjdou dvě slova s naprosto odlišným významem a dopadem na vývoj samotný jako pouhé slovíčkaření, pak tedy smekám. To mě potom neudivuje, že nevidíte rozdíl mezi enginem LOVE (Kde si kompletně celou hru musíte napsat sám - hotový je pouze engine ), a Game makerem (do kterého v podstatě nasypete resources a naklikáte si co to má dělat).
"Měl jsem za to, že SDL a ClanLib nejdou zdaleka tak daleko jako Qt - a i při použití Qt (s tím mám praktické zkušenosti) je pořád ještě dost práce s tím "mírně poupravit a poskládat do fungující aplikace"..."
Teď pro změnu nerozumím já Vám. SDL a ClanLib jsou naprosto odlišné projekty, programované pro jinou třídu aplikací, jiný typ úloh a s jinou filosofií než Qt. Porovnávat "pokročilost" těchto aplikací, je podobné jak porovnávat "pokročilost" Boingu a kombajnu.Každopádně, začínám získávat ten dojem, že se mi snažíte vysvětlit, že ve Win stčí jen někam nasipat kupu resources, říc Widlím "tady to máš" a je z toho hra. jak funguje? odkud ví objekty jak se mají chovat, kdy a jak mají být odebrány z paměti? kdo ví? Skvělé, sekce SCI-FI je o server dál... :-(
"O samotném vývoji pod knihovnou, která neumí zdaleka tolik, jako nativní knihovny jednotlivých systémů nemluvě."
Znovu. Bavíme-li se pořád o jednoduchých hrách, pak by mě zajímalo, co výše zmíněné framworkům ( oproti Widlím ) chybí. To mi zatím není (a už se na to ptám poměrně dlouho) nikdo schopen vysvětlit. Há-em.Já bych řekl, že je to jinak. Co kdyby si šéf vzal do hlavy, že se vaší firmě najednou vyplatí psát multiplatformní aplikace (hry). A najednou by se programátoři, kteří se doposud zabívali jen Win API, museli učit něco nového. Říká se, že lenost je jedna z cností každého programátora (to nemám ze své hlavy :-D )
-
Ten člověk má pravdu, jenom puntičkaříte.
Nemáte ani šajnu o tom, co znamená multiplatformost a co to obnáší. Až taková legrace to není.
Zkuste si někdy naprogramovat větší projekt multiplatformně – nemusí být ani herní a už nikdy nebudete psát, že je to easy peasy.
Ony se ty platformy liší miliónem drobných detailů a přes všechny snahu to zakrýt multiplatformním frameworkem to jednak nejde dokonale, jednak se za to platí určitá cena – ztráta rychlosti, omezenost API či často i debilita samotného multiplatformního API, nutnost omezit se na společný průnik všech platforem – a stačí když na jedné to bude chybět. Občas mívají multiplatformní API i právní problémy, tedy debilní licenci (není problémem zmíněných). Dále si musíte odpustit využití silných stránek nějaké platformy, nebo dokonce emulovat to co některé platfromy mají a často velmi dobře udělané ve jménu multiplatformovosti.
Kromě toho musíte ty multiplatformní věci na těch platfromách otestovat. A udržovat a spravovat a opravovat bugfixy a distribuovat. Zejména na linuxu pak je třeba otestovat řadu distribucí/verzí/kombinací všeho možného.
Učit se nové API není nic těžkého, pokud je interface knihovny dobře vymyšlen (velmi zřídkavé) a pokud je dobrá dokumentace (velmi zřídkavé).
WinAPI je opravdu velmi dobré a obsahuje obrovskou kupu funkcí a hlavně podporu pro mnoho věcí. Navíc není vždy vymyšleno tak špatně, je zásadně Unicode a multithread (pokud to jde) a je velmi dobře zdokumentováno (mnohem lépe, než třeba většina unixových/multiplatformních API).
Je rozhodně jednodušší udělat projekt jednoplatformový – třeba i pouze linuxový, než multiplatformový. Kurevsky jednodušší, pokud děláte poněkud složitější projekty než Hello World, nebo Hledání min.
Kromě toho na multiplatformový projekt potřebujete znalejší lidi se zkušenostmi z těch více platform – a mělo by se to vyplatit.
Zkrátka přestaňte politicky okecávat a dodejte nějaké důkazy. Přestaňte chytat za slovíčka. Protože moje 25letá praxe nintenzivně na pěti operačních systémech vám nedává za pravdu.
-
Pane Ponkrác s prominutím, ale to je naprostý žvást. A zajímalo by mě, kde jste předložil ty důkazy po kterých se tak vehementně dovoláváte, krom prohlášení o Vašich 25 letých zkušennostech, které Vám věřit mohu a nemusím.
Navíc to slovíčkaření se týkalo rozdílu mezi ručně psanou a generovanou aplikací. Kdyby jste byl tak hodný, a než začnete do něčeho rejpat, si alespoň přečetl o co vlastně Váš potencionální oponent píše, nebo o čem se diskutuje.
Platformy se samozřejmě liší milionem detailů, které cca 90 - 95% překryje framework (moje osobní zkušenost s výše uvedenými frameworky ). Při dobrém návrhu projektu je člověk schopen se většinou těmto problémům vyhnout.
Nevím kolik jste naprogramoval multiplatformních her, ale z vlastních zkušenností vím, že výše zmiňovaná frameworky Vám ve svém API poskytnou vše co pro vývoj her potřebujete. Zatím mi nikdo nebyl jasně schopen říct co KONKRÉTNĚ JIM CHYBÍ PRO TENTO ÚČEL. Samozřejmě kro všeříkajícího : "WinAPI je opravdu velmi dobré a obsahuje obrovskou kupu funkcí a hlavně podporu pro mnoho věcí. " (Což jsou sice vaše slova, ale nicméně takhle na tu otázku odpovídá skoro každý podobný oponent, kterého se zeptám). Hm.. aha, to jsem se toho dozvěděl.
Jinak už v dávných dobách jsem pracoval na aplikacích, jejich vnitřní (funkční) část se dělala jako core knihovny a GUI se dodělávalo pro Widle v VB a Linuxu pod Qt (kvůli licenci). Takže bych řekl, že zkušeností s tím mám docela dost. Neříkám že to bylo jednoduché, ale jakmile jsme přišli jak na to, už nám to žádné problémy nedělalo. Dneska je to minimálně o dva řády jednoduší, jednak proto, že se změnila licence Qt, a jednak proto, že existuje dost konkurenčních multiplatformních frameworku.
-
Chlup (neregistrovaný)
1. LOVE znám velmi povrchně a pokud je pravda to, co o něm říkáte, pak jsem se mýlil. Psal jsem, že vývoj her není moje hlavní činnost a psal jsem, proč se téhle diskuze účastním.
2. SDL, ClanLib, Qt - jistě, že to jsou zcela odlišné projekty. Ale mohu je porovnávat v tom - jak moc mi usnadní úkol o kterém je tato diskuze - tedy vývoj multiplatformní aplikace. Takové srovnání smysl má.
3. Pokud získáváte dojem, že se vám snažím vysvětlit, že na Win stačí podstrčit kupu resources a zamíchat, tak to získáváte dojem zcela chybný. Tvrdím, že vývoj her (a obecně jakýchkoliv multimediálních aplikací) jako win-only je ze všech ostatních možností nejsnazší a nejpohodlnější. Rozhodně je to mnohem snazší a mnohem pohodlnější než vývoj multiplatformní. A rozdíl je větší (obvykle výrazně) než 5/10/15%. To je moje pointa, co tady omýlám pořád dokola.
Jiným než win-nativním knihovnám obvykle chybí to, abych danou eye-candy věc udělal stejně snadno a levně.4. Poslednímu odstavci bohužel vůbec nerozumím a netuším, kam míříte. Už jsem psal, že mám za sebou několik multiplatformních projektů, takže kdyby můj šéf chtěl, abych psal multiplatformní hru, tak nové by pro mne bylo jenom to, že bych pracoval komerčně na vývoji hry.
-
1.
V pohodě, porovnejte sám :
http://gamemaker.czweb.org/gmaker.php
https://love2d.org/wiki/Main_Page2.
Jasně, ale právě o to jde. Chápejte, Kombajn a Boing jsou dopravní prostředky (no dobře, kombajn...:-D ) ale určitě by jste do Francie necestoval na kombajnu. :)Chci tím říci, že samotný pojem "aplikace" je strašně obecný. Ano QT mi poskytne daleko více nástrojů, na rozdíl od třeba ClanLib (ať zůstaneme v C++), ale ClanLib se zaměřuje na herní aplikace a všechno tomu podřizuje. Proto si jsem přesvědčen, že vývoj hry pod ClanLib bude jednoduší, narozdíl od QT. I protože pokrývá všechny oblasti co k tomu potřebujete.
3) To souvisí s bodem 2. Jestliže budu cestovat do Francie na kombajnu, tak si tu cestu... ehm, určitě užiji (ale rozhodně se mi to asi líbit nebude :) ). vidím to tak, že pokud budu chtít vyvíjet hru, zvolím tohle, pokud budu chtít vyvíjet aplikaci jiného zaměření, kde se spíš hodí řekněme... velký toolkit, který je sám OS v operačním systému, zvolím QT. Navíc většina vývojových studií se přece zaměřuje jen na určitý druh aplikací.
Vidím to tak, že pravda může být na obou stranách. Záleží na projektu a na prostředcích.
4. To bylo jen takové rejpnutí, neberte to vážně :)
-
Chlup (neregistrovaný)
Qt je rozhodně dobrá a použitelná věc. Bohužel její instalace na windows není vždy bezproblémová a bezuživatelská. A pochopil jsem, že na macu to není o moc lepší (i když tam se to týkalo spíše SDK).
Pokud bych vyvíjel multiplatformní hru, tak bych velmi pravděpodobně šel touto cestou, ale rozhodně bych netvrdil, že mě to bude stát pouze 5-10% úsilí navíc oproti win-only vývoji. -
Rax (neregistrovaný)
Prosím vyjmenovat multiplatformní frameworky pro solidní nativní klikací aplikačky, rozuměj se solidním GUI.
Náklady na Windows jsou menší prokazatelně, jednak je uvnitř Windows spousta hotového API, na Linuxu aby si člověk půlku napsal sám a ještě nestačí testovat jenom XP,Vista,7 a 8 ale nejméně desítku distribucí. Když se k tomu přidá fakt, že na Windows to běží roky, například solidně napsaná aplikace pro XP běží i na 7, tak na Linuxu se co půl roku mění jádro a aplikačka se obvykle kompletně ro*ese*e a to je další práce navíc.O něco lépe je na tom multiplatformní service/daemonu, tam je situace o něco lepší, ovšem service/daemon se prodává podstatně méně.
-
aaaaaaaaaaaaaaaaaaa (neregistrovaný)
> Na tom není co vysvětlovat, prostě práce a ladění s QT je o něco větší opruz než normálně
To je tak vseobecne povedane az sa mi to nezda byt pravda. Ja som nieco malo robil v QT a ladenie sa mi nezdalo nejake hrozne oproti vyvoju cisteho C bez GUI. Debugger tam ide, breakpointy to ma a to staci. Ale co konkretne sa vam zdalo byt take zle?
> Uživatelům vadí že QT je mírně jiné a funguje mírně jinak.
S cim to porovnavate? Ak porovnavate QT a Gtk, tak je trochu ine, aj ked sa to da dost prisposobit. Ale na Windows som asi prakticky ani nepostrehol rozdiel oproti cisto nativnemu pristupu.
-
jarda667 (neregistrovaný)
Zrovna vcera jsem neveril svym ocim kdyz jsem nainstaloval hru Colin McRae 2 z roku 1999 na Windows 7 64bit a fungovala na prvni spusteni bezproblemu :)
Nerikam ze u vsech her to tak je , ale tomuhle se rika kompatabilita , o tomto se linuxu ani nezda i kdyz u starsich her je to uplne jedno tam funguje DOSBOX jak na linuxu tak windows , nebo wine nebo nejaky emulator.
-
SDL, http://www.libsdl.org/
ClanLib, http://clanlib.org/wiki/Main_Page
Allegro, http://alleg.sourceforge.net/Všechny tři jmenované by měli mít vlastní GUI
-
"Náklady na Windows jsou menší prokazatelně, jednak je uvnitř Windows spousta hotového API, na Linuxu aby si člověk půlku napsal sám"
Konkrétně CO by jste si musel na Linuxu dopsat sám? Co vám konkrétně na Linuxu chybí - i s tím, že použijete výše zmíněné frameworky?
"ještě nestačí testovat jenom XP,Vista,7 a 8 ale nejméně desítku distribucí "
Jednak by mělo bohatě stačit otestovat na několika mainstreamovích. A jednak nic co by se nedalo zvládnout s několika skripty a virtualizačním programem.
"tak na Linuxu se co půl roku mění jádro a aplikačka se obvykle kompletně ro*ese*e a to je další práce navíc."
Ano, uznávám, že tohle je na Linuxu opravdu problém. Jenže ještě jsem nanarazil na nic, co se roz*sr*lo na Linuxu co by zásadně ovlivňovalo hry samotná (jsou-li solidně napsány). Ale je možné, že si jen nevzpomínám, mohu prosit o nějaký příklad (relevantní, kecy typu ovladače, neberu jako relevantní)?
-
Rax (neregistrovaný)
Na Linuxu chybí desítky věcí, například to nejmenší je nulová podpora pro národní charsety na Unicode, na to si mohu napsat nebo stáhnou knihovnu a je to jen práce navíc, ale některé věci nejsou vůbec, třeba nelze čekat na dva a víc mutexů zároveň. A tak by se dalo dlouze pokračovat.
To "mělo by bohatě stačit" opravdu nestačí.
Relevantní příklad je když už nic horšího, tak alespoň změna názvu nějaké důležité .so to se děje co půl roku. Konkrétně .so s jedním názvem zmizí a objeví se podobné .so s podobným názvem ale jiným, takže aplikačka nejde spustit.
-
"Na Linuxu chybí desítky věcí, například to nejmenší je nulová podpora pro národní charsety na Unicode, na to si mohu napsat nebo stáhnou knihovnu a je to jen práce navíc..."
QT, libc, SDL, ClanLib, GTK+ a Fox Toolkit podporu unicode mají stoprocentně.
"ale některé věci nejsou vůbec, třeba nelze čekat na dva a víc mutexů zároveň."
Semafory?
"To "mělo by bohatě stačit" opravdu nestačí."
S takovými argumenty se tu budeme hádat týden a nikam nedospějeme. stačí-nestačí-stačí-nestačí... Jak děti ve školce ;)
"Relevantní příklad je když už nic horšího, tak alespoň změna názvu nějaké důležité .so to se děje co půl roku. Konkrétně .so s jedním názvem zmizí a objeví se podobné .so s podobným názvem ale jiným, takže aplikačka nejde spustit"
Há-Em tak s tím jste mě dostal naprosto, protože tohodle jsem si za těch víc jak deset let co Linux používám všiml opravdu zřídka. Jo, bývají občas rozdíly v názvu u jednotlivých distribucí, ale aby se každýho půl (třeba i každý rok)roku měnil název to mě fakt uniklo. Natož u nějaké důležitější sdílené knihovny :)
Bez urážky, ale mě to příjde jako docela ujetý výmluvy, ne-li něco horšího
-
„QT, libc, SDL, ClanLib, GTK+ a Fox Toolkit podporu unicode mají stoprocentně.“
Na Windows není nic jiného než Unicode. Filesystém a názvy souborů jsou v Unicode. Veškeré vlastnosti, řetězce, hodnoty, vytáhnete z kernelu Windows v Unicode.
Unicode není jenom obal z vnějších knihoven, o kterém unix/linux kernel netuší a v Unicode nepracuje.
„ale některé věci nejsou vůbec, třeba nelze čekat na dva a víc mutexů zároveň. Semafory?“
Neměl byste ze sebe dělat vola.
Semafor je promiskuitní atomické počítadlo bez toho, aby znalo thready a jejich locky někdo vlastnil.
Mutex je synchronizační objekt, jehož počítadlo smí upravovat jenom jeden thread a právě ta znalost vlastníka – threadu je samotným důvodem existence a určení mutexu.
„S takovými argumenty se tu budeme hádat týden a nikam nedospějeme. stačí-nestačí-stačí-nestačí... Jak děti ve školce“
Přesně tak – doučte se.
-
Ono by stačilo, kdybyste přestal plkat a občas odpověděl nevyhýbavě a konkrétně na libovolný můj příspěvek.
Nicméně já s Vámi končím. Vy se jenom kroutíte jako had a děláte ze sebe machra ve věcech, kterým nerozumíte (např. mutex, synchronizační objekty) – ale nezapomínáte jiného řečníka pérovat v termínech.
Takže toho prosím využijte, pořádně mě všude utřete, protože já už na Vás reagovat nebudu. Budete mít poslední slovo a můžete tvrdit cokoli a vymlžit třeba dojem, že jste mě dostal.
-
takhle bych to přímo nespecifikoval. Mám pocit, že se to dalo nastavit pro Widle XP dalo nastavit...
Pro Win 9x vyšla někdy kolem roku 2000 malá knihovnička, která jim umožňovala s unicode pracovat. Jestli s ním bylo 100% kompatibilní tehdejší FAT, to dneska už těžko zjistím, ale NTFS ho mělo podporovat.
Nicméně výchozí kódování pro české Widle bylo (pamatuji-li si to dobře) Windows-1280 (CP-1250), což byl charset pro střední Evropu. Zajímavé je, že Widle od NT 4 už unicode (prý) uměly, ale v XP byla stejně standardně používána Windows-1250...
-
Lael Ophir (neregistrovaný)
FAT ukládá dlouhé názvy vždy v Unicode UTF-16. Totéž NTFS.
Windows 9x používaly API s 8-bitovými chary, a názvev funkce končil na A (například TextOutA). Kódová stránka byla vždy ANSI podle jazykové mutace. Ve střední Evropě šlo o ANSI 1250. Vyjma toho měly Win9x pár funkcí pro práci s Unicode. A samozřejmě pro kompatibilitu se světem DOSu tam bylo i pár funkcí pracujících s OEM code page (u nás CP 852).
Ano, Microsoft Layer for Unicode, uvedený v roce 2001, umožňoval běh Unicode aplikací na Windows 9x. Do té doby bylo možné psát aplikaci pomocí maker, které expandovaly na ANSI verzi při kompilaci pro Win9x, a na Unicode verzi při kompilaci pro NT. Dost vývojářů to ale nepobralo :)Windows NT jsou Unicodové od první verze. Veškeré API používá 16-bitové wchary, jména funkcí končí na W (TextOutW). Pro zpětnou kompatibilitu s Windows 9x umí systém i "ANSI" funkce s A na konci, například TextOutA. Volání takových funkcí se překládá do Unicode, a výsledky volání se pak překládají zpátky do ANSI. Tu ANSI kódovou stránku lze nastavit, ve Windows XP stejně jako ve Windows 7. To asi bude to vaše "v XP byla stejně standardně používána Windows-1250". Ano, byla, ale jen pro ne-Unicodové programy.
Vyjma toho umí Windows NT samozřejmě zpracovat i jiné kódové stránky, pokud máte nainstalovanou jejich podporu (konverzní tabulky do/z Unicode). -
Pane Ponkrác, to děláte naschvál, nebo neumíte číst, nebo fakt o Linuxu nic nevíte?
"Na Windows není nic jiného než Unicode. Filesystém a názvy souborů jsou v Unicode. Veškeré vlastnosti, řetězce, hodnoty, vytáhnete z kernelu Windows v Unicode."
Žvást. Na Win, stejně jako na Linuxu je dostupných hned několik charsetových sad, např. CP, ISO, Unicode. Vzpomínám si, že v době, kdy na Linuxu bylo ještě XFree (X systém, dnes XOrg) proběhla Linuxovým světem zpráva , libc (!) má kompletní podporu pro unicode a pro XFree se dodělává. To už je drahnou dobu. Pane Ponkrác - libc!!!jen pro zajímavost na mém systému :
Út 25/09/2012 10:48 (~)> locale
LANG=cs_CZ.UTF-8
LANGUAGE=
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=Kdyby jste někdy alespoň jádro Linuxu configuroval, věděl by jste, že podpora znakových sad je nastavitelná přímo v něm. takže asi tak.
"Neměl byste ze sebe dělat vola.
Semafor je promiskuitní atomické počítadlo bez toho, aby znalo thready a jejich locky někdo vlastnil."
Aha. Dovolím si malí citát (Code Soucery, pokročilé programování v operačním systému Linux, Kp.4 Vlákna, SoftPress) :
... Bylo by lepší mít při vyprazdňování fronty mechanizmus pro zablokování vlákna do doby, než se začne zpracovávat další úloha.
Tímto prostředkem je semafor. Semafor je čítač, který můžete použít k synchronizaci více vláken. Podobně, jako v případě mutexů, operační systém Linux garantuje, že kontrola a modifikace se provádí bezpečně a nemůže dojít k souběhu...Takže asi tak.
"Přesně tak – doučte se."
To samé doporučuji i vám ;) -
„Žvást. Na Win, stejně jako na Linuxu je dostupných hned několik charsetových sad, např. CP, ISO, Unicode …“
Samozřejmě, ale to je otázka vnějšího API, že nabídne i další znakové sady.
„ Vzpomínám si, že v době, kdy na Linuxu bylo ještě XFree (X systém, dnes XOrg) proběhla Linuxovým světem zpráva , libc (!) má kompletní podporu pro unicode a pro XFree se dodělává. To už je drahnou dobu. Pane Ponkrác - libc!!!“
A to je zase to vnější API, ale kernel vnitřně v Unicode nepracuje.
O kousek výše jste se rozčiloval a dělal ze sebe chytrého kvůli puntičkářskému termínu. A zde klíďo píďo zaměňujete nativní kernel pracuijící s Unicode s nějakým vnějším API – máte v termínech hokej.
Kážete vodu a pijete víno.
„Tímto prostředkem je semafor. Semafor je čítač, který můžete použít k synchronizaci více vláken. Podobně, jako v případě mutexů, operační systém Linux garantuje, že kontrola a modifikace se provádí bezpečně a nemůže dojít k souběhu...“
Rozumíte vůbec tomu co píšete?
K synchronizaci více vláken můžete použít desítky synchronizačních objektů – od atomických strojových instrukcí přes synchronizační objekty nabízené operačním systémem.
Funkci WaitForMultipleObjects(), která je součástí WinAPI volanou s několik mutexy budete emulovat jen s horšími vlastnostmi.
Znovu, mutex někdo vlastní – na rozdíl od semaforu. To znamená, že má jiné vlastnosti.
-
"A to je zase to vnější API, ale kernel vnitřně v Unicode nepracuje.
O kousek výše jste se rozčiloval a dělal ze sebe chytrého kvůli puntičkářskému termínu. A zde klíďo píďo zaměňujete nativní kernel pracuijící s Unicode s nějakým vnějším API – máte v termínech hokej.
Kážete vodu a pijete víno."
No, myslím že vy máte chaos v mnohem více věcech. Například se čtením a asi chápáním - to je mnohem vážnější. Jednak jsem vám psal, že unicode jádra podporují a jednak jsem vám psal, že že unicode podporuje libc což znamená, že v podstatě každá aplikace s unicode může pracovat. Což je pro tuto diskuzi to podstatné. Tečka."Funkci WaitForMultipleObjects(), která je součástí WinAPI volanou s několik mutexy budete emulovat jen s horšími vlastnostmi."
Takže podle tohoto vašeho výplodu multiplatformnost znamená emulovat Widloidní API? LOL :-D Tak to jste mě dostal.
"Znovu, mutex někdo vlastní – na rozdíl od semaforu. To znamená, že má jiné vlastnosti."
To je v tuto chvíli krapet jedno. Mutex slouží k řešení problému souběhu vláken, stejně jako semafory - a o tomhle byla původní diskuze ;) -
Víte, pane Tiger, přečetl jsem si tady příspěvky z tomto vlákně na mnoha stranách. Mám pocit, že diskuse je s Vámi jenom ztrátou času.
Windows od kernelu a všech částí přirozeně pracuje v Unicode, konkrétně v UTF-16 kódování.
Linux o ničem takovém neví. Sem tam někdy interpretuje řetězce jako 8mibitové kódování, sem tam jako UTF-8. Rozhodně se – na rozdíl od Windows – nedá říci, že v Linuxu/unix je bezpečné kamkoli poslat Unicode řetězec s jistotou, že se nikde po cestě nerozbije, nebo nenarazí na část, která s Unicode neumí pracovat.
Windows totiž je plně – v každé své části – včetně low level kernelu – sjednocen na užívání Unicode v UTF-16. Jakékoli API je primárně s UTF-16 řetězci a jakékoli kódování se konvertuje do/z UTF-16.
To, že nerozumíte synchronizačním objektům jste myslím již dokázal dostatečně.
K řešení problémů souběhu vláken se používá leccos, například nepoužívat vlákna vůbec. To také řeší problém souběhu vláken. :-)
Přesto holinky a hodinky jsou rozdíl.
Synchronizační objekty necháme tedy na pokoji. Opravdu o nich mnoho nevíte.
-
Chlup (neregistrovaný)
Na multiplatformní aplikaci potřebujete
1) podstatně více know-how, než na win-only aplikaci (win-only zmiňuji proto, že win je hlavní herní platforma). Což někdo má a někdo nemá.
2) podstatně více času navíc, než nějakých 5-10%. 5-10% času navíc to bude možná v případech, kdy je vaše aplikace velmi vývojářsky nenáročná a nudná (což neznamená, nudná pro uživatele, aby se toho někdo nechytl) a současně v případě, kdy máte multiplatformní vývoj již dostatečně prošlapán (a to až do konce).Reálně ten čas pro vývoj multiplatformní aplikace, bude spíše v násobcích win-only vývoje. Beru vývojáře, kteří umí vyvíjet na jednotlivých platformách, ale ještě nedotáhli do konce multiplatformní projekt.
Čas na support raději odhadovat nebudu. A to přesto, že support hodíte na hlavu komunitě, tak pořád toho na vás zbyde dost.Multiplatformní vývoj má tu nevýhodu, že si dost prodlužujete tu dobu, kdy nemáte v ruce nic hotového, co byste někomu ukázali (jako demo, jako betu). A tahle doba bývá problém vždy u všech projektů a hodně projektů na tom skončilo. Multiplatformovým vývojem si zvětšujete velikost projektu s tím, že časem to přinese velké výhody - ale taky s tím, že možná právě tohle bude jeden ze střípků v mozaice, kvůli které ten projekt nedoděláte.
-
j (neregistrovaný)
1) neni pravda, je to spis presne naopak, normalne napsana aplikace multiplatformni bude - presne do okamziku, nez do ni nekdo zacne mastit nejake "super duper ..." vychytavky (a neni treba zustavat pouze u her).
2) taky neni pravda, pokud budu psat normalni aplikaci, a budu pouzivat standardni postupy, tak budu maximalne ladit chyby, ale kod jako takovy nikde nijak extra osetrovat nemusim.Realne vim minimalne o desitkach ruznych multiplatformnich aplikacich a je to vzdy jen o tom, ze se vyvojar nechova jako dobytek. Nekolikrat sem byl svedkem, ze vyvojar ani nezamyslel ze by aplikace fungovala na jinem systemu, ale protoze ji nenapsal jako dobytek, tak to stacilo prekombilovat, maximalne s nekolika drobnyma upravama.
-
Chlup (neregistrovaný)
Přemýšlím, jestli jste buď
-nikdy nenapsal žádnou multiplatformní aplikaci, nebo
-nikdy nenapsal ani žádnou větší aplikaci na jedné platformě(větší než školní projekt)A přikláním se k té druhé možnosti. Váš příspěvek mi bohužel nedává žádný smysl, abych na něj reagoval jinak.
