Iadul DLL

Locatia fiecarei componente este stocata in Windows registry si poate exista o singura versiune instalata a unei anumite componente. Aceasta limitare poate duce la complicarea dezvoltarii aplicatiilor bazate pe COM (Component Object Model), si posibilitatea ca programe diferite, sau chiar versiuni diferite ale aceluiasi program, sa poata fi realizate pentru a functiona cu diferite versiuni ale aceleiasi componente COM. Aceasta conditie este cunoscuta ca iadul DLL (Dinamic Link Library).

Windows Xp a introdus un nou model de registrare a obiectelor COM numita “Registration-free COM”. Datorita acestei facilitati, aplicatiile care au nevoie sa instaleze obiecte COM si informatia necesara lor in registry.

Datorita acestei facilitati aplicatiile instaleaza obiectele COM in folderul aplicatiei, in loc sa foloseasca registrul global, si prin care, doar respectiva aplicatie va putea “vedea” – folosi obiectele COM instalate.

Probleme si incompatibilitati de versiuni

In stiinta calculatoarelor, “Iadul DLL” este un termen pentru complicatiile ce pot surveni cand se lucreaza cu biblioteci dinamice “DLL” folosite in sistemul de operare Microsoft Windows.

“Iadul” apare printr-o alerta tip pop-up ce raporteaza un mesaj “A required DLL file, was not found” sau “The procedure entry point Y couldn’t be located in nume.DLL” atunci cand utilizatorul incearca sa porneasca o aplicatie.

Adesea, problemele de acest gen apar in special atunci cand numeroase aplicatii au fost instalate si dezinstalate din sistem. Dificultatile includ conflicte intre versiuni diferite ale unui DLL, dificultati in obtinerea DLL-ului necesar sau existenta mai multor copii care nu sunt necesare a unui singur DLL.

O versiune a unei biblioteci poate fi compatibila cu anumite programe care o folosesc, si incompatibile cu altele. Sistemul de operare Windows a fost vulnerabil la acest lucru datorita legaturilor intre librarii C++ si obiectele OLE (Object Linking and Embedding). Clasele din C++ exporta multe metode si o singura schimbare intr-o clasa poate duce la incompatibilitatea intregii librarii cu aplicatia pe care o va deservi.

OLE are niste reguli stricte pentru a preveni acest lucru: interfetele sunt stabile iar memoria nu este “impartita”. Dar acest lucru nu este de ajuns. Inainte de Windows 2000, sistemele de operare Windows erau vulnerabile deoarece tabloul de clase COM era impartit de toti utilizatorii si de toate procesele. Doar un singur obiect COM intr-un singur EXE/DLL putea fi declarat ca un COM specific ClassID.

Daca un program dorea sa creeze o instanta a acestei clase, o putea face. Ca rezultat, o instalare a unui program ce instala o noua versiune a obiectelor putea duce la “stricarea” altor aplicatii ce au fost instalate inainte.

O problema comuna ce poate aparea este atunci cand noile programe instalate rescriu un DLL functionabil existent, cu o versiune mai veche, incompatibila. Un exemplu bine cunoscut este ctl3d.dll si ctl3dv2.dll, librarii ale Windows 3.1.

Inregistrarea COM incorecta

In COM, registrul Windows-ului este folosit pentru a decide ce DLL va fi folosit. Daca este inregistrata o versiune gresita a unui modul, acel modul DLL va fi incarcat inlocul celui bun. Aceasta situatie poate surveni atunci cand se instaleaza o anumita versiune a unui program peste o versiune mai veche a aceluiasi program.

Module ce impart aceeasi memorie

Versiunile vechi ale Windows-ului incarcau doar o instanta a unui anumit DLL; toate aplicatiile foloseau aceleasi adrese de memorie pana ce nicio aplicatie nu le mai folosea – atunci erau sterse din memorie. Pentru sistemele de operare mai noi pe 32 si 64 biti, folosirea in comun a memoriei poate avea loc doar atunci cand executabile diferite incarca un modul din exact acelasi folder; codul este impartit de procese printr-un alt proces numit “memory mapping”.

Cu toate acestea, chiar daca DLL-ul dorit este gasit in folderul potrivit, nicio instanta nu va fi pornita daca unul din aceste programe a pornit cu o versiune incompatibila dintr-un alt folder. Acest lucru se poate observa atunci cand o aplicatie poate retura erori doar atunci cand o alta aplicatie ruleaza. Din acest motiv, pentru programatori, este necesar atunci cand survine o eroare neintampinata, sa se stie ce alte programe ruleaza in acel timp, pentru a detecta cauza problemei.

Iadul DLL-urilor era un fenomen comun in versiunile mai vechi ale sistemului de operare Windows. Aplicatiile de instalare a programelor au introdus noi metode pentru a verifica bibliotecile inainte de a fi inlocuite si diverse unelte au simplificat procesul de instalare. Microsoft a cerut ca aplicatiile sa foloseasca un sistem de instalare standard si sa functioneze corespunzator, desi Internetul a oferit multe oportunitati utilizatorilor, de a instala diverse programe din surse nesigure si care nu se conformau cererilor Microsoft.

Solutii

Una dintre cele mai simple solutii pentru a evita aceste probleme este legatura statica intre biblioteci si programe. In loc ca o aplicatie sa-si faca griji in privinta unei anumite versiuni a unei librarii DLL, aplicatia era compilata sa fie legata de acele librarii si sa nu foloseasca o alta aflata deja in sistem.

Windows File Protection este o alta masura a Microsoft introdusa in anul 2000 pentru a preveni aplicatiile neautorizate de a rescrie DLL-uri din sistem. In acest fel, bibliotecile se pot rescrie doar daca aplicatiile folosesc un API specific care le permit sa faca asta.

Rularea in mod simultan a unor DLL ce se afla in conflict

Pentru a rula mai multe versiuni diferite a acelorasi biblioteci in acelasi timp, trebuie plasate in foldere diferite, de exemplu in folderul aplicatiei, nu in folderul System. Inainte de Windows Xp acest lucru nu era posibil deoarece OLE nu permitea, existand un singur registru de obiecte COM pentru toate aplicatiile.

Windows Xp a introdus o solutie numita Side-by-Side Component Sharing ce incarca separat copii ale DLL-ului pentru fiecare aplicatie ce le foloseste. Desi conflictele par rezolvate, pot exista si procese care folosesc aceleasi date.

Aplicatiile portabile reduc problemele legate de biblioteci, deoarece fiecare program contine DLL-urile sale intr-un fel de “container”, folosind “virtualizarea aplicatiei” si evitand instalarea fisierelor DLL in sistemul de operare.

NET Framework diminueaza aceste probleme, folosind un sistem numit “Global Assembly Cache” pentru a stoca multiple versiuni a unui DLL.

Bibliografie: http://en.wikipedia.org/wiki/DLL_hell