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]
35 Odpovědí
15851 Zhlédnutí