Autor Téma: Nezávislost dcu  (Přečteno 557 krát)

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2693
  • Karma: 104
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Nezávislost dcu
« kdy: 13-12-2019, 18:54:23 »
Škoda, že totéž nefunguje na úrovni .dcu, i kdyby to nemělo být neomezené, ale jen "dokud se nezmění interface".

Jen pro upřesnění i v souvislosti s patchem z jiného vlákna.

Co já vím, tak to tak funguje. Jde o to, že s každou velkou verzí se mění interface (něco přibude atd). Pokud se jedná o update, tak co vím z komunikace s členy R&D, mají nástroj, který proběhne dcu třeba z 10.3.2, udělá hash rozhraní, které je unikátní a při změně rozhraní nesouhlasí. Následně se udělá podobně z verze 10.3.3 a hashe musí souhlasit. Pak je zaručeno, že externí knihovny nebudou protestovat a komponenty 3rd stran (resp. jejich dcu vytvořené proti 10.3.2) budou fungovat. Že se asi někdy stalo, že to neklaplo, bylo, že provedená úprava byla mimo (např. se přidat class constructor) a ten nezměnil daný hash. Může se změnit třeba jen pár unit, to je v podstatě vždy, ale v důsledku to je zbytečné řešit, takže se to zneplatní vše.

Mezi verzemi je to složité a jak říkám nestojí to za to, ale třeba dcu D2006 a D2007 jsou kompatibilní, přičemž rozšíření VCL při zachování rozhraní bylo v tomto případě děláno opravdu špinavými triky za pomocí class helperů - stačí se v D2007 podívat třeba Form.GlassFrame a jak je to hackováno pomocí právě class helperu, který to opravdu hardcore bastlí přes FPixelsPerInch, což v následující verzi bylo upraveno na normální proměnnou, protože dcu kompatibilita D2007 a D2009 opravdu nešla

Embarcadero MVP - Czech republic

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1510
  • Karma: 37
    • Pepak.net
Re:Nezávislost dcu
« Odpověď #1 kdy: 13-12-2019, 22:23:45 »
Mezi verzemi je to složité
Vždycky si pomyslím na .obj.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2693
  • Karma: 104
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Nezávislost dcu
« Odpověď #2 kdy: 13-12-2019, 23:40:59 »
Mezi verzemi je to složité
Vždycky si pomyslím na .obj.

Zajímavé a co si pomyslíš? Podle mne je .obj více formátů, a jestli myslíš podformát 32bit OMF, tak podle mne ez nějakého .h nebo importního souboru z toho dostaneš jméno funkce plus, že to vzniklo z toho a toho souboru. Proto ty různé dekorování jména funkcí, podle kterých se dají uhádnout parametry. Ale třeba se pletu, ale momentálně mi to přijde jako pohrobek z 80 let. A to jsem si teď zběžně pročítal doc a nástrojem jsem listoval obsah .obj.

Embarcadero MVP - Czech republic

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1510
  • Karma: 37
    • Pepak.net
Re:Nezávislost dcu
« Odpověď #3 kdy: 14-12-2019, 08:32:21 »
Pomyslím si, že tady máme příklad, kdy je v zásadě možné kombinovat soubory nejen z různých verzí kompilátoru, ale přímo z různých kompilátorů. V praxi to úplně stoprocentně nefunguje právě z důvodu, že jsou různé dekorační konvence, ale to je čistě záležitost toho, naučit linker různé konvence a/nebo je standardizovat. Pak by skutečně fungovala kompatibilita i napříč kompilátory. Ve stávajícím řešení nám funguje aspoň kompatibilita napříč různými verzemi téhož kompilátoru.

32bit formát OMF je samozřejmě relikt minulosti, ale formát COFF je stále živý. Mimo jiné ho dodržují všechny Windowsové PE soubory.

Soubor .h ani importní soubor k .obj vůbec není potřeba. Ty jsou potřeba k tomu, abys mohl vytvořit další .obj, ale pokud už .obj máš, tak jsou soběstačné a je možné je linkovat bez čehokoliv dalšího.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2904
  • Karma: 135
    • Verze Delphi: D2007, XE3, DX10
Re:Nezávislost dcu
« Odpověď #4 kdy: 14-12-2019, 19:37:29 »
ale formát COFF je stále živý.
A co RTTI? AFAIK, tak obsahuje jen tabulku symbolu ev. s typem ev. name-pool a cisla radku pro debugger. To pro introspekci asi stacit nebude, ne?

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1510
  • Karma: 37
    • Pepak.net
Re:Nezávislost dcu
« Odpověď #5 kdy: 14-12-2019, 22:23:10 »
To by se samozřejmě dalo nacpat do speciální sekce, v tom vůbec nevidím problém.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2693
  • Karma: 104
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Nezávislost dcu
« Odpověď #6 kdy: 16-12-2019, 10:53:42 »
Tak jsem ji přečetl aspon https://en.wikipedia.org/wiki/COFF, kde se píše že jediná reálná aplikace je Windows PE (tak to v tom případě je opravdu bída, vzhledem k tomu, jaké jsou problémy s linkováním DLL) a že pro reálné jazyky je nepoužitelný pokud se neporuší různé definice (pokud to chápu dobře tak cokoliv s objekty by byl hack, problémy s laděním atd). Doteď jsem si navíc myslel, že OMF je vylepšením. Teoreticky by se to možná dalo použít místo DCU se všemi úpravami (ale zda ty další sekce co se musí nejsou závislé na verzi už nevím), ale zapomínáš na jednu věc: použití DCU řádově urychluje kompilaci. Samozřejmě paralelní kompilace atd. to dnes už trošku řeší.

Prostě si myslím, že nemáš pravdu.

Embarcadero MVP - Czech republic

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2693
  • Karma: 104
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Nezávislost dcu
« Odpověď #7 kdy: 16-12-2019, 10:57:34 »
Cite: Note that COFF was not capable of representing line numbers or debugging symbols for included source as with header files rendering the COFF debugging information virtually useless without incompatible extensions.
Embarcadero MVP - Czech republic

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 2904
  • Karma: 135
    • Verze Delphi: D2007, XE3, DX10
Re:Nezávislost dcu
« Odpověď #8 kdy: 16-12-2019, 11:26:54 »
Cite: Note that COFF was not capable of representing line numbers or debugging symbols for included source as with header files
Tak v tom bych zase tak velkou prekazku nevidel: mam dojem, ze ani Delphi neumel dat bkpt do kodu, ktery byl do zdrojovky zaclenen pomoci {$I}. U tech header filu jako *.h, tak je vetsinou nepotrebujes, protoze tam se jedna o "import" symbolu, ktere jsou nekde jinde definovany jako public a exportovany - tam je pak potrebujes - ale je otazka, co vsechno v tech headerech mas a jak presne je ta jejich definice udelana.

Ale porad to budou jen nejake osizene informace pro debugger tj. breakpoint a inspekce promenne.


Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1510
  • Karma: 37
    • Pepak.net
Re:Nezávislost dcu
« Odpověď #9 kdy: 16-12-2019, 13:02:59 »
Tak jsem ji přečetl aspon https://en.wikipedia.org/wiki/COFF, kde se píše že jediná reálná aplikace je Windows PE (tak to v tom případě je opravdu bída, vzhledem k tomu, jaké jsou problémy s linkováním DLL) a že pro reálné jazyky je nepoužitelný pokud se neporuší různé definice (pokud to chápu dobře tak cokoliv s objekty by byl hack, problémy s laděním atd).
"Jediná reálná aplikace" jsou všechny PE soubory, všechny ELF soubory, všechny objektové soubory a knihovny ve všech Visual Studiích, všechny objektové soubory a všechny knihovny v GCC a tak. Dokonce i C++ Builder přešel na COFF, i když jen v 64 bitech. Překvapivě v tom fugují i objekty, i když samozřejmě pod kvalifikátorem "pokud se neporuší různé definice" si může kdokoliv představit cokoliv, včetně toho, že variabilita, kterou COFF ze své definice zavádí, je vlastně špatná. "Problémy s linkováním DLL" s COFF formátem nesouvisí vůbec. Takže asi tolik ke kvalitě informací z Wikipedie.

Citace
Doteď jsem si navíc myslel, že OMF je vylepšením.
Musím se přiznat, že výhody OMF formátu mi dodnes zůstávají utajeny. Jedinou evidentní věcí je, že pokud použiju OMF, jsem vázaný na svět Borlandu, zatímco všichni ostatní používají COFF.

Citace
zapomínáš na jednu věc: použití DCU řádově urychluje kompilaci.
Nevidím sice, proč by to mělo být specifikum DCU, ale dejme tomu. To by byla jasná výhoda. Ale jestli stojí za tu nevýhodu, že DCU je striktně svázané s konkrétní verzí, to si nejsem jistý.

Citace
Prostě si myslím, že nemáš pravdu.
V čem? V tom, že existují objektové formáty, které jsou nezávislé na verzi kompilátoru? Nebo v tom, že by se mi líbilo, kdyby DCU měly stejnou vlastnost?

Jako je to ryze akademická diskuse, protože Delphi samozřejmě tohle nikdy neudělají, ale to nic nemění na tom, že by se mi líbilo, kdyby to udělaly.

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2693
  • Karma: 104
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Nezávislost dcu
« Odpověď #10 kdy: 16-12-2019, 14:07:59 »
Citace
zapomínáš na jednu věc: použití DCU řádově urychluje kompilaci.
Nevidím sice, proč by to mělo být specifikum DCU, ale dejme tomu. To by byla jasná výhoda. Ale jestli stojí za tu nevýhodu, že DCU je striktně svázané s konkrétní verzí, to si nejsem jistý.

Citace
Prostě si myslím, že nemáš pravdu.
V čem? V tom, že existují objektové formáty, které jsou nezávislé na verzi kompilátoru? Nebo v tom, že by se mi líbilo, kdyby DCU měly stejnou vlastnost?

Jako je to ryze akademická diskuse, protože Delphi samozřejmě tohle nikdy neudělají, ale to nic nemění na tom, že by se mi líbilo, kdyby to udělaly.

ELF není COFF.

Jinak u toho visual studia mne nikdy nenapadlo, ze formát lib je interně archive obj souborů ve formátu COFF, ok dik.

DCU je rychlejší, nedokáži to teď najít, ale co si pamatuji, tak obsahuje i nějaké interní tabulky nebo stavy kompilátoru, takže je kompilátor může rychle načíst zpět a nemusí provádět nějaké vyhledávání, a podle toho dokáže určit zda je nutné ten a ten soubor kompilovat, protože se nějaký z dependency unitů změnit a zda to má vliv na daný soubor (změna rozhraní). Ale jak řík PF, HOSIP.
Embarcadero MVP - Czech republic

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1510
  • Karma: 37
    • Pepak.net
Re:Nezávislost dcu
« Odpověď #11 kdy: 16-12-2019, 14:56:24 »
Hmm, měl jsem za to, že ELF je COFF, ale podle všeho asi spíš není. I stand corrected.