Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: klaxo 14. 10. 2016, 17:31:58
-
Mam obycajny lacny tablet za 150 € s x86 procesorom atom a mam vykonny mobil s arm procesorom, ten mobil vyzera byt na prvy pohlad vykonnejsi (papierovo aj je), ma viac pamate, lepsi display... ale ked prehravam trebars hd video tak ten mobil ma obcas problemy nieco ide plynule, ale niektore kodeky vôbec neprehra, niektore exotickejsie kodeky ako keby nestihal, ak mam otvorených viac stranok tak sa stava zs tiez nestiha. Pritom ten lacny tablet ide ako hodinky a vzdy prehra vsetko bez sekania a zvlada aj 10ky otvorenych tabov v browseri. Ako je to mozne? je arm naozaj tak slaba architektura? Sorry za neodborne polozenu otazku, nie som ITckar.
-
Mám Atom v tablebu s androidem a pocitově je to svižnější než podobná ARM konfigurace.
-
zaujímavé by bolo do tabletu pridať nejaké C6000 od Texas Instruments ktorý kombinuje v jednom čipe ARM aj DSP ;) a porovnať to s obvyklým tabletovým ARMa alebo x86.
-
Ano, aj serverove riesenia su take nejake, preto sa pouzivaju multicpu zariadenia.
-
ale ked prehravam trebars hd video tak ten mobil ma obcas problemy nieco ide plynule, ale niektore kodeky vôbec neprehra, niektore exotickejsie kodeky ako keby nestihal,... Ako je to mozne? je arm naozaj tak slaba architektura? Sorry za neodborne polozenu otazku, nie som ITckar.
mozno by stalo za to pozistovat ci vam to prehrava priamo cpu alebo nejaky dedikovany cip... ja mam obstarozni Prestigio tablet a cpu(arm) samo o sebe ma dost problem prehravat videa - zerie baterku a hreje... na videa tam ma taky medialny cip, ktory s tym nema problem a vklude prehraje hociake rozlisenie s pomerne malou spotrebou a takmer nehreje (v porovnani s cpu) - pokial sa teda jedna o podporovany kodek... ak je kodek exotickejsi - typicky anime => smola a mozem prehrat len softverovo => na cpu, ak je vyssie rozlisenie tak sekanie, vypadavanie zvuku a pod...
-
podla mna je to vec softu - dnes je pre vyrobcu vyhodnejsie pouzit vykony cpu ako platit dobreho programatora
(svojho casu som mal mp3 s 8 bitakom - atmega8 a dekodoval to externy svab - procak mal aj tak co robit - fat32 s 1k ram + stream rychlostou okolo 1Mbit/s nie je sranda pre AVR, ale slo to)
moj nazor je ze pre vseobecnu mnozinu aplikacii mozu byt arm aj x86 rovnako vykonne, lisit sa budu pre specificke ulohy; avsak- ARM je ovela cistejsie navrhnuty ^_^ - nemusi bojovat s predkami typu 8080, 8086
-
To záleží, co je to za ARM. Aby se to dalo rozumně srovnávat, musel by to být 64bitový ARMv8 (neboli AArch64). 32bitový ARMv7 nemusí obsahovat instrukce NEON SIMD, které výrazně zrychlují přehrávání videa, což způsobuje, že mnoho aplikací ty výkonné instrukce nepoužívá, a 32bitová délka instrukcí dost zpomaluje práci s inty (musí se buď pracovat s bitovými maskami či posuny nebo se musí používat odkazy třeba pomocí MOV32, což snadno může vést k výpadkům cache). 64bitový ARM umí pracovat se 32bitovými hodnotami přímo a NEON má vždy, a tak bude výrazně rychlejší, srovnatelně s x86.
-
avsak- ARM je ovela cistejsie navrhnuty ^_^ - nemusi bojovat s predkami typu 8080, 8086
S 8086 bojovat nemusí. Jenže máte původní ARM, potom Thumb a Thumb-2, Jazelle a ThumbEE, a 64-bitový ARMv8, což jsou odlišné instrukční sady. Jinými slovy boji s historií se nevyhnete, pokud chcete zpětnou kompatibilitu. A tu trh chce, u Intelu i u ARMu.
-
S 8086 bojovat nemusí. Jenže máte původní ARM, potom Thumb a Thumb-2, Jazelle a ThumbEE, a 64-bitový ARMv8, což jsou odlišné instrukční sady. Jinými slovy boji s historií se nevyhnete, pokud chcete zpětnou kompatibilitu. A tu trh chce, u Intelu i u ARMu.
Nechce. Kdyby Intel zahodil podporu 8086 16-bit, tak si toho nikdo nevšimne (kromě zavaděče OS). Kdyby zahodil 32-bit, tak v některých sektorech si toho nevšimne nikdo, v některých (Windows legacy) část korporátních zákazníků. Kdyby zahodili instrukce AAD a podobné, které každá berou 1/256 prostoru či více, nevšimne si toho vůbec nikdo.
-
Nechce. Kdyby Intel zahodil podporu 8086 16-bit, tak si toho nikdo nevšimne (kromě zavaděče OS). Kdyby zahodil 32-bit, tak v některých sektorech si toho nevšimne nikdo, v některých (Windows legacy) část korporátních zákazníků. Kdyby zahodili instrukce AAD a podobné, které každá berou 1/256 prostoru či více, nevšimne si toho vůbec nikdo.
Zpětná kompatibilita je důležitá, proto si jí s sebou táhne Intel i ARM.
16-bitový režim dodnes používají embedded systémy, plus spousta historických aplikací typu malých národních účetnictví (za všechny třeba produkty mrp.cz).
http://arstechnica.com/information-technology/2014/07/it-may-be-barely-an-operating-system-but-dos-still-matters-to-some-people/
32-bitový režim je nutný pro podporu 16-bitového kódu, protože ze 64-bitového OS na Intelu 16-bitový kód nepustíte. Dále je tu spousta slabého HW s omezenou RAM, kde se 32-bitové OS dodnes používají. Navíc je tu spousta SW, který je k dispozici jen v 32-bitové verzi. Zkuste zákazníkovi vysvětlit, že mu na jeho novém HW nepůjde starší verze Oracle RDBMS, Lotus Domino/Notes, nebo jeho ekonomický systém; klidně na Linuxu. Kdo dělá business, nevystačí s aplikacemi z distra.
Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.
-
Zpětná kompatibilita je důležitá, proto si jí s sebou táhne Intel i ARM.
16-bitový režim dodnes používají embedded systémy, plus spousta historických aplikací typu malých národních účetnictví (za všechny třeba produkty mrp.cz).
http://arstechnica.com/information-technology/2014/07/it-may-be-barely-an-operating-system-but-dos-still-matters-to-some-people/
32-bitový režim je nutný pro podporu 16-bitového kódu, protože ze 64-bitového OS na Intelu 16-bitový kód nepustíte. Dále je tu spousta slabého HW s omezenou RAM, kde se 32-bitové OS dodnes používají. Navíc je tu spousta SW, který je k dispozici jen v 32-bitové verzi. Zkuste zákazníkovi vysvětlit, že mu na jeho novém HW nepůjde starší verze Oracle RDBMS, Lotus Domino/Notes, nebo jeho ekonomický systém; klidně na Linuxu. Kdo dělá business, nevystačí s aplikacemi z distra.
Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.
Kdo jste a co jste udelal s Laelem Ophirem?
Tento text dava smysl a neni to blaboliva sracka. To neni LO ani trochu podobne.
-
Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.
Tohle platí jenom u widláků, linuxáci mají repozitáře a v nich soft zkompilovaný přímo pro jejich aktuální hardware, na kterém běží zvolená distribuce. Takže v Linuxu funguje kompatibilita, zpětně i dopředně, na úrovni zdrojových kódů, což byl důvod vzniku FORTRANu...
-
16-bitový režim dodnes používají embedded systémy, plus spousta historických aplikací typu malých národních účetnictví (za všechny třeba produkty mrp.cz).
http://arstechnica.com/information-technology/2014/07/it-may-be-barely-an-operating-system-but-dos-still-matters-to-some-people/
32-bitový režim je nutný pro podporu 16-bitového kódu, protože ze 64-bitového OS na Intelu 16-bitový kód nepustíte.
mrp.cz má jenom 16-bitové produkty verze??? Jak se teda pustí na většině nových systémů, jak je napsáno v druhém odstavci? Produkt, který by byl dneska 16-bitový, by na trhu neměl naprosto žádnou šanci.
Dále je tu spousta slabého HW s omezenou RAM, kde se 32-bitové OS dodnes používají. Navíc je tu spousta SW, který je k dispozici jen v 32-bitové verzi. Zkuste zákazníkovi vysvětlit, že mu na jeho novém HW nepůjde starší verze Oracle RDBMS, Lotus Domino/Notes, nebo jeho ekonomický systém; klidně na Linuxu. Kdo dělá business, nevystačí s aplikacemi z distra.
Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.
Proto jsem psal, že odstranění 32 bitů by si část korporátních zákazníků všimla. Zrovna Oracle ale není úplně dobrý příklad, neboť ten se dá zrovna snadno pustit v 64-bitové variantě a je to pro klienty zcela transparentní. Nehledě na to, že provozovat jakýkoli starý software je bezpečnostní riziko...
IA64 dojel na úplně jiné věci, podporu od relevantních software společností měl dostatečnou (bavíme se o server side), primárním důvodem byla kombinace mizerného výkonu a vysoké ceny. Sice možná mohla porazit (v té době už) dinosaury typu Alpha, PA-RISC a další, ale utopická architektura nakonec podlehla ač zastaralé, tak přesto flexibilní x86_64. Nicméně, i kdyby tomu tak bylo, IA64 byla novinka ve světě x86, zatímco o 15 let později je x86 legacy ostrůvek ve světě x86_64, ARM a dalších.
-
Tak 16 bit. režim by se snad dal emulovat, ne? A případný pokles výkonu kvůli emulaci by pro současné silné procesory neměl být problém. Konec konců emulátory jako Dosbox dávno existují.
-
32-bitový režim je nutný pro podporu 16-bitového kódu, protože ze 64-bitového OS na Intelu 16-bitový kód nepustíte. Dále je tu spousta slabého HW s omezenou RAM, kde se 32-bitové OS dodnes používají. Navíc je tu spousta SW, který je k dispozici jen v 32-bitové verzi. Zkuste zákazníkovi vysvětlit, že mu na jeho novém HW nepůjde starší verze Oracle RDBMS, Lotus Domino/Notes, nebo jeho ekonomický systém; klidně na Linuxu. Kdo dělá business, nevystačí s aplikacemi z distra.
Pokud nedáte zákazníkovi zpětnou kompatibilitu, nebo jen budete starý SW běžet pomaleji, budete jen opakovat to co Intel zjistil u platformy IA64: zpětná kompatibilita je zásadní.
U Itania to Intel podcenil, jenže pro tu zpětnou kompatibilitu vůbec nepotřebujete hardwarovou podporu (tedy pokud tam nepotřebujete spustit Windows, protože nativně spustit nejdou :) ). Zkuste si najít, co dělá libhoudini, hlavní důvod, proč vůbec existují androidí tablety a telefony s Atomy. Nebo si najděte, jak řešil MacOS X přechod z PowerPC na x86-64. Nakonec i systémy na Itaniu dneska umí spouštět aplikace pro x86, jenže než se to naučili, AMD už prodávalo vlastní 64bitový systém, který to uměl taky a byl výrazně levnější.
-
pochybujem, že kompatibilita so 16/32 bit architektúrou je až taký veľký problém, že by to malo viditeľný vplyv na parametre dnešných CPU. Pokiaľ sa nemýlim zo 64bit módu (teda t 64 bit OS) už 16 bitový kód aj tak nejde spustiť, iba ak emuláciou a ten 32 bitový je veľmi príbuzný 64bitovému, len má skrátené registre a je ich menej + možno pár detailov navyše.
To, že by sa dali lepšie využiť niektoré krátke inštrukčné kódy je nepodstatné dnes je dosť pamäte a o pár % menší kód nič zásadné nerieši.
-
mrp.cz má jenom 16-bitové produkty verze??? Jak se teda pustí na většině nových systémů, jak je napsáno v druhém odstavci? Produkt, který by byl dneska 16-bitový, by na trhu neměl naprosto žádnou šanci.
mrp.cz a řada dalších nabízí SW psaný ještě pro DOS, a to za velmi malé peníze. Upozorňují na to, že běží jen pod 32-bitovými Windows. Přesně z toho důvodu, že na 64-bitovém OS nespustíte 16-bitový kód.
Mimochodem dalším podobným příkladem mohou být pokladny založené na embedded DOSu. Pokud si je firma koupila před 10 lety za levný peníz, a pořád fungují, tak není jediný důvod do toho sahat.
Proto jsem psal, že odstranění 32 bitů by si část korporátních zákazníků všimla. Zrovna Oracle ale není úplně dobrý příklad, neboť ten se dá zrovna snadno pustit v 64-bitové variantě a je to pro klienty zcela transparentní. Nehledě na to, že provozovat jakýkoli starý software je bezpečnostní riziko...
SW nerezaví, a interní firemní systémy mohou být (a často jsou) velmi staré.
IA64 dojel na úplně jiné věci, podporu od relevantních software společností měl dostatečnou (bavíme se o server side), primárním důvodem byla kombinace mizerného výkonu a vysoké ceny. Sice možná mohla porazit (v té době už) dinosaury typu Alpha, PA-RISC a další, ale utopická architektura nakonec podlehla ač zastaralé, tak přesto flexibilní x86_64. Nicméně, i kdyby tomu tak bylo, IA64 byla novinka ve světě x86, zatímco o 15 let později je x86 legacy ostrůvek ve světě x86_64, ARM a dalších.
Ano IA64, mohla porazit dinosaury typu Alpha, PA-RISC. Jenže ti dinosauři byli tak jako tak na odchodu, a pro IA64 nebylo dost SW. Je fajn mít OS, MS SQL Server a Oracle, ale firma potřebuje daleko víc SW. Bylo možné použít běžný x86 SW, ale emulace x86 neměla nic moc výkon, takže jste měl zatraceně drahou IA64 a efektivně na ní jel s výkonem nižším než na x86. Společnost AMD pak IA64 zabila svými procesory s x64. Ten samý CPU bylo možné použít na desktopu i serveru, pro 32-bit i 64-bit OS, a starý 32-bitový kód fungoval beze ztráty výkonu. To že x64 je z technického hlediska fialový hnus pak nikoho netrápilo, hlavně že fungovala zpětná kompatibilita.
-
U Itania to Intel podcenil, jenže pro tu zpětnou kompatibilitu vůbec nepotřebujete hardwarovou podporu (tedy pokud tam nepotřebujete spustit Windows, protože nativně spustit nejdou :) ). Zkuste si najít, co dělá libhoudini, hlavní důvod, proč vůbec existují androidí tablety a telefony s Atomy. Nebo si najděte, jak řešil MacOS X přechod z PowerPC na x86-64. Nakonec i systémy na Itaniu dneska umí spouštět aplikace pro x86, jenže než se to naučili, AMD už prodávalo vlastní 64bitový systém, který to uměl taky a byl výrazně levnější.
Itanium mělo od první verze "HW" kompatibilitu s x86 (pár x86 instrukcí vyžadovalo SW podporu). Přechod do x86 módu se prováděl zvláštní instrukcí, a například obsluha interruptu byla vždy v IA64 režimu, takže nebylo možné použít x86 OS (leda by tomu "pomohl" firmware, což se pokud vím nestalo). Bohužel výkon x86 kódu byl na IA64 dost tragický, údajně v nejlepším případě ekvivalent 100MHz Pentia (v době kdy se prodávaly 1.1GHz Pentia). Novější verze OS pro Itanium používaly SW emulaci x86, která nabízela lepší výkon, a novější verzi Itania tu "HW" kompatibilitu s x86 odstranily. Bohužel ta emulace přišla pozdě, a ani tak nebyl výkon nic moc.
Kód pro ARM puštěný na Intelu přes libhoudini má cca třetinový výkon. PPC kód na Mac Rosetta měl cca třetinový až poloviční výkon. V případě Macu se přechod z PPC na Intel povedl, ovšem jen z toho důvodu, že zákazníci neměli moc na vybranou :). Kdyby v AMD nepřišli s x86-64, tak by Intel s Itaniem možná také uspěl.
-
Lulane, fialovej hnus bylo predevsim Itanium, proto pro nej nikdo nic nevyvijel. Protoze to nejen ze nebylo binarne kompatibilni, ono to vyzadovalo i uplne jiny postupy programovani, a to bylo to, co to zabilo.
AMD naopak prislo s naprosto genialnim navrhem, kdy jen proste a jednoduse pridali rozsireny 64bit instrukce, ktery se ale chovaly presne stejne, jako ty 32bit. Takze u spousty aplikaci proste stacilo kompilatoru rict "udelej mi to jako 64bit" ... a FUNGOVALO to.
-
Lulane, fialovej hnus bylo predevsim Itanium, proto pro nej nikdo nic nevyvijel. Protoze to nejen ze nebylo binarne kompatibilni, ono to vyzadovalo i uplne jiny postupy programovani, a to bylo to, co to zabilo.
AMD naopak prislo s naprosto genialnim navrhem, kdy jen proste a jednoduse pridali rozsireny 64bit instrukce, ktery se ale chovaly presne stejne, jako ty 32bit. Takze u spousty aplikaci proste stacilo kompilatoru rict "udelej mi to jako 64bit" ... a FUNGOVALO to.
Naprostá většina software se nepíše v assembleru a jiné přístupy to nevyžadovalo. Vyžadovalo to kompilátor, který umí generovat optimalizované VLIW. Což v době vydání Itania byl trochu problém. O pět let později již kompilátory neměly problém generovat složité instrukce, ať již VLIW, SIMD či dokonce paralelizované, ale to už bylo pozdě. K tomu se přidala cena. Je hezké mít 128+128 registrů, 8 ALU a 4 FPU, ale takový procesor nejde udělat levný. AMD se spokojilo se 16+8 registry, jedním ALU a jedním FPU.
-
Kód pro ARM puštěný na Intelu přes libhoudini má cca třetinový výkon. PPC kód na Mac Rosetta měl cca třetinový až poloviční výkon. V případě Macu se přechod z PPC na Intel povedl, ovšem jen z toho důvodu, že zákazníci neměli moc na vybranou :). Kdyby v AMD nepřišli s x86-64, tak by Intel s Itaniem možná také uspěl.
S libhoudini mám jinou zkušenost. Ono asi záleží, co překládá a kde. Když jsem to zkoušel na video a audio kodecích, které používají NEON SIMD, na Lollipop (kde je AOT kompilátor), tak to běželo srovnatelně rychle jako na podobně drahém telefonu s ARMem.
-
Lulane, fialovej hnus bylo predevsim Itanium, proto pro nej nikdo nic nevyvijel. Protoze to nejen ze nebylo binarne kompatibilni,
Jak jsem už psal, na Itaniu je možné provozovat x86 kód (ale ne kompletní x86 OS, protože například obsluha interruptu jede vždy v EPIC). Itanium má instrukci pro přepnutí do režimu x86, a pak HW dekodér překládá x86 instrukce na nativní EPIC. Problém je v tom, že to bylo pomalé. Zdroj: Intel Itanium Architecture Software developer's manual, chapter 6.
http://www.intel.com/content/www/us/en/processors/itanium/itanium-architecture-vol-1-2-3-4-reference-set-manual.html
ono to vyzadovalo i uplne jiny postupy programovani, a to bylo to, co to zabilo
Hlavně to vyžadovalo úplně jiný kompilátor, který v době uvedení Itania nebyl na dostatečné úrovni, jak už tu někdo psal.
AMD naopak prislo s naprosto genialnim navrhem, kdy jen proste a jednoduse pridali rozsireny 64bit instrukce, ktery se ale chovaly presne stejne, jako ty 32bit.
Ten "geniální" návrh je přesně to co Michal Chovanec dříve v téhle diskusi kritizoval jako zátěž x86-64 architektury zbytečnou historií, což vede k nižší efektivitě. Návrh x86-64 je hlavně "geniální" prasárna. Jenže bylo možné používat
nový 64-bit i stávající 32-bit OS, a bylo možné se stejným výkonem běžet nový 64-bit i starý 32-bit kód. Proto vyhrálo prasácké řešení.
Takze u spousty aplikaci proste stacilo kompilatoru rict "udelej mi to jako 64bit" ... a FUNGOVALO to.
Možná u aplikací typu Hello World. U rozsáhlejších projektů ani náhodou.
-
S libhoudini mám jinou zkušenost. Ono asi záleží, co překládá a kde. Když jsem to zkoušel na video a audio kodecích, které používají NEON SIMD, na Lollipop (kde je AOT kompilátor), tak to běželo srovnatelně rychle jako na podobně drahém telefonu s ARMem.
Zkuste na Intelu pustit nějaký benchmark, a použít pak ten samý benchmark ve verzi pro ARM, ovšem puštěný přes libhoudini. Emulace prostě stojí nějaké zdroje.
https://regmedia.co.uk/2014/04/30/watt_benchmarks_large.jpg
-
ono to vyzadovalo i uplne jiny postupy programovani, a to bylo to, co to zabilo
Hlavně to vyžadovalo úplně jiný kompilátor, který v době uvedení Itania nebyl na dostatečné úrovni, jak už tu někdo psal.
Kompilátor nedokáže zachránit utopickou architekturu, když program využívá nějaký typ operací, ale jedna VLIW instrukce jich vyžaduje víc. Myšlenka dobrá, ale v reálném světě ve většině aplikací nepoužitelná.
Takze u spousty aplikaci proste stacilo kompilatoru rict "udelej mi to jako 64bit" ... a FUNGOVALO to.
Možná u aplikací typu Hello World. U rozsáhlejších projektů ani náhodou.
To platí pouze pro Windows world, kde je většina proměnných WORD či DWORD a maďarština se používá na každém řádku. Pro POSIX, kde lidi používají platform independent typy size_t, off_t, uintptr_t, time_t a další, portace velkých projektů byla většinou opravdu jen o zkompilování a spuštění (namátkou KDE, Emacs, ViM, OpenOffice). Firefox je nejspíš lehce jiný případ pouze kvůli závislosti na 3rd party plugins.
-
To platí pouze pro Windows world, kde je většina proměnných WORD či DWORD a maďarština se používá na každém řádku. Pro POSIX, kde lidi používají platform independent typy size_t, off_t, uintptr_t, time_t a další, portace velkých projektů byla většinou opravdu jen o zkompilování a spuštění (namátkou KDE, Emacs, ViM, OpenOffice). Firefox je nejspíš lehce jiný případ pouze kvůli závislosti na 3rd party plugins.
Aha. Tak se koukneme na GLib (základ GTK), Qt a Win32. Kupodivu definují vlastní typy: quint32, guint32, DWORD, ...
https://developer.gnome.org/glib/stable/glib-Basic-Types.html
http://doc.qt.io/qt-4.8/qtglobal.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx
Pojďme se tedy podívat, jak se namátkou OpenOffice "jen zkompiloval a přeložil". Jan Holešovský k tomu měl prezentaci. V té popisuje obvyklé problémy, dvě větve projektu vytvořené za účelem portu, to že ty větvě nefungují, a popisuje že po spoustě práce, kterou nad věcí odvedli, je výsledek nadále nestabilní a nelze ho ani demonstrovat. Sice je to stav k roku 2005, ale ilustruje to, že "jen zkompilovat a přeložit" je nesmysl.
http://artax.karlin.mff.cuni.cz/~kendy/ooo/OOoCon-2005/img5.html
-
To platí pouze pro Windows world, kde je většina proměnných WORD či DWORD a maďarština se používá na každém řádku. Pro POSIX, kde lidi používají platform independent typy size_t, off_t, uintptr_t, time_t a další, portace velkých projektů byla většinou opravdu jen o zkompilování a spuštění (namátkou KDE, Emacs, ViM, OpenOffice). Firefox je nejspíš lehce jiný případ pouze kvůli závislosti na 3rd party plugins.
Aha. Tak se koukneme na GLib (základ GTK), Qt a Win32. Kupodivu definují vlastní typy: quint32, guint32, DWORD, ...
https://developer.gnome.org/glib/stable/glib-Basic-Types.html
http://doc.qt.io/qt-4.8/qtglobal.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx
To je naprosto v pořádku, že tam ty typy jsou. Jsou místa, kde je třeba mít pevně daný typ, například při serializaci. Problém Windows world a jejich developerů je, že je používají naprosto špatně, i v místech, kde mají použít "logický" typedef (off_t, size_t atd). Například DWORD WINAPI GetFileSize(_In_ HANDLE hFile, _Out_opt_ LPDWORD lpFileSizeHigh);, zatímco POSIX má jednoduše off_t. A chování té funkce je tedy lahůdka, nepoužívám ostrá slova, ale tohle musel designovat opravdu blbec posedlý DWORDy: Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success.
Díky za link na Windows Data Types (http://Windows Data Types), to je taky dílo:
DWORDLONG - A 64-bit unsigned integer. The range is 0 through 18446744073709551615 decimal.
DWORD32 - A 32-bit unsigned integer.
DWORD64 - A 64-bit unsigned integer.
DWORD byl původně double word, resp 32-bit uint, což je jako platform independent samo o sobě brain-damaged, ale vem to peklo. Tady z pevně daného typu udělají suffixem jiný typ přesto, že logické jméno reflektuje ten starý pevný 32-bit. To byl jen příklad, v rámci toho linku se dají najít mnoho dalších neméně "povedených"
Qt a Glib oproti tomu mají jasné a výstižné názvy, ze kterých je jasně viditelný smysl, použití a velikost.
-
GetFIieSize
Zřejmě jim v MS již dávno došlo, že práce s touto API není tak úplně přímočará, a tak s WIndows XP přišla GetFileSizeEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364957(v=vs.85).aspx), kterou již přímočaře použít lze.
IIRC tu GetFIleSIze byla s námi ještě ve velmi dávných dobách (Windows 9x, možná dříve?), kde se jako souborové systémy používaly FAT12/16/32. Vzhledem k tamějšímu omezení na velikost souborů obvykle nebylo potřeba vyplňovat druhý parametr. Ale je to jen taková domněnka, proč taková skladba parametrů.
-
Zřejmě jim v MS již dávno došlo, že práce s touto API není tak úplně přímočará, a tak s WIndows XP přišla GetFileSizeEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364957(v=vs.85).aspx), kterou již přímočaře použít lze.
Tak s přímočarostí bych byl hodně opatrný. V porovnání s POSIX off_t lseek(int fd, off_t offset, int method) je i tahle pokročilá Windows varianta pořád peklo - jako parametr bere LARGE_INTEGER, což je union, který má v sobě strukturu se dvěma DWORD (low, high) a druhý člen je quadPart, který skutečně obsahuje to číslo. Pominu-li opět platform independence (o big-endian v Microsoftu nejspíš nikdy neslyšeli), tak práce s tímhle, pokud chcu skutečně operovat s offsetem, sčítat ho apod., dostáváme se někde na úroveň mezi assembler a C.
A to je na tom nejhorší - na to, že tahle funkce vznikla v 2000+, tak už bych čekal, že se z toho poučí, nebo aspoň ze 30 let staršího POSIXu. Ale kdepak, to se soudruzi zamysleli, udělali to jinak, ale téměř stejně blbě. V tom musela být nějaká politika, aby náhodou nepřiznali, že to 30 let před nima někdo vymyslel stokrát líp... Mimochodem těma dwOffsetLow, dwOffsetHigh jsou ty "moderní" WINAPI Ex funkce protkané všude...
-
To je naprosto v pořádku, že tam ty typy jsou. Jsou místa, kde je třeba mít pevně daný typ, například při serializaci. Problém Windows world a jejich developerů je, že je používají naprosto špatně, i v místech, kde mají použít "logický" typedef (off_t, size_t atd). Například DWORD WINAPI GetFileSize(_In_ HANDLE hFile, _Out_opt_ LPDWORD lpFileSizeHigh);, zatímco POSIX má jednoduše off_t. A chování té funkce je tedy lahůdka, nepoužívám ostrá slova, ale tohle musel designovat opravdu blbec posedlý DWORDy: Note that if the return value is INVALID_FILE_SIZE (0xffffffff), an application must call GetLastError to determine whether the function has succeeded or failed. The reason the function may appear to fail when it has not is that lpFileSizeHigh could be non-NULL or the file size could be 0xffffffff. In this case, GetLastError will return NO_ERROR (0) upon success.
Jak už tu padlo, GetFileSize je staré API, a bylo před mnoha lety nahrazeno pomocí GetFileSizeEx. Nakonec je to uvedené i v popisu funkce.
Dále zjištění velikosti souboru na Unixech probíhá pomocí volání stat nebo stat64, výsledek inteligentně dostanete struktuře, a ta obsahuje member, který má typ off_t nebo off64_t. No a jestli vám přijde dobrý nápad mít na file offset vlastní datový typ off_t, který je "signed integer... no narrower than int", a pak ještě off64_t, který je také signed a také no narrower than int, ale navíc je na 32-bitových systémech 64-bitový... tak k tomu asi nemám komentář. BTW o kvalitě dokumentace glibc vs MSDN asi nemá smysl psát.
Díky za link na Windows Data Types (http://Windows Data Types), to je taky dílo:
DWORDLONG - A 64-bit unsigned integer. The range is 0 through 18446744073709551615 decimal.
DWORD32 - A 32-bit unsigned integer.
DWORD64 - A 64-bit unsigned integer.
DWORD byl původně double word, resp 32-bit uint, což je jako platform independent samo o sobě brain-damaged, ale vem to peklo. Tady z pevně daného typu udělají suffixem jiný typ přesto, že logické jméno reflektuje ten starý pevný 32-bit. To byl jen příklad, v rámci toho linku se dají najít mnoho dalších neméně "povedených"
Qt a Glib oproti tomu mají jasné a výstižné názvy, ze kterých je jasně viditelný smysl, použití a velikost.
DWORD byl původně double word, a postupem času se z něj stal unsigned int, by default 32-bitový. To že se z něj sufixem 64 udělá 64-bitový typ mi připadá poměrně logické. Jinak použití typů bez definované šířky (jak je nešťastným zvykem v definici jazyka C) považuji za příčinu většiny problémů v portování na 64-bitové platformy.
Qt a Glib jsou poměrně high level knihovny. Win32 je API z roku 1993, a když srovnáte .NET Framework nebo WinRT s Qt nebo Glib, tak na tom MS není s datovými typy špatně. Hlavně je na tom ale velmi dobře s funkcionalitou a dokumentací.
Mimochodem u těch platform independent typů (size_t, off_t, uintptr_t, time_t a další) jste viděl, že portaci velkých projektů nijak nepomohly, a například u OpenOffice to zdaleka nebylo "jen o zkompilování a spuštění". Uvědomte si, že řada starších aplikací například serializuje objekty do binárního blobu, a je tak dělaná mimo jiné většina souborových formátů uvedených před XML. Všechny tyhle věci se vám při změně datových typů zhroutí jako domeček z karet. OO sice používal souborový formát založený na XML, ale kupodivu při portu na x86-64 dospěl i do stádia, kdy byl schopný číst binární dokumenty MS Office, ale ne OOXML (vizte prezentaci).
-
Tak s přímočarostí bych byl hodně opatrný. V porovnání s POSIX off_t lseek(int fd, off_t offset, int method) je i tahle pokročilá Windows varianta pořád peklo - jako parametr bere LARGE_INTEGER, což je union, který má v sobě strukturu se dvěma DWORD (low, high) a druhý člen je quadPart, který skutečně obsahuje to číslo. Pominu-li opět platform independence (o big-endian v Microsoftu nejspíš nikdy neslyšeli), tak práce s tímhle, pokud chcu skutečně operovat s offsetem, sčítat ho apod., dostáváme se někde na úroveň mezi assembler a C.
A to je na tom nejhorší - na to, že tahle funkce vznikla v 2000+, tak už bych čekal, že se z toho poučí, nebo aspoň ze 30 let staršího POSIXu. Ale kdepak, to se soudruzi zamysleli, udělali to jinak, ale téměř stejně blbě. V tom musela být nějaká politika, aby náhodou nepřiznali, že to 30 let před nima někdo vymyslel stokrát líp... Mimochodem těma dwOffsetLow, dwOffsetHigh jsou ty "moderní" WINAPI Ex funkce protkané všude...
Předpokládám že víte jak funguje v jazyku C union, takže je vám jasné, že QuadPart a LowPart+HighPart jsou jen různé pohledy na tu samou hodnotu. Pokud compiler umí 64-bitové integery, s klidem používejte QuadPart, a nevidím důvod, proč by se vám s ní počítalo špatně. Pokud je neumí, pořád máte možnost použít LowPart+HighPart.
O big-endian v MS slyšeli, ale asi také vědí, že naprostá většina dnešního HW je bi-endian: ARM 3+, PowerPC, Alpha, SPARC V9+, MIPS, PA-RISC, SuperH SH-4, IA-64 aka Itanium.
Když to shrnu, tak obhajujete platform-independent datové typy, u kterých není daná jejich šířka ani endianness. Jak vidíte u portu OpenOffice na 64-bitovou architekturu, v praxi to portabilitě nepomáhá. Co je ale horší: v takovém prostředí nemáte stabilní ABI. Windows staví na stabilním ABI, ale ve světě POSIXu nic takového neexistuje.
-
výsledek inteligentně dostanete struktuře - dle jazyka tvého kmene odhaduji, že jsi nějaký tatar, který dnes vyfasoval pohotovost.
-
Předpokládám že víte jak funguje v jazyku C union, takže je vám jasné, že QuadPart a LowPart+HighPart jsou jen různé pohledy na tu samou hodnotu. Pokud compiler umí 64-bitové integery, s klidem používejte QuadPart, a nevidím důvod, proč by se vám s ní počítalo špatně. Pokud je neumí, pořád máte možnost použít LowPart+HighPart.
O big-endian v MS slyšeli, ale asi také vědí, že naprostá většina dnešního HW je bi-endian: ARM 3+, PowerPC, Alpha, SPARC V9+, MIPS, PA-RISC, SuperH SH-4, IA-64 aka Itanium.
Když to shrnu, tak obhajujete platform-independent datové typy, u kterých není daná jejich šířka ani endianness. Jak vidíte u portu OpenOffice na 64-bitovou architekturu, v praxi to portabilitě nepomáhá. Co je ale horší: v takovém prostředí nemáte stabilní ABI. Windows staví na stabilním ABI, ale ve světě POSIXu nic takového neexistuje.
Tohle s ABI vůbec nesouvisí, na Linuxu bez problému pustím 20 let starou binárku. A ohledně QuadPart, LowPart a HighPart - jakože budu psat ifdefy (ehm, není to dokonalé, kdyby MyStruct byla moc velká, ale nechtěl jsem to komplikovat moc):
#ifdef VERY_OLD_COMPILER
DWORD originalLowPart = myFileOffset.split.LowPart;
myFileOffset.split.LowPart = myFileOffset.split.LowPart+sizeof(MyStruct);
if (myFileOffset.split.LowPart < originalLowPart)
myFileOffset.split.HighPart++;
#else
myFileOffse.QuadPart = largeIntegerUsedForGainingTheOffset.QuadPart+sizeof(MyStruct);
#endif
// vs Posix:
myFileOffset += sizeof(MyStruct);
Opravdu takhle vypadají Microsoftí programy??
DWORD byl původně double word, a postupem času se z něj stal unsigned int, by default 32-bitový. To že se z něj sufixem 64 udělá 64-bitový typ mi připadá poměrně logické. Jinak použití typů bez definované šířky (jak je nešťastným zvykem v definici jazyka C) považuji za příčinu většiny problémů v portování na 64-bitové platformy.
WORD znamená slovo, tedy základní element, se kterým se procesoru "dobře" pracuje. Už tohle má Microsoft blbě, neboť WORD chápe jako 16 bitů, což není pravda pro drtivou většinu dnešních architektur. DWORD je double word, tedy dvakrát slovo, v řeči Microsoftu tedy 32 bitů. Stejně jako existuje jediný kilogram, žádný lehký kilogram a těžký kilogram, nelze DWORD (double word) přiřadit malý double word a velký double word. Jak to udělat správně - opět viz POSIX, glib, Qt (*int64* - je to celočíselné a má to 64 bitů - jednoduché, čitelné, přehledné, nematoucí).
A k té druhé části, to asi nebylo myšleno vážně, že? Naopak flexibilní definice typu podle jeho úlohy tu portabilitu usnaďnuje. Zároveň taky výrazně zvedá čitelnost kódu, což opět vyřeší potenciální chyby při portaci - když vidím off_t, size_t, vidím i ten význam a je-li to špatně, jsem schopen rychle říct proč. Když vidím DWORD, nevidím smysl té proměnné, nevidím nic. A přehlednost kódu je jeden z klíčů pro efektivitu vývoje a v důsledku jeho kvalitu a cenu. Takže původně banda školáků dokázala postavit něco, co konkurovalo balíku MS, za který půlka světa platí řádově tisíce korun.
Mimochodem u těch platform independent typů (size_t, off_t, uintptr_t, time_t a další) jste viděl, že portaci velkých projektů nijak nepomohly, a například u OpenOffice to zdaleka nebylo "jen o zkompilování a spuštění". Uvědomte si, že řada starších aplikací například serializuje objekty do binárního blobu, a je tak dělaná mimo jiné většina souborových formátů uvedených před XML.
Opět je to o tom, aby se ty typy používaly správně, je samozřejmě nesmysl serializovat size_t. Tohle zjevně na některých místech u OpenOffice podcenili, proto ty problémy. Ale nejspíš nebyly tak velké, když je malý tým dokázal vyřešit poměrně rychle. Což, když například porovnám jediný port MS Office na Mac, kde aplikace vypadá výrazně jinak a velká část funkcionality chybí, tak zjevně ani velká banda pracujících na MS Office ty pozůstatky nedokázala vyřešit ani za 10 let.
Když to shrnu, viděl jsem spoustu projektů, které byly postavené na logických (POSIX) typech a portace byla jen o překompilování. Neviděl jsem ___jediný___ projekt postavený na WINAPI, u kterého by byl port bez problémový - naopak jsem jich viděl dost, které skončily jako "give it up". To asi o něčem vypovídá, což?
-
Tohle s ABI vůbec nesouvisí, na Linuxu bez problému pustím 20 let starou binárku.
S ABI to samozřejmě souvisí. Jak myslíte že bude fungovat aplikace, která volá open(), a čeká že ji libc vrátí 32-bitový int, když libc vrátí místo toho 64-bitový? Pochopitelně z tohoto z milionu dalších důvodů nebude fungovat. Jistě, můžete aplikaci přeložit tak, aby používala 64-bitový int. Jenže pak nejde o kompatibilitu na úrovni ABI.
Další věc: různé platformy používají různý alignment. Například 32-bitový int se typicky ukládá na adresu, která je násobkem čtyř, a pokud tato podmínka není splněna, tak buď výrazně propadne výkon, nebo dokonce dojde k výjimce. Při změně šířky datových typů tedy nedojde jen k prostému zvětšení struktur. Mezi jednotlivé members často complier nasází padding, a může se to lišit podle compileru (například gcc vs MSVC vs icc). To pak může vést k tomu, že když uložíte strukturu na disk na jedné 32-bit platformě, tak ji na jiné nepřečtete, protože se liší allignment/padding. A podobně to může být problém (se kterým se naštěstí většinou počítá) i v rámci jednoho systému, pokud přeložíte aplikaci jiným compilerem.
A ohledně QuadPart, LowPart a HighPart - jakože budu psat ifdefy (ehm, není to dokonalé, kdyby MyStruct byla moc velká, ale nechtěl jsem to komplikovat moc):
...
Opravdu takhle vypadají Microsoftí programy??
Proč byste psal ifdefy? Když píšete pro 64-bitovou platformu, máte compiler s podporou 64-bitových integerů. Ovšem pokud píšete 32-bitový kód, který má používat 64-bitové integery, může se to hodit. Předpokládám že vrstva WoW32 (tedy běh 32-bitových programů na 64-bitových Windows) je interně řešená právě takhle.
Mimochodem proč byste to na Windows řešil tak jak jste ukazoval, a ne takhle?
myFileOffset.QuadPart += sizeof(MyStruct);
WORD znamená slovo, tedy základní element, se kterým se procesoru "dobře" pracuje. Už tohle má Microsoft blbě, neboť WORD chápe jako 16 bitů, což není pravda pro drtivou většinu dnešních architektur. DWORD je double word, tedy dvakrát slovo, v řeči Microsoftu tedy 32 bitů. Stejně jako existuje jediný kilogram, žádný lehký kilogram a těžký kilogram, nelze DWORD (double word) přiřadit malý double word a velký double word. Jak to udělat správně - opět viz POSIX, glib, Qt (*int64* - je to celočíselné a má to 64 bitů - jednoduché, čitelné, přehledné, nematoucí).
To je historická zátěž. Nicméně kdo je schopný si zapamatovat quint32, měl by zvládnout i DWORD32. Pokud jde o glib a Qt, tak jsem vám říkal, že .NET Framework i WinRT mají datové typy dost podobné.
A k té druhé části, to asi nebylo myšleno vážně, že? Naopak flexibilní definice typu podle jeho úlohy tu portabilitu usnaďnuje. Zároveň taky výrazně zvedá čitelnost kódu, což opět vyřeší potenciální chyby při portaci - když vidím off_t, size_t, vidím i ten význam a je-li to špatně, jsem schopen rychle říct proč. Když vidím DWORD, nevidím smysl té proměnné, nevidím nic. A přehlednost kódu je jeden z klíčů pro efektivitu vývoje a v důsledku jeho kvalitu a cenu. Takže původně banda školáků dokázala postavit něco, co konkurovalo balíku MS, za který půlka světa platí řádově tisíce korun.
Původně školáci jsou snad dneska skoro všichni :). OpenOffice byl koupen společností Sun Microsystems, a následně dlouhé roky platila jeho vývoj. Náklady šly v přepočtu do miliard korun. Komunita se starala primárně o údržbu dokumentace. Když nevyšla strategie kde se Sun, Oracle a IBM snažili vnutit OpenOffice zákonem (získat ISO standard na formát OOXML, lobbovat za přijetí zákonů vyžadujících používání standardizovaných formátů a zabránění konkurenci v získání standardu), tak Sun i ostatní náklady prostě odepsali.
Ohledně toho jak použití off_t údajně zvyšuje portabilitu: na prvním místě máte i off64_t. Na druhém místě nevidím moc důvodů zrovna pro file offset mít vlastní datový typ. Vždyť je to integer. Naopak pokud otevřu soubor, tak chápu že výsledek by měl být typu handle (ve Win32 HANDLE), protože tam to opravdu má význam. Samozřejmě v libc funkce open() vratí int, asi byste ho mohl s něčím sečíst :/
Opět je to o tom, aby se ty typy používaly správně, je samozřejmě nesmysl serializovat size_t. Tohle zjevně na některých místech u OpenOffice podcenili, proto ty problémy. Ale nejspíš nebyly tak velké, když je malý tým dokázal vyřešit poměrně rychle. Což, když například porovnám jediný port MS Office na Mac, kde aplikace vypadá výrazně jinak a velká část funkcionality chybí, tak zjevně ani velká banda pracujících na MS Office ty pozůstatky nedokázala vyřešit ani za 10 let.
Souhlas, správné používání typů je základ. Jenže v době kdy se psal originální kód řada autorů stavěla na nesprávných předpokladech o šířce jednotlivých typů, v dané situaci na tom prostě nezáleželo. Jak vidíte, tak se jim to vymstí ať už používají Win32, nebo libc. Mimochodem pro lepší portabilitu se *vždy* doporučuje používat typy s danou šíří, například uint32 nebo DWORD, namísto těch generických jako int.
Port MS Office na Mac není problém z hlediska datových typů. Je to problém z hlediska API, protože se aplikaci napsanou pro Win32 portujete na MacOS Cocoa.
To že MS Office for Mac vypadá jinak než na Windows je záměr. Uživatelé na Macu mají ohledně UI výrazně odlišná očekávání, ať už jde o nativní widgety, nebo třeba o umístění menu. Je potom otázkou pro portující tým, kde look-and-feel přizpůsobí cílové platformě, a kde nechá ten původní.
Chybějící funkcionalita je důsledkem toho, že MS nechtěl moc investovat do portu. Zákazníků na Macu bylo málo, ta platforma prakticky umírala. Navíc Apple přešel z API Classic na Carbon + Cocoa, takže bylo potřeba portovat znovu. Plus byla v MS řada lidí, kteří se ptali, proč by měl MS podporovat konkurenta, a navrhovali úplně MS Office for Mac stopnout.
Když to shrnu, viděl jsem spoustu projektů, které byly postavené na logických (POSIX) typech a portace byla jen o překompilování. Neviděl jsem ___jediný___ projekt postavený na WINAPI, u kterého by byl port bez problémový - naopak jsem jich viděl dost, které skončily jako "give it up". To asi o něčem vypovídá, což?
Jistě, hello world opravdu přeložíte pro 64-bitovou platformu, a bude to bez problému. Cokoliv složitějšího dopadne tak jako OpenOffice: bude s tím spousta práce. Mimochodem představte si, jak portujete na 64-bit platformu třeba DB engine. Jde o obrovskou hromadu datových struktur, změní se vám veškeré formáty i protokoly. Port OpenOffice je proti tomu nuda. [/code]
-
Původně školáci jsou snad dneska skoro všichni :). OpenOffice byl koupen společností Sun Microsystems, a následně dlouhé roky platila jeho vývoj. Náklady šly v přepočtu do miliard korun. Komunita se starala primárně o údržbu dokumentace. Když nevyšla strategie kde se Sun, Oracle a IBM snažili vnutit OpenOffice zákonem (získat ISO standard na formát OOXML, lobbovat za přijetí zákonů vyžadujících používání standardizovaných formátů a zabránění konkurenci v získání standardu), tak Sun i ostatní náklady prostě odepsali.
Ta diskuse tady je zajímavá, ale bohužel jste se pustil do politiky a to co jste vypustil je opravdu strašné.
Samozřejmě, že zákon by měl ve veřejné správě vyžadovat používání veřejných standardizovaných formátů a to, že tomu tak dlouho nebylo (a někde ještě stále není) je výsledkem silného lobingu Microsoftu a případných dalších firem. Masové přijímání nestandardizovaných a proprietárních dokumentů je totéž, jako by stát nařídil, že na státní cesty mohou jen auta výrobce xyz a ostatní tam nesmí. To by vám připadlo normální?
-
Původně školáci jsou snad dneska skoro všichni (https://forum.root.cz/Smileys/default/smiley.gif). OpenOffice byl koupen společností Sun Microsystems, a následně dlouhé roky platila jeho vývoj. Náklady šly v přepočtu do miliard korun. Komunita se starala primárně o údržbu dokumentace. Když nevyšla strategie kde se Sun, Oracle a IBM snažili vnutit OpenOffice zákonem (získat ISO standard na formát OOXML, lobbovat za přijetí zákonů vyžadujících používání standardizovaných formátů a zabránění konkurenci v získání standardu), tak Sun i ostatní náklady prostě odepsali.
No, máte, jako vždy, naprostou pravdu. Jen OpenOffice.org nebyly koupeny fy. Sun Microsystems, ale uvolněny koncem roku 2001 jako základ balíku StarOffice pod licencemi LGPL a SISSL. Je pravda, že balík StarOffice fy. Sun Microsystems koupila. Jako balík Starwriter od fy. StarDivision.
Dále nechápu souvislost s OOXML, a fy. Sun, Oracle a IBM, když OOXML je formát Microsoftu. Je pravda, že při schvalování OOXML Microsoft fakticky ochromil organizaci ISO tím, že si zaplatil nové členy ISO organizace. Tito nový členové po schválení nebyli aktivní a ISO byla nějakou dobu neusnášeníschopná. A diskreditovaná.
Vypadá to, že z úspory času při psaní Vám vypadávají celé části textu a Váš text tím ztratil faktické souvislosti.
-
No, máte, jako vždy, naprostou pravdu. Jen OpenOffice.org nebyly koupeny fy. Sun Microsystems, ale uvolněny koncem roku 2001 jako základ balíku StarOffice pod licencemi LGPL a SISSL. Je pravda, že balík StarOffice fy. Sun Microsystems koupila. Jako balík Starwriter od fy. StarDivision.
Nepsal jsem o OpenOffice.org. Psal jsem, že OpenOffice koupila společnost Sun. Ano, Sun koupil produkt ze kterého vychází OpenOffice, nikoliv produkt jménem OpenOffice, ale neviděl jsem důvod jít do detailu. Když chcete detaily, tak OpenOffice vychází ze StarOffice, a teprve ten vychází ze StarWriteru. Autorem StarOffice byla společnost StarDivision, kterou Sun koupil v roce 1999, a jejíž zaměstnanci se dál starali o rozvoj balíku. K uvolnění zdrojáku došlo v roce 2000.
Dále nechápu souvislost s OOXML, a fy. Sun, Oracle a IBM, když OOXML je formát Microsoftu. Je pravda, že při schvalování OOXML Microsoft fakticky ochromil organizaci ISO tím, že si zaplatil nové členy ISO organizace. Tito nový členové po schválení nebyli aktivní a ISO byla nějakou dobu neusnášeníschopná. A diskreditovaná.
Pardon, mělo tam být ODF.
Je pravda, že se Sunu nepodařilo proniknout na trh office produktů, takže vytvořil strategii kdy alespoň poškodí konkurenta (Microsoft) tím, že OpenOffice uvolní zdarma. Sun pak nabízel placenou verzi pod značkou StarOffice s podporou. Protože o produkt nikdo nestál, protlačil Sun interní formát svého produktu standardizací u ISO (a o necelých 9(!) let později dokonce standardizoval takové "drobnosti", jako jsou vzorce ve spreadsheetech), a lobboval za přijetí zákonů, které měly donutit státní správu používat (nepoužitelný) ISO standard. Tím pádem bylo zásadní, aby konkurenční formát OOXML od MS nezískal ISO standard. Sun nad tím strávil obrovské množství úsilí. Šlo o bezprecedentní přenesení konkurenčního boje na půdu ISO. MS reagoval způsobem, který byl nejspíš také bezprecedentní. Výsledkem je poškození ISO a celého standardizačního procesu. Naštěstí špinavá taktika Sunu (a jeho přítel v IBM a Oracle) nevyšla. Po ISO standardizaci OOXML se vývoj OpenOffice prakticky zastavil, a Sun dojel mimo jiné na své utrácení za projekty bez finanční návratnosti (OpenOffice, MySQL). V IBM odepsali Lotus Symphony, a v Oraclu po nákupu Sunu odepsali OpenOffice.