Browse Prior Art Database

Integration von Software-Komponenten, die mit unterschiedlichen Compilern erstellt worden sind

IP.com Disclosure Number: IPCOM000129177D
Published in the IP.com Journal: Volume 5 Issue 10A (2005-10-25)
Included in the Prior Art Database: 2005-Oct-25
Document File: 2 page(s) / 394K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Bei der Software-Produktentwicklung werden in Abstaenden von wenigen Jahren neue Compiler eingesetzt. Um die Vorteile der neuen Technologie nutzen zu koennen, ist es mitunter erforderlich, sehr langwierige Aenderungen des bereits bestehenden Codes vorzunehmen. Es ist daher wirtschaftlich sinnvoll, nur neu erzeugten Code mit dem neuen Compiler und bestehenden Code mit den „alten“ Compilern zu uebersetzen. Die Anbindung neuer Komponenten an die alten Komponenten ist nur dann problemlos, wenn bereits beim Design der „alten“ Komponenten die vom ABI (Application Binary Interface) vorgeschriebenen Regeln eingehalten werden. Das ABI definiert, in welcher Sequenz die Bitmuster auf einem Speichermedium (z.B. Festplatte) abzulegen sind, damit ein mit dem alten Compiler erzeugtes Programm auch mit einem Programm, das mit einem anderen Programm erzeugt worden ist, noch eine lauffaehige Einheit bilden kann. Das erzeugte Bitmuster auf einem Speichermedium definiert das von einem Compiler erzeugte Interface fuer andere Programme. Unterscheidet sich das Bitmuster nicht von dem Bitmuster, das von einem anderen Compiler erzeugt worden ist, so ist das Programm binaerkompatibel, d.h. ABI konform. Bisher wurde das mit dem Einsatz neuer Compiler auftretende Problem (siehe oben) geloest, indem die gesamte Software auf den neuen Compiler umgestellt wurde. Mit dieser Vorgehensweise ist jedoch ein erheblicher Aufwand verbunden. Um dieses Problem auszuschliessen, ist entweder die ABI strikt einzuhalten, oder die Komponenten unterstuetzen ein sprachunabhaengiges Interface auf Basis von COM (Common Object Model). COM Interfaces sind automatisch mit dem Windows ABI kompatibel.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

S

Integration von Software-Komponenten, die mit unterschiedlichen Compilern erstellt worden sind

Idee: Alois Kraus, DE-Erlangen

Bei der Software-Produktentwicklung werden in Abstaenden von wenigen Jahren neue Compiler eingesetzt. Um die Vorteile der neuen Technologie nutzen zu koennen, ist es mitunter erforderlich, sehr langwierige Aenderungen des bereits bestehenden Codes vorzunehmen. Es ist daher wirtschaftlich sinnvoll, nur neu erzeugten Code mit dem neuen Compiler und bestehenden Code mit den "alten" Compilern zu uebersetzen. Die Anbindung neuer Komponenten an die alten Komponenten ist nur dann problemlos, wenn bereits beim Design der "alten" Komponenten die vom ABI (Application Binary Interface) vorgeschriebenen Regeln eingehalten werden. Das ABI definiert, in welcher Sequenz die Bitmuster auf einem Speichermedium (z.B. Festplatte) abzulegen sind, damit ein mit dem alten Compiler erzeugtes Programm auch mit einem Programm, das mit einem anderen Programm erzeugt worden ist, noch eine lauffaehige Einheit bilden kann. Das erzeugte Bitmuster auf einem Speichermedium definiert das von einem Compiler erzeugte Interface fuer andere Programme. Unterscheidet sich das Bitmuster nicht von dem Bitmuster, das von einem anderen Compiler erzeugt worden ist, so ist das Programm binaerkompatibel, d.h. ABI konform.

Bisher wurde das mit dem Einsatz neuer Compiler auftretende Problem (siehe oben) geloest, indem die gesamte Software auf den neuen Compiler umgestellt wurde. Mit dieser Vorgehensweise ist jedoch ein erheblicher Aufwand verbunden. Um dieses Problem auszuschliessen, ist entweder die ABI strikt einzuhalten, oder die Komponenten unterstuetzen ein sprachunabhaengiges Interface auf Basis von COM (Common Object Model). COM Interfaces sind automatisch mit dem Windows ABI kompatibel.

Zur Loesung dieses Problems wird daher die Entwicklung einer Bruecke, einer so genannten "Bridge" vorgeschlagen, welche die alte Komponente mit der neuen ABI kompatibel anbindet (siehe auch Kaestchen "Bridge Component" in Abbildung 1). Diese Anbindung kann beispielsweise mittels der COM Komponente erfolgen und hat den Vorteil, die alte Dll (siehe Kaestchen "Dll v1.0" in Abbildung 1) in einem anderen Prozess laufen lassen zu koennen. Im Fall eventuell auftretender Inkompatibilitaeten ist dies ein wertvolles Ausstattungsmerkmal.

Fuer ein Migrationsszenario ist nur punktuell eine Anbindung an die alten Komponenten erforderlic...