Zitat:
Original geschrieben von ComSubVie
wo hast du dieses Problem? Mit COM und IDL gibts das eigentlich schon laaaaaaaaaaange nicht mehr....
Ich meine das neue ist zwar recht .nett - aber mich hauts nicht vom hocker, ich bleib da lieber bei meinem c++ mit gcc
|
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.
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.
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).
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.
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ß.
.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.