Software installasjon og andre ettertanker Stein Jørgen Ryan 25feb05 Software installasjon Alle software produsenter gjør det. Høyst varierende forståelse av hva det er. Hvordan gjøres det i dag (på Windows)? Hvordan ble det slik? Hva er idealet? Hvordan realisere idealet? 1
Installasjon i dag (Windows) Skriv ditt eget setup.exe program som: 1. Oppretter en tom katalog. 2. Kopierer inn Egenutviklede filer til nyopprettet katalog. Microsoft redistribuérbare filer til systemkatalog. 3. Gjør funksjonaliteten tilgjengelig Legger programmet inn i Start menyen. Eventuelt hekter seg på som OS plugin. 4. Eventuelt registrerer egenutviklet uninstall.exe. Avinstallering i dag (Windows) Kun mulig hvis registrert med uninstall.exe. Windows vil da: 1. Liste opp de programmer som har registrert seg. 2. Starte egenutviklet uninstall.exe for valgt program. 3. Uninstall.exe reverserer det som ble gjort av setup.exe. 2
Sørgelig oppsummering Setup.exe = applikasjonskonstruktor. Uninstall.exe = applikasjonsdestruktor. Microsoft overlater hele oppgaven til applikasjonsutviklerne. Gjøres en eneste applikasjonsinstallasjon feil, får potensielt alle installerte applikasjoner lide. Jobben til et operativsystem er å isolere applikasjoner fra hverandre!!! Hvordan havnet vi i denne suppa? In the beginning was the command line Installasjon = nytt verb/kommando i shell. Eksekverbar fil kopieres til /usr/bin. Forhåndsdefinert katalogstruktur. Uninstall = fjerne filen. Install/uninstall er operasjoner på filer. Veldefinert og enkelt. Dagens systemer er mer enn et shell der hver kommando er en (og bare en) eksekverbar fil. Dette kompliserer installasjonsprosessen. 3
Enter the dragon 1 Dynamisk linking. Et program er ikke lenger én fil, men er nå: En hovedfil (exe). Flere dynamiske lenkede biblioteker (DLL) Link fra hovedfil til start-meny etc. Flere programmer kan dele en DLL. Typisk redistribuérbare tillegg fra Microsoft. Eksempler: GDI+ og.net framework. DLL HELL Programmer redistribuerer samme DLL. Flere versjoner av denne DLL. Problem: Installer et program = et annet slutter å virke. Microsoft løsning: Versjonskontroll av DLL. Gjøres av installasjonsprogrammet. Dersom en produsent gjør det feil slutter programmer fra andre produsenter å virke. 4
To typer dynamisk linking Implisitt. Exe inneholder refereranse til DLL er. Loader laster automatisk inn DLL er. Leter etter DLL ene i bestemte kataloger. Eksplisitt. Exe inneholder ikke referanser til DLL. Programmet laster DLL selv (LoadLibrary). Kall via funksjonspekere (GetProcAddress). Eksplisitt dynamisk linking Meget kraftig mekanisme som gir Late binding. Utbyttbar funksjonalitet. Basis for Common Object Model (COM).NET 5
Enter the dragon 2 Ved eksplisitt dynamisk linking: Ingen referanser fra EXE til DLL. Ukjent hvilke DLL er som brukes av EXE! Avhengigheter må lagres separat. Finnes ingen sentral oversikt over dette. Gjøres i beste fall av hvert enkelt program. Ingen generell mekanisme for avinstallering. Void if seal broken Produsenter trenger å kunne gi garantier. Må kunne beskytte seg mot andres feil. Støtte interaksjon med annen software. Vanskelig pr i dag. Program er bare en samling EXE og DLL filer. Avhengigheter mellom filer er ukjent. Direkte håpløst når flere programmer deler DLL. Til hinder for integrasjon av programvare. Vi trenger nye mekanismer! 6
Komponenter Enhet som (atomisk) kan Installeres Fjernes Oppdateres (feilrettinger) Kan ikke oppdateres av andre enn produsenten. Kan inneholde andre komponenter. Noen obligatoriske, andre ikke. Holder styr på avhengigheter mellom disse. Eksempler på komponenter Eksekverbar enkeltfil (EXE/DLL). Program Samling enkeltfiler med innbyrdes avhengigheter Eksempel: Excel Programpakke. Eksempel: Microsoft Office Device drivers Plugins Biometrisk login shell Passord kvalitetssjekker 7
Operativsystemet som komponent OS er en komponent. Inneholdes ikke i andre komponenter. Inneholder alle andre komponenter. Noen obligatoriske: dev-drivers, shell, plugins. Andre ikke-obligatoriske: Applikasjoner. Holder styr på alle avhengigheter og tilbyr: Installering. Avinstallering. Oppdatering (via web). Komponentstøtte i dag Systemkritiske komponenter Device drivers (tvunget fram av PnP) Visse typer plugins (protokollstack etc) Oppdatering via Windows Update Burde vært, men er ikke komponenter Programmer Plugins generelt 8
Konsekvenser Ingen sentral oversikt over software Installasjon/avinstallasjon er ikke robust Ingen sentral oppdateringsfunksjon Ønskeliste for ny OS funksjonalitet En sentral database over komponenter. Klar definisjon av komponenttyper. For hver komponenttype Språk for å beskrive en komponent av typen. Installasjon basert på beskrivelsen. Avinstallering som reverserer installasjonen. Generell oppdateringstjeneste. Kommuniserer med en server hos produsenten. Gi bedre beskyttelse mot virus. 9
Hvordan realisere ny funksjonalitet Operativsystem produsentene kan: Utvide eksisterende støtte for kritiske komponenter til også å omfatte vanlige applikasjoner. Åpne opp protokoller som Windows Update. I mellomtiden bør man Ikke distribuere redistribuerbare filer (!) Ikke kopiere filer til systemkataloger. Hva med open source? Mulig å modifisere Linux? Liten tradisjon for binære distribusjoner! Lang tradisjon for enkel shell-fokusert bruk! Plug-and-play hardware vil fremtvinge mer komponentmessig håndtering av kritiske sw-komponenter. Applikasjonsinstallasjon kan utnytte denne trenden. 10
Surfe inn på neste bølge?.net introduserer interessante konsepter: Distribuert kode er CIL (mellomkode). Kodegenerering gjøres ved installasjonen. CIL kode beskriver alle avhengigheter. CIL assemblies er fullgode komponenter? 11