100%ige Sprachunabhängigkeit ist ein Wunsch, der seit dem Zeitpunkt existiert, seit dem es mehr als eine Programmiersprache gibt. Compilerbauer für VC++, Delphi, Smalltalk usw. hatten immer wieder verschiedene Vorstellungen davon, wie ein String, ein Stack-Frame oder ein Objekt im Speicher abgebildet werden sollte. Es gab mehrere Versuche, die teilweise auch erfolgreich waren, solche Probleme in den Griff zu bekommen.
Dynamic Link Librarys sind dynamische Bibliotheken. Von mehr als einem Programm benötigter Code kann ausgelagert und von den Programmen zur Laufzeit eingebunden werden. Somit wird Speicherplatz gespart. Ist ein Update des Codes nötig, so muss der Code nur in der DLL und nicht in jedem einzelnen Programm geändert werden.
DLLs definieren Vorgaben für Funktionsbibliotheken und Aufrufkonventionen. Sie können Sourcecode, Daten und Resourcen enthalten und können in jeder Programmiersprache benutzt bzw. erstellt werden, die DLLs unterstützt. Das Problem der Typsystem-Inkompatibilität wurde nur teilweise gelöst. Auch die teilweise unterstützte Objektorientierung war ein großeß Mängel. Durch diese Problematik brachten DLLs nur eine gewisse Abhilfe.
Als DLL Hölle wird in der Windows Welt ein Problem genannt, welches auftritt, wenn mehrere Programme eine DLL mit dem gleichen Namen aber in unterschiedlichen Versionen benötigen. Das Problem kann behoben werden, in dem die benötigte Version der DLL im Programmverzeichnis abgelegt wird. Dadurch wird aber der Vorteil der Speicherplatzersparnis wieder zunichte gemacht.
Überschreibt ein Programm eine bereits installierte DLL mit einer anderen Version, so kann ein zuvor installiertes Programm eventuell nicht mehr richtig funktionieren.
Eine grundsätzliche Lösung war das Component Object Model, welches auf der DLL Technik aufsetzt und diese mit DDE [Dynamic Data Exchange (Protokoll für den Datenaustausch zwischen verschiedenen Anwendungsprogrammen)] kombiniert. COM versprach die Interoperabilität beliebiger Programmiersprachen durch Definition eines eigenen, objektorientierten Typsystems. COM gab vor wie der Maschinencode zum Aufbau von Objekten und einfachen Datentypen, die Speicherverwaltung und Aufruf von Methoden aussehen soll. Sprachen, deren Compiler diese Vorgaben erfüllten, waren damit interoperabel.
Am Ende wies COM doch zu viele Beschränkungen auf. In der Kritik waren die beschränkte Objektorientierung, eine umständliche Objektlebensverwaltung mittels Referenzzählung, der Zwang zu einer Anmeldung in der Registry und die fehlende Möglichkeit eines Parallelbetriebes verschiedener Versionen auf einem Rechner.