XP-Kurztest

[ComSubVie]

Original geschrieben von NodMot
COM ist der eigentliche Verursacher der sogenannten DLL-Hölle.

COM (Component Object Model) stellt eine Infrastruktur bereit, mit Hilfe derer Programme ihre Klassen und Schnittstellen anderen Programmen zur Verfügung stellen können. Dabei spielt immer ein Programm den Server und ein anderes den Client. Damit ein Programm oder eine DLL als Server fungieren kann, muß es und seine Klassen in der Registry unter einer sogenannten GUID (Weltweit eindeutige Nummer) registriert werden. Das Clientprogramm fragt dann immer explizit nach diesen Nummern, die sind da fest drin verdrahtet und das funktioniert auch immer, solange der Server richtig registriert ist und in der richtigen Version vorliegt. Nun stell Dir aber folgende Situation vor:

Programm A braucht DLL D in der Version 1.
Programm B braucht DLL D in der Version 2.
Beide Programme kommen mit der jeweils anderen Version nicht klar.

Welche Version soll man nun registrieren? COM kann nur eine Version registrieren, nicht zwei, also bist Du in der Zwickmühle.

HALT! Das Problem liegt bei den Komponenten. Wenn du eine DLL der Version irgendwas.x brauchst, so sind die Interfaces dieser Version bei allen Subversionen von irgendwas gleich - sofern der Programmierer weiß was er tut. Und verschiedene Major-Versionen der DLL kannst du sehr wohl registrieren. Mal abgesehen davon, das du die DLL nicht unbedingt mit deren GUID laden musst (wie das mit den windoof CreateInstance & Co Funktionen geht). Außerdem kannst du die DLL auch registrieren bevor du die verwendest, und nachher wieder die ursprüngliche. Das funktioniert zwar nicht so einfach, aber es geht.

Original geschrieben von NodMot
Außerdem verlangt dieses System vom Entwickler einiges an Vorsicht und verursacht ihm einige Probleme, da jede Änderung an einer bereits registrierten DLL die Einhaltung der sogenannten Binärkompatibilität erfordert, was mitunter an sich schon eine Hölle ist, weil man bestehende Schnittstellen nicht verändern darf. Brichst Du die Binärkompatibilität, mußt Du alle Programme ändern, die Deine DLL aufrufen, brichst Du sie nicht, bist Du verdammt eingeschränkt.

Ahja, das ist aber wohl klar. Und mal ehrlich, wie oft änderst du Schnittstellen einer Komponente? Doch wohl wenn dann nur in der Entwicklung, und da kriegst du sowieso stündlich eine neue. Bei einer release-Version ist für die Komplette Major-Version die Schnittstelle eingefroren. Und wer vor dem Programmieren überlegt, die Deklaration schreibt und so ist klar im Vorteil. Schließlich basiert die ganze Komponente auf den Schnittstellen und die zu modifizieren ist eine sch**** hackn.

Original geschrieben von NodMot
Dazu kommt noch das Problem, daß manche Software einfach System-DLLs überschreibt, die dann mit anderen Programmen (oder auch mal einer anderen Version des Systems) dann nicht mehr funktionieren.

Das alles nennt man DLL-Hölle und das löst COM nicht, sondern verursacht es (zumindest den ersten Teil, den ich beschrieb).

Soweit ich mich erinnern kann gabs DLLs auch schon vor COM - mit den gleichen Problemen. COM ist ein Schritt diese zu vermindern (zum Beispiel mit den GUIDs).

Original geschrieben von NodMot
IDL (IDL (Interface Definition Language) ist quasi ein Teil von COM (bzw. OLE)) steht für Interface und taugt nur dazu, mit Hilfe des dazugehörigen Compilers MIDL eine Typbibliothek für COM-Komponenten zu erstellen. die DLL-Hölle löst das aber gar nicht.
Zudem brauchen es eigentlich nur Leute, die COM-Komponenten mit C++ und MFC entwickeln (und wir entwickeln auf der Firma nunmal viel in VB) und die IDL hat ohne COM keine Existenzberechtigung, also wird sie auch nicht gegen die DLL-Hölle helfen.

HAAAAAAAAAALT! Also ich kann IDL auch für CORBA, C++ @Linux und Java verwenden.

Original geschrieben von NodMot
Seit W2K gibt es zwar ein paar Tricks, die da abhelfen können (man kann zum Beispiel Dateien überwachen lassen, so daß W2K das Überschreiben von System-DLLs verhindert und man kann mit einer leeren Datei Programm.exe.local im Verzeichnis von Programm A sagen, daß Programm A nicht die registrierte DLL D in der Version 2 sondern die lokale richtige DLL D in Version 1 nutzen soll), das ist aber eher Gefrickel und kein offizieller Weg, soweit ich weiß.

Nun, gibts für irgendwelche m$-probleme OFFIZIELLE wege? Nein, nur Pfusch.

Original geschrieben von NodMot
.net löst dieses Problem nun, indem es die zentrale Registrierung von Komponenten um das Feature der Versionierung erweitert. Das Programm A kann nun also seine DLL D in der Version 1 anfordern, kriegt die auch, während Programm B nach Version 2 fragt und diese ebenfalls von der zentralen Registrierung kriegt.

Hier stimm ich dir zu, das geht mit .net um einiges einfacher als mit COM. Aber durch kompetente Programmierung hast du diese Probleme sowieso nicht. Und unter Linux schon gar nicht

[NodMot]

@Com Subvie
Erstmal nur zum Thema "Schnittstellen einer Komponente" ändern, zum Rest später, weil mir momentan etwas die Zeit für eine komplette Antwort fehlt:

In unserer Firma wird fast ausschließlich firmeneigene Software und kaum Standardsoftware eingesetzt (wenn man mal von SAP für REWE absieht, ich spreche jetzt natürlich nicht von Textverarbeitung, etc.). Wir haben etwa 200 Programmierer, es gibt etwa 50 verschiedene DLLs, die wahrscheinlich von etwa 10 verschiedenen Teams entwickelt wurden und gewartet werden, darunter solche "Kernkomponenten", wie Security-Prüfungen, Datumsmodule, Schreibroutinen mit RPC-Aufrufen, etc. !

Ich weiß nicht, ob Du Dir vorstellen kannst, wie schnell sich DLLs ändern, weil Team A eine Weiterentwicklung benötigt, Team Z aber die Änderung nicht in Programm XY aus irgendwelchen Gründen nicht mitpflegen kann, gleichzeitig aber das Programm ABC des gleichen Teams ebenfalls die neue Version dieser Kernkomponente benötigt ?
Da ist nichts mit einer gleichzeitigen Anpassung aller betroffenen Systeme, vor allem nicht in einem Betrieb von über 30.000 Mitarbeitern, wo ich leider schonmal auf die Bedürfnisse von Direktor Gedöhnsrat reagieren muß, auch wenn die Planung anders aussah.

Zum Rest später etwas, möglicherweise erst morgen.

[ComSubVie]

Original geschrieben von NodMot
@Com Subvie
Erstmal nur zum Thema "Schnittstellen einer Komponente" ändern, zum Rest später, weil mir momentan etwas die Zeit für eine komplette Antwort fehlt:

In unserer Firma wird fast ausschließlich firmeneigene Software und kaum Standardsoftware eingesetzt (wenn man mal von SAP für REWE absieht, ich spreche jetzt natürlich nicht von Textverarbeitung, etc.). Wir haben etwa 200 Programmierer, es gibt etwa 50 verschiedene DLLs, die wahrscheinlich von etwa 10 verschiedenen Teams entwickelt wurden und gewartet werden, darunter solche "Kernkomponenten", wie Security-Prüfungen, Datumsmodule, Schreibroutinen mit RPC-Aufrufen, etc. !

Ich weiß nicht, ob Du Dir vorstellen kannst, wie schnell sich DLLs ändern, weil Team A eine Weiterentwicklung benötigt, Team Z aber die Änderung nicht in Programm XY aus irgendwelchen Gründen nicht mitpflegen kann, gleichzeitig aber das Programm ABC des gleichen Teams ebenfalls die neue Version dieser Kernkomponente benötigt ?
Da ist nichts mit einer gleichzeitigen Anpassung aller betroffenen Systeme, vor allem nicht in einem Betrieb von über 30.000 Mitarbeitern, wo ich leider schonmal auf die Bedürfnisse von Direktor Gedöhnsrat reagieren muß, auch wenn die Planung anders aussah.

Zum Rest später etwas, möglicherweise erst morgen.

klingt nach schlechter bis sehr schlechter organisation. naja, bei meinen maximal-10-leute teams hab ich die probleme nicht...

[NodMot]

Ich weiß ja nicht, in welcher Branche Du tätig bist, wie groß Deine Firma ist, etc. und kann deshalb nicht sagen, wie einfach Deine Organisation zu halten ist, oder nicht.

Aber ich kann Dir mal ein paar Beispiele von uns nennen. Z.B gab es zwei Kern-DLLs, die in allen Systemen gleich gehalten werden konnten.
Urplötzlich (vom einen auf den anderen Tag) wurde vom Vorstand des Mutterkonzerns bekanntgegeben, daß ein Unternehmen im europäischen Ausland aufgekauft wird, die Verhandlungen mehr oder minder abgeschlossen sind und bestimmte Systeme "direkt" nach Belgien übernommen werden sollen, um eine einheitliche Logistikstruktur zu bekommen. Dazu gehört nicht nur eine 1:1-Portierung, sondern eine Übersetzung ins englische, flämische und wallonische (OK, das hat nicht viel mit dem eigentlichen Problem zu tun, sondern soll nur mal verdeutlichen, was plötzlich organisatorisch umgeworfen werden kann) und es müssen aber auch Dinge geändert werden, weil nunmal bestimmte Sachen nach belgischem Recht ganz anders laufen.
Und da gehst Du weder zum Vorstandschef vom eigenen Konzern mit 30000 MA, noch zum Chef des Mutterkonzerns mit etwa 55000 MA und erzählst ihm etwas von Versionsproblemen von DLLs aufgrund dessen die geplante Firmenübernahme mit den angedachten Prozeßen erstmal etwas warten soll, um auch alle Syteme anpassen zu können. Sorry, aber der lacht mich aus und sagt, daß ihn solche Kleinigkeiten nicht interessieren, sondern nur, daß er seinen Jahresumsatz von 45 Milliarden Euro wie geplant um 10 % steigern will.
Ein weiteres "einigermaßen" aktuelles Beispiel war die Änderung des Rabattgesetzes in Deutschland, die sich zwar schon etwas längerfristig ankündigte, aber dennoch Planungen umwarf. Das ist etwas anderes, als vielleicht einen reinen Softwarebetrieb zu führen, in dem man abgeschlossene Produkte nach draußen verkauft.


Nun aber zu meiner eigentlichen Antwort, die ich noch geben wollte:

Ich gebe zu, daß COM die DLL-Hölle nicht allein verursacht hat. Ich gehe auch darin mit überein, daß wenn man in einer abgeschotteten Welt lebt, in der nur man ganz allein DLLs kompiliert, es für den Entwickler kein Problem darstellt, eine komplett neue Version seiner DLL zu registrieren.
Was aber, wenn andere auch auf die DLL zugreifen können sollen und zwar auf die aktuelle Version und ohne Entwicklungsaufwand (also ohne die neuen GUIDs verwenden zu müssen)? Und wenn noch dazu gefordert ist, daß auf zentral im System registrierte DLLs zugegriffen werden soll (es gibt ja gute Gründe für sowas) und eben kein Wildwuchs mit vielen Versionen in verschiedensten Anwendungsverzeichnissen getrieben werden soll ?
Wenn im Unternehmen nur mit VB programmiert werden soll (wo mir beim besten Willen kein trivialer Weg einfällt, eine DLL ohne GUID zu laden) ?
Wer meint, er könne seine Schnittstellen immer so universell planen, daß ihre Rückwärtskompatibilität niemals gebrochen werden müßte, der ist entweder ein Hellseher oder extrem naiv (bitte nicht persönlich nehmen, ich nehme einfach an, wir arbeiten nicht in den gleichen Welten). Und da kommt die (Er-)Lösung eben erst mit dem GAC-Konzept des .Net-Frameworks, das die Vorteile einer zentralen Registrierung von Komponenten mit der Möglichkeit einer Versionierung verbindet, was auch den Konfigurationsaufwand beträchtlich reduziert.
Wenn man die Perspektive nun noch etwas erweitert und bedenkt, daß moderne Unternehmenssoftware auch oft auf Komponenten von Drittanbietern angewiesen sein kann, kommt man eigentlich erst richtig ins Schwitzen, denn diese sind quasi immer zentral registriert und unterscheiden sich eben oft auch zwischen Versionen mit gleicher Schnittstelle in ihrem Verhalten. Warum sonst sollte der Drittanbieter die "Zwischenversion" herausgebracht haben? In einer idealen Welt würde man nun immer dafür sorgen, daß auf allen Maschinen, auf denen Software zu installieren ist, immer der genau gleiche Stand an Komponentenversionen herrscht. Genau darauf zielen natürlich auch unsere Konfigurationskonzepte ab.
Nun leben wir allerdings nicht in einer idealen Welt und so ist schon die relativ überschaubare Landschaft wie die unseres Unternehmens mit nur einigen hundert relevanten Servern (und einigen Tausend Citrix-Clients) auch bei den größten Anstrengungen nur sehr bedingt immer auf dem gleichen Stand zu halten. Der Standardfehler, der immer wieder auftritt, ist zum Beispiel der, daß die Datenzugriffskomponenten auf der Entwicklermaschine und der Produktionsmaschine sich in kleinen Details unterscheiden, was dann oft auch zu Programmabstürzen führt, die auf der Entwicklermaschine nicht passiert sind. Eine zentrale Registrierung mit Versionierung löst dieses Problem äußerst elegant, indem eben einfach immer alle theoretisch benötigten Versionen zentral abrufbar sind. Man kann sich als Entwickler darauf verlassen, daß die richtige Version da ist. Und wenn eine sehr neue Version dann eben doch noch nicht auf allen Produktionsmaschinen installiert ist, kann man sie sofort, ohne Entwicklungsaufwand und ohne Auswirkungen auf andere installierte Software einfach dazu installieren. Das geht mit COM nun beim besten Willen nicht, sondern höchstens ansatzweise mit dem Workaround mit der anwendung.exe.local - Datei, was aber erhöhten Konfigurationsaufwand nach sich zieht.

Um mal auf die Eingangsfrage zurückzukommen:
Die DLL-Hölle mag schon vor COM bestanden haben, ich kann allerdings nicht erkennen, inwiefern COM und die IDL dazu beigetragen haben sollten, sie zu lindern. Eher das Gegenteil ist der Fall.

Nun noch ein paar spezielle Aspekte:

Original geschrieben von ComSubVie
Mal abgesehen davon, das du die DLL nicht unbedingt mit deren GUID laden musst (wie das mit den windoof CreateInstance & Co Funktionen geht).

Das würde mich ja mal interessieren. Ich möchte mich hier nicht als COM-Experten aufschwingen, aber mit CoCreateInstance oder einer ClassFactory kann man meines Wissens keine Klasse aus einer DLL laden ohne CLSID (was ja auch eine GUID ist). Wenn Du einen anderen Weg meintest, würde mich dieser wirklich sehr interessieren!

Original geschrieben von ComSubVie
Außerdem kannst du die DLL auch registrieren bevor du die verwendest, und nachher wieder die ursprüngliche. Das funktioniert zwar nicht so einfach, aber es geht.

Das kann es ja wohl nicht sein. Denn was passiert bei einer solchen Lösung, wenn zur Laufzeit ein anderes Programm die ursprünglich registrierte DLL benötigt? Das ist riskantes Gefrickel.

Original geschrieben von ComSubVie
Also ich kann IDL auch für CORBA, C++ @Linux und Java verwenden.

C++ hatte ich ja bereits aufgeführt und dies sollte nun wirklich keine absolute Vollständigkeit beanspruchen, denn dafür kenne ich nunmal einfach nicht alle Programmiersprachen dieser Welt.

[ComSubVie]

Naja, ich gebe zu, ich sehe das mehr als "Einzelprojekt-Programmierer", da wird die DLL nur von einem Entwicklerteam benötigt, und von sonst niemandem. Und erst wenn die released ist - und damit die Schnittstellen eingefroren sind - können sich andere damit beschäftigen. Mal abgesehen davon das ich DLLs sowieso nicht mag

naja, wenn wir uns zum beispiel mal DirectX ansehen, so kann ich auch bei der aktuellen Version nachwievor die Schnittstellen der Version 3 verwenden. Soweit ist hier also binärkompatibilität gegeben. Ob ich alte und neue Interfaces gleichzeitig verwenden kann weiß ich allerdings nicht.

Ich hab gemeint, es gibt einen anderen Weg als CoCreateInstance auch, aber frag mich jetzt auf nicht wie das ging, ich hab das früher mal mit C verwendet, ob das in C++ noch immer geht? Keine Ahnung....