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