BEDRIFTSTEKNOLOGI

Microsoft rydder opp i "DLL-helvetet"

Ulike versjoner av sentrale bibliotekfiler med samme navn har alltid vært et problem i Windows. Nå ser det ut til at Microsoft har funnet en løsning.

10. mars 2003 - 13:00

Problemet med dynamisk tilknyttede biblioteker (Dynamic Link Library - DLL) i Windows oppstår når et program installeres som tar i bruk en oppgradert utgave av en DLL som allerede er i bruk av en annen applikasjon. Det er nemlig alltid slik at det opprinnelige programmet kan benytte den oppdaterte DLL. Det vil brukeren merke ved at programmet gir en feilmelding og som oftest ikke lar seg starte.

Verken Windows eller programvaren som kjøres i operativsystemet har noe begrep om versjonsnummer på DLL. Når DLL-er av samme typen heter nøyaktig det samme, uavhengig av versjon, blir det også vanskelig å lagre både nye og gamle utgaver på samme sted.

Ifølge ZDNet UK er årsaken til at Microsoft i sin tid valgte denne måten å håndtere DLL-filer på, at harddiskplass og minne var langt dyrere da. Det var derfor om å gjøre å utnytte plassen så effektivt som mulig. Situasjonen i dag er en annen. Om du har fem ulike utgaver av en DLL-fil på harddisken din - hver på et par megabytes, er det ingen katastrofe. Det vil bare utgjøre en brøkdel av den tilgjengelige plassen på harddisken din uansett. I tillegg var ikke bruk moduler, som DLL-ene faktisk er, så vanlig i programvaren før i tiden. Da var det i mange tilfeller vanlig at hvert program besto av én stor fil.

Microsoft håper nå å kunne gjøre en slutt på dette problemet når selskapet i Windows Server 2003 bygger inn et system som vil hindre at nye og oppgraderte DLL-filer skriver over de gamle utgavene som kanskje fortsatt benyttes av allerede installert programvare.

.Net 1.1, som vil være en integrert del Microsoft nye serveroperativsystem, skal støtte noe selskapet kaller sterk binding. Dette betyr at en applikasjon eller komponent kan binde seg til en spesifisert versjon av en annen komponent, slik at du kan gjenbruke komponenter eller bruke dem isolert.

.Net 1.1 vil tilby Windows Server 2003 en såkalt Global Assembly Cache, et lager for alle de globalt delte .Net-komponentene på en spesiell datamaskin.

- Når en .Net-komponent installeres på denne maskinen, vil Global Assembly Cache sjekke komponentens versjon, offentlige nøkkel og språkinformasjon, for så å opprette et sterkt navn for denne komponenten, forklarer Ivo Salmre, Microsofts sjef for verktøy og teknologier for .Net og utviklere, til ZDNet UK. Komponenten vil da registreres i lageret indeksert med det sterke navnet, slik at den ikke vil bli forvekslet med andre versjoner av den sammen komponenten.

For å sørge for at en applikasjon finner den korrekte komponenten, vil systemet først lete etter en lokal utgave. Hvis en slik ikke eksisterer, vil systemet se i mellomlageret (cache'en) for å finne et nøyaktig motstykke til komponentens sterke navn. Hvis dette også feiler, vil systemet bruke en heuristisk framgangsmåte for å finne den nest beste komponenten. Men normal vil en applikasjon alltid bruke den komponenten som den var bygget og testet mot. Det skal likevel være mulig for administratorer å overstyre disse reglene ved behov.

.Net-komponenter skal ifølge ZDNet UK ikke ha noen registreringsregler under Windows Server 2003. Dette skal ifølge Salmre bety at det vil være enkelt å flytte en .Net-komponent fra én server til en annen. Dette skal også bety at hele applikasjoner kan flyttes fra én maskin til en annen, uten at applikasjonen må installeres på nytt.

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.
Tekjobb
Se flere jobber
En tjeneste fra