Niekompatybilne wersje Konkretna wersja biblioteki może być zgodna z częścią (i niezgodna z inną) programów, które jej wymagają. System Windows był szczególnie podatny na tę przypadłość ze względu na nacisk do stosowania łączenia dynamicznego bibliotek C++ i mechanizm osadzania obiektów (OLE). Klasy w C++ eksportują wiele metod, a jedna zmiana w klasie (jak np. nowa metoda wirtualna) może spowodować utratę kompatybilności z programami, które były utworzone w oparciu o wcześniejszą wersję. Mechanizm osadzania obiektów ma ścisłe zasady, które mają temu zapobiec – od interfejsów wymaga się, aby były stabilne, a zarządzanie pamięcią nie jest współdzielone. Lecz to nie jest wystarczające, bo może się zmienić semantyka klasy. Co dla jednego programu jest „poprawką”, w innym może oznaczać usunięcie „funkcjonalności”. Zanim pojawił się Windows 2000, systemy Windows były bardzo wrażliwe na takie zmiany, gdyż tabela klas COM była wspólna dla wszystkich użytkowników i procesów. Tylko jeden obiekt COM, z jednego pliku DLL/EXE mógł być zadeklarowany w systemie jako serwis dla konkretnej globalnej klasy COM. Jeśli jakikolwiek program musiał utworzyć instancję tej klasy, uzyskiwał obiekt z aktualnie zarejestrowanej implementacji.
Źródło i licencja
Fragment artykułu Wikipedia — Piekło DLL · historia autorów.
Tekst: CC BY-SA 4.0. Wydzielono fragment z dłuższego artykułu.