Windows -register - Windows Registry

Windows -register

Registerredigering, brukergrensesnittet for registret, i Windows 10
Utvikler (er)	Microsoft
Første utgivelse	6. april 1992 ; For 29 år siden med Windows 3.1 ( 1992-04-06 )
Operativsystem	Microsoft Windows
Plattform	IA-32 , x86-64 og ARM (og historisk sett DEC Alpha , Itanium , MIPS og PowerPC )
Inkludert med	Microsoft Windows
Type	Hierarkisk database
Nettsted	docs .microsoft .com /no-us /windows /desktop /SysInfo /registry

Den Windows-registeret er en hierarkisk database som lagrer lavt nivå innstillinger for Microsoft Windows operativsystem og for programmer som velger å bruke registeret. Den kjernen , enhetsdrivere , tjenester , Security Accounts Manager , og brukergrensesnitt kan alle bruke registret. Registeret gir også tilgang til tellere for profilering av systemytelse.

Med andre ord inneholder registret eller Windows -registret informasjon, innstillinger, alternativer og andre verdier for programmer og maskinvare som er installert på alle versjoner av Microsoft Windows -operativsystemer. For eksempel, når et program er installert, blir en ny undernøkkel som inneholder innstillinger som programmets plassering, versjon og hvordan du starter programmet, lagt til i Windows -registret.

Når det ble introdusert med Windows 3.1 , lagret Windows -registret først og fremst konfigurasjonsinformasjon for COM -baserte komponenter. Windows 95 og Windows NT utvidet bruken til å rasjonalisere og sentralisere informasjonen i mengden INI -filer , som inneholdt konfigurasjonene for individuelle programmer, og ble lagret på forskjellige steder. Det er ikke et krav for Windows -programmer å bruke Windows -registret. .NET Framework -applikasjoner bruker for eksempel XML -filer for konfigurasjon, mens bærbare applikasjoner vanligvis beholder konfigurasjonsfilene med kjørbare filer .

Begrunnelse

Før Windows -registret,. INI-filer lagret hvert programs innstillinger som en tekstfil eller binær fil , ofte plassert på et delt sted som ikke ga brukerspesifikke innstillinger i et flerbruksscenario. I kontrast lagrer Windows -registeret alle programinnstillinger i ett logisk depot (men et antall diskrete filer) og i en standardisert form. Ifølge Microsoft gir dette flere fordeler i forhold til .INI -filer. Siden filanalyse utføres mye mer effektivt med et binært format, kan den leses fra eller skrives til raskere enn en tekst -INI -fil. Videre kan sterkt typede data lagres i registret, i motsetning til tekstinformasjonen som er lagret i .INI -filer. Dette er en fordel når du redigerer nøkler manuelt ved hjelp av regedit.exeden innebygde Windows Registerredigering. Fordi brukerbaserte registerinnstillinger lastes fra en brukerspesifikk bane i stedet for fra en skrivebeskyttet systemplassering, lar registret flere brukere dele den samme maskinen, og lar også programmer fungere for mindre privilegerte brukere. Sikkerhetskopiering og gjenoppretting er også forenklet ettersom registeret kan nås via en nettverkstilkobling for ekstern styring/støtte, inkludert fra skript, ved bruk av standard sett med APIer , så lenge Remote Registry -tjenesten kjører og brannmurregler tillater dette.

Fordi registret er en database, tilbyr det forbedret systemintegritet med funksjoner som atomoppdateringer . Hvis to prosesser prøver å oppdatere den samme registerverdien samtidig, vil en prosessendring gå foran den andre, og den generelle konsistensen av dataene vil opprettholdes. Når det gjøres endringer i .INI -filer, kan slike løpsbetingelser resultere i inkonsekvente data som ikke samsvarer med noen av forsøkene på oppdatering. Windows Vista og senere operativsystemer gir transaksjonsoppdateringer til registret ved hjelp av Kernel Transaction Manager , og utvider atomisitetsgarantiene for flere viktige og/eller verdiendringer, med tradisjonell forpliktelse -avbryt semantikk. (Vær imidlertid oppmerksom på at NTFS også gir slik støtte for filsystemet, så de samme garantiene kan i teorien oppnås med tradisjonelle konfigurasjonsfiler.)

Struktur

Nøkler og verdier

Registeret inneholder to grunnleggende elementer: nøkler og verdier . Registernøkler er container objekter som ligner på mapper. Register verdier er ikke-container objekter som ligner på filer. Nøkler kan inneholde verdier og undernøkler. Nøkler refereres til med en syntaks som ligner på Windows 'stinavn, ved å bruke skråstreker for å angi hierarkinivåer. Nøkler må ha et ufølsomt navn uten omvendt skråstrek.

Hierarkiet med registernøkler kan bare nås fra et kjent rotnøkkelhåndtak (som er anonymt, men hvis effektive verdi er et konstant numerisk håndtak) som er kartlagt til innholdet i en registernøkkel som er forhåndslastet av kjernen fra en lagret "bikube", eller til innholdet i en undernøkkel i en annen rotnøkkel, eller kartlagt til en registrert tjeneste eller DLL som gir tilgang til dens inneholdte undernøkler og verdier.

F.eks. Refererer HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows til undernøkkelen "Windows" til undernøkkelen "Microsoft" til undernøkkelen "Programvare" til HKEY_LOCAL_MACHINE rotnøkkelen.

Det er syv forhåndsdefinerte rotnøkler, tradisjonelt navngitt i henhold til deres konstante håndtak definert i Win32 API, eller med synonyme forkortelser (avhengig av applikasjoner):

• HKEY_LOCAL_MACHINE eller HKLM
• HKEY_CURRENT_CONFIG eller HKCC
• HKEY_CLASSES_ROOT eller HKCR
• HKEY_CURRENT_USER eller HKCU
• HKEY_USERS eller HKU
• HKEY_PERFORMANCE_DATA (bare i Windows NT, men usynlig i Windows Registerredigering)
• HKEY_DYN_DATA (bare i Windows 9x, og synlig i Windows Registerredigering)

I likhet med andre filer og tjenester i Windows, kan alle registernøkler være begrenset av tilgangskontrollister (ACL -er), avhengig av brukerrettigheter, eller sikkerhetstokener som er anskaffet av applikasjoner, eller på systemsikkerhetspolicyer som håndheves av systemet (disse begrensningene kan være forhåndsdefinerte av systemet selv, og konfigurert av lokale systemadministratorer eller av domeneadministratorer). Ulike brukere, programmer, tjenester eller eksterne systemer kan bare se noen deler av hierarkiet eller forskjellige hierarkier fra de samme rotnøklene.

Registerverdier er navn / dataparene lagret i tastene. Registerverdier refereres separat til registernøkler. Hver registerverdi lagret i en registernøkkel har et unikt navn hvis bokstaver ikke er vesentlig. De Windows API- funksjoner som søk og manipulere register verdier tar verdi navn separat fra nøkkelbanen og / eller håndtak som identifiserer den overordnede nøkkelen. Registerverdier kan inneholde omvendte skråstreker i navnene, men det gjør det vanskelig å skille fra nøkkelbanene når du bruker noen eldre Windows Registry API -funksjoner (hvis bruk blir avviklet i Win32).

Terminologien er noe misvisende, ettersom hver registernøkkel ligner en assosiativ matrise , der standardterminologi vil referere til navnet på hver registerverdi som en "nøkkel". Vilkårene er en holdout fra 16-biters registret i Windows 3, der registernøkler ikke kunne inneholde vilkårlige navn/datapar, men bare inneholdt en ikke navngitt verdi (som måtte være en streng). I denne forstand var Windows 3 -registret som et enkelt assosiativt array, der nøklene (i betydningen både "registernøkkel" og "assosiativ matrisnøkkel") dannet et hierarki, og registerverdiene var alle strenger. Da 32-biters register ble opprettet, var tilleggsmuligheten for å lage flere navngitte verdier per nøkkel, og betydningen av navnene var noe forvrengt. For kompatibilitet med den forrige oppførselen kan hver registernøkkel ha en "standard" -verdi, hvis navn er den tomme strengen.

Hver verdi kan lagre vilkårlige data med variabel lengde og koding, men som er knyttet til en symbolsk type (definert som en numerisk konstant) som definerer hvordan disse dataene skal analyseres. Standardtypene er:

Rotnøkler

Nøklene på rotnivå i den hierarkiske databasen er vanligvis navngitt etter Windows API -definisjonene, som alle begynner "HKEY". De blir ofte forkortet til et tre- eller fire-bokstavs kortnavn som begynner med "HK" (f.eks. HKCU og HKLM). Teknisk sett er de forhåndsdefinerte håndtak (med kjente konstante verdier) til spesifikke nøkler som enten oppbevares i minnet, eller lagres i bikube -filer som er lagret i det lokale filsystemet og lastet av systemkjernen ved oppstartstid og deretter delt (med forskjellige tilgangsrettigheter) mellom alle prosesser som kjører på det lokale systemet, eller lastet og kartlagt i alle prosesser som startet i en brukersesjon når brukeren logger seg på systemet.

HKEY_LOCAL_MACHINE (lokale maskinspesifikke konfigurasjonsdata) og HKEY_CURRENT_USER (brukerspesifikke konfigurasjonsdata) noder har en lignende struktur som hverandre; brukerprogrammer søker vanligvis etter innstillingene sine ved å først se etter dem i "HKEY_CURRENT_USER \ Software \ Leverandørnavn \ Applikasjonsnavn \ Versjon \ Innstillingsnavn", og hvis innstillingen ikke blir funnet, ser du i stedet på samme sted under HKEY_LOCAL_MACHINE -nøkkelen. Imidlertid kan det omvendte gjelde for administratorinnstilte policyinnstillinger der HKLM kan gå foran HKCU. Den Windows Logo-programmet har spesifikke krav til hvor ulike typer brukerdata kan lagres, og at begrepet minst privilegium følges slik at administrator-nivå tilgang ikke er nødvendig å bruke et program.

HKEY_LOCAL_MACHINE (HKLM)

Forkortet HKLM, HKEY_LOCAL_MACHINE lagrer innstillinger som er spesifikke for den lokale datamaskinen.

Nøkkelen som er lokalisert av HKLM er faktisk ikke lagret på disken, men beholdes i minnet av systemkjernen for å kartlegge alle de andre undernøklene. Applikasjoner kan ikke opprette flere undernøkler. På Windows NT inneholder denne nøkkelen fire undernøkler, "SAM", "SECURITY", "SYSTEM" og "SOFTWARE", som lastes inn ved oppstartstid i de respektive filene i mappen %SystemRoot %\ System32 \ config. En femte undernøkkel, "HARDWARE", er flyktig og opprettes dynamisk, og lagres som sådan ikke i en fil (den viser en visning av alle de oppdagede Plug-and-Play-enhetene). På Windows Vista og over blir en sjette og syvende undernøkkel, "COMPONENTS" og "BCD", kartlagt i minnet av kjernen on-demand og lastet fra %SystemRoot %\ system32 \ config \ COMPONENTS eller fra oppstartskonfigurasjonsdata, \ boot \ BCD på systempartisjonen.

• "HKLM \ SAM" -tasten vises vanligvis som tom for de fleste brukere (med mindre de får tilgang fra administratorer av det lokale systemet eller administratorer av domener som administrerer det lokale systemet). Den brukes til å referere til alle SAM -databaser for " Security Accounts Manager " for alle domener der det lokale systemet er administrativt autorisert eller konfigurert (inkludert det lokale domenet til det kjørende systemet, hvis SAM -database er lagret i en undernøkkel også kalt " SAM ": andre undernøkler opprettes etter behov, en for hvert tilleggsdomenet). Hver SAM -database inneholder alle innebygde kontoer (for det meste gruppealiaser) og konfigurerte kontoer (brukere, grupper og deres aliaser, inkludert gjestekontoer og administratorkontoer) som er opprettet og konfigurert på det respektive domenet, for hver konto i domenet inneholder den spesielt brukeren navn som kan brukes til å logge på det domenet, den interne unike brukeridentifikatoren i domenet, en kryptografisk hash for hver brukers passord for hver aktivert autentiseringsprotokoll , plasseringen av lagring av brukerregisteret, forskjellige statusflagg (for eksempel hvis kontoen kan telles opp og være synlig på skjermbildet for pålogging), og listen over domener (inkludert det lokale domenet) som kontoen ble konfigurert til.
• "HKLM \ SECURITY" -tasten vises vanligvis tom for de fleste brukere (med mindre de får tilgang av brukere med administrative rettigheter) og er koblet til sikkerhetsdatabasen til domenet som den nåværende brukeren er logget på (hvis brukeren er logget på det lokale systemdomenet, vil denne nøkkelen bli koblet til registret som er lagret av den lokale maskinen og administrert av lokale systemadministratorer eller av den innebygde "System" -kontoen og Windows -installatører). Kjernen får tilgang til den for å lese og håndheve sikkerhetspolicyen som gjelder for den nåværende brukeren og alle applikasjoner eller operasjoner som utføres av denne brukeren. Den inneholder også en "SAM" -nøkkel som er dynamisk koblet til SAM -databasen for domenet som den nåværende brukeren er logget på.
• "HKLM \ SYSTEM" -tasten kan vanligvis bare skrives av brukere med administrative rettigheter på det lokale systemet. Den inneholder informasjon om Windows -systemoppsettet, data for den sikre tilfeldige tallgeneratoren (RNG), listen over enheter som er montert for øyeblikket som inneholder et filsystem, flere nummererte "HKLM \ SYSTEM \ Control Sets" som inneholder alternative konfigurasjoner for systemmaskinvaredrivere og tjenester som kjører på det lokale systemet (inkludert det nåværende brukte og en sikkerhetskopi), en "HKLM \ SYSTEM \ Select" -nøkkel som inneholder statusen til disse kontrollsettene, og en "HKLM \ SYSTEM \ CurrentControlSet" som er dynamisk knyttet ved oppstart til Kontrollsett som for øyeblikket brukes på det lokale systemet. Hvert konfigurert kontrollsett inneholder:
  • en "Enum" -nøkkel som oppregner alle kjente Plug-and-Play-enheter og knytter dem til installerte systemdrivere (og lagring av enhetsspesifikke konfigurasjoner av disse driverne),
  • en "Tjenester" -nøkkel som viser alle installerte systemdrivere (med ikke-enhetsspesifikk konfigurasjon og oppregning av enheter som de blir instantiert for) og alle programmer som kjører som tjenester (hvordan og når de kan startes automatisk),
  • en "Kontroll" -nøkkel som organiserer de forskjellige maskinvaredrivere og programmer som kjører som tjenester og all annen systemomfattende konfigurasjon,
  • en "Maskinvareprofiler" -nøkkel som viser de forskjellige profilene som er innstilt (hver med "System" eller "Programvare" -innstillinger som brukes til å endre standardprofilen, enten i systemdrivere og -tjenester eller i programmene) samt "Maskinvare Profiler \ Current "undernøkkel som er dynamisk knyttet til en av disse profilene.
• Undernøkkelen "HKLM \ SOFTWARE" inneholder programvare og Windows -innstillinger (i standard maskinvareprofil). Det er for det meste modifisert av applikasjoner og systeminstallatører. Den er organisert av programvareleverandør (med en undernøkkel for hver), men inneholder også en "Windows" -nøkkel for noen innstillinger i Windows -brukergrensesnittet, en "Klasser" -nøkkel som inneholder alle registrerte assosiasjoner fra filutvidelser, MIME -typer, objektklasse -IDer og grensesnitt -ID -er (for OLE, COM/DCOM og ActiveX), til de installerte programmene eller DLL -ene som kan håndtere disse typene på den lokale maskinen (men disse tilknytningene kan konfigureres for hver bruker, se nedenfor) og en "Policies" -nøkkel (også organisert av leverandør) for å håndheve generelle brukspolicyer for applikasjoner og systemtjenester (inkludert den sentrale sertifikatbutikken som brukes til å autentisere, autorisere eller ikke tillate eksterne systemer eller tjenester som kjører utenfor det lokale nettverksdomenet).
• "HKLM \ SOFTWARE \ Wow6432Node" -tasten brukes av 32-biters applikasjoner på et 64-biters Windows OS, og er tilsvarende, men atskilt fra "HKLM \ SOFTWARE". Nøkkelbanen presenteres transparent for 32-biters applikasjoner av WoW64 som HKLM \ SOFTWARE (på lignende måte som 32-biters applikasjoner ser %SystemRoot %\ Syswow64 som %SystemRoot %\ System32)

HKEY_CLASSES_ROOT (HKCR)

Forkortet HKCR, HKEY_CLASSES_ROOT inneholder informasjon om registrerte applikasjoner, for eksempel filforeninger og OLE -objektklasse -IDer, og knytter dem til programmene som brukes til å håndtere disse elementene. På Windows 2000 og nyere er HKCR en samling av brukerbaserte HKCU \ Software \ Classes og maskinbaserte HKLM \ Software \ Classes. Hvis det finnes en gitt verdi i begge undernøklene ovenfor, har den i HKCU \ Software \ Classes forrang. Designet gir mulighet for enten maskin- eller brukerspesifikk registrering av COM- objekter.

HKEY_USERS (HKU)

Forkortet HKU, HKEY_USERS inneholder undernøkler som tilsvarer HKEY_CURRENT_USER-nøklene for hver brukerprofil som er aktivt lastet på maskinen, selv om brukerhives vanligvis bare lastes for nå påloggede brukere.

HKEY_CURRENT_USER (HKCU)

Forkortet HKCU, HKEY_CURRENT_USER lagrer innstillinger som er spesifikke for den påloggede brukeren. HKEY_CURRENT_USER -nøkkelen er en lenke til undernøkkelen til HKEY_USERS som tilsvarer brukeren; den samme informasjonen er tilgjengelig på begge stedene. Den spesifikke undernøkkelen det refereres til er "(HKU) \ (SID) \ ..." hvor (SID) tilsvarer Windows SID ; hvis "(HKCU)" -tasten har følgende suffiks "(HKCU) \ Software \ Classes \ ..." så tilsvarer den "(HKU) \ (SID) _CLASSES \ ..." dvs. suffikset har strengen " _CLASSES "er lagt til i (SID).

På Windows NT -systemer lagres hver brukers innstillinger i sine egne filer kalt NTUSER.DAT og USRCLASS.DAT i sin egen undermappe Dokumenter og innstillinger (eller deres egen brukerundermappe i Windows Vista og nyere). Innstillinger i denne bikuben følger brukere med en roamingprofil fra maskin til maskin.

HKEY_PERFORMANCE_DATA

Denne nøkkelen gir kjøretidsinformasjon til ytelsesdata levert av enten selve NT -kjernen, eller kjører systemdrivere, programmer og tjenester som gir ytelsesdata. Denne nøkkelen er ikke lagret i noen bikube og vises ikke i Registerredigering, men den er synlig gjennom registerfunksjonene i Windows API, eller i en forenklet visning via kategorien Ytelse i Oppgavebehandling (bare for noen få ytelsesdata på det lokale systemet) eller via mer avanserte kontrollpaneler (for eksempel Performances Monitor eller Performances Analyzer som gjør det mulig å samle og logge disse dataene, inkludert fra eksterne systemer).

HKEY_DYN_DATA

Denne nøkkelen brukes bare på Windows 95, Windows 98 og Windows ME . Den inneholder informasjon om maskinvareenheter, inkludert Plug and Play og nettverksytelsesstatistikk. Informasjonen i denne bikuben er heller ikke lagret på harddisken. Plug and Play -informasjonen samles og konfigureres ved oppstart og lagres i minnet.

Utslett

Selv om registret presenterer seg som en integrert hierarkisk database, lagres grener av registret faktisk i en rekke diskfiler som kalles elveblest . (Ordet bikube utgjør en spøk .)

Noen elveblest er flyktige og lagres ikke på disken i det hele tatt. Et eksempel på dette er bikuben til grenen som starter på HKLM \ HARDWARE. Denne bikuben registrerer informasjon om systemmaskinvare og opprettes hver gang systemet starter opp og utfører maskinvaredeteksjon.

Individuelle innstillinger for brukere på et system lagres i en bikube (diskfil) per bruker. Under brukerpålogging laster systemet brukerhulen under HKEY_USERS -nøkkelen og setter HKCU (HKEY_CURRENT_USER) symbolsk referanse for å peke på den nåværende brukeren. Dette lar applikasjoner lagre/hente innstillinger for den nåværende brukeren implisitt under HKCU -nøkkelen.

Ikke alle elveblest lastes inn samtidig. Ved oppstart lastes bare et minimalt sett med elveblest, og etter det lastes elveblestene når operativsystemet initialiseres og når brukerne logger på eller når en bikube eksplisitt lastes inn av et program.

Filplasseringer

Registret er fysisk lagret i flere filer, som vanligvis er skjult fra brukermodus-API-ene som brukes til å manipulere dataene i registret. Avhengig av versjonen av Windows, vil det være forskjellige filer og forskjellige steder for disse filene, men de er alle på den lokale maskinen. Plasseringen for systemregisterfiler i Windows NT er %SystemRoot%\System32\Config; den brukerspesifikke HKEY_CURRENT_USER brukerregisteret er lagret Ntuser.datinne i brukerprofilen. Det er en av disse per bruker; hvis en bruker har en roamingprofil , blir denne filen kopiert til og fra en server ved henholdsvis avlogging og pålogging. En andre brukerspesifikk registerfil som heter UsrClass.dat inneholder COM-registeroppføringer og streifer ikke som standard.

Windows NT

Windows NT -systemer lagrer registret i et binært filformat som kan eksporteres, lastes og lastes av Registerredigering i disse operativsystemene. Følgende systemregisterfiler er lagret i %SystemRoot%\System32\Config\:

• Sam - HKEY_LOCAL_MACHINE \ SAM
• Security - HKEY_LOCAL_MACHINE \ SECURITY
• Software - HKEY_LOCAL_MACHINE \ SOFTWARE
• System - HKEY_LOCAL_MACHINE \ SYSTEM
• Default - HKEY_USERS \ .DEFAULT
• Userdiff- Ikke assosiert med en bikube. Brukes kun ved oppgradering av operativsystemer.

Følgende fil er lagret i hver brukers profilmappe:

• %USERPROFILE%\Ntuser.dat- HKEY_USERS \ < User SID > (lenket til av HKEY_CURRENT_USER)

For Windows 2000, Server 2003 og Windows XP brukes følgende tilleggsspesifikke fil for filtilknytninger og COM-informasjon:

• %USERPROFILE%\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat (banen er lokalisert) - HKEY_USERS \ <User SID> _Classes (HKEY_CURRENT_USER \ Software \ Classes)

For Windows Vista og senere ble banen endret til:

• %USERPROFILE%\AppData\Local\Microsoft\Windows\Usrclass.dat(banen er ikke lokalisert) alias %LocalAppData%\Microsoft\Windows\Usrclass.dat- HKEY_USERS \ <User SID> _Classes (HKEY_CURRENT_USER \ Software \ Classes)

Windows 2000 beholder en alternativ kopi av registerhives (.ALT) og prøver å bytte til det når det oppdages korrupsjon. Windows XP og Windows Server 2003 opprettholder ikke en System.altbikube fordi NTLDR på disse versjonene av Windows kan behandle System.logfilen for å oppdatere en systemhule som har blitt inkonsekvent under en nedleggelse eller krasj. I tillegg %SystemRoot%\Repairinneholder mappen en kopi av systemets registerelementer som ble opprettet etter installasjonen og den første vellykkede oppstarten av Windows.

Hver registerdatafil har en tilknyttet fil med en ".log" -utvidelse som fungerer som en transaksjonslogg som brukes til å sikre at eventuelle avbrutte oppdateringer kan fullføres ved neste oppstart. Internt er registerfiler delt inn i 4  kB "binger" som inneholder samlinger av "celler".

Windows 9x

Registerfilene lagres i %WINDIR%katalogen under navnene USER.DATog SYSTEM.DATmed tillegg av CLASSES.DATi Windows ME. Hver brukerprofil (hvis profiler er aktivert) har også sin egen USER.DATfil som ligger i brukerens profilkatalog i %WINDIR%\Profiles\<Username>\.

Windows 3.11

Den eneste registerfilen kalles, REG.DATog den lagres i %WINDIR%katalogen.

Windows 10 Mobile

Merk: For å få tilgang til registerfilene må telefonen settes i en spesiell modus ved å bruke enten: 

• WpInternals (Sett mobilenheten i blitsmodus.)
• InterOp -verktøy (monter MainOS -partisjonen med MTP.)

Hvis noen av metodene ovenfor fungerte - Enhetsregisterfilene finnes på følgende sted:

 {Phone}\EFIESP\Windows\System32\config

Merk: InterOp Tools inkluderer også et registerredigeringsprogram.

Redigerer

Registerredaktører

Registeret inneholder viktig konfigurasjonsinformasjon for operativsystemet, for installerte applikasjoner samt individuelle innstillinger for hver bruker og applikasjon. En uforsiktig endring av operativsystemets konfigurasjon i registret kan forårsake irreversibel skade, så det er vanligvis bare installasjonsprogrammer som utfører endringer i registerdatabasen under installasjon/konfigurasjon og fjerning. Hvis en bruker ønsker å redigere registret manuelt, anbefaler Microsoft at en sikkerhetskopi av registret utføres før endringen. Når et program fjernes fra kontrollpanelet, kan det hende at det ikke blir helt fjernet, og i tilfelle feil eller feil forårsaket av referanser til manglende programmer, må brukeren sjekke manuelt i kataloger, for eksempel programfiler. Etter dette kan det hende at brukeren må fjerne enhver referanse til det avinstallerte programmet i registret manuelt. Dette gjøres vanligvis ved å bruke RegEdit.exe. Noen ganger er det nødvendig å redigere registret når du arbeider med Windows-spesifikke problemer, f.eks. Problemer når du logger på et domene kan løses ved å redigere registret.

Windows -registeret kan redigeres manuelt ved hjelp av programmer som RegEdit.exe, selv om disse verktøyene ikke avslører noen av registerets metadata, for eksempel den siste endringsdatoen.

Registerredigering for 3.1/95 -serien med operativsystemer er RegEdit.exe, og for Windows NT er RegEdt32.exe; funksjonalitetene er slått sammen i Windows XP. Valgfrie og/eller tredjepartsverktøy som ligner på RegEdit.exe er tilgjengelige for mange Windows CE-versjoner.

Registerredigering lar brukerne utføre følgende funksjoner:

• Opprette, manipulere, gi nytt navn og slette registernøkler, undernøkler, verdier og verdidata
• Import og eksport. REGfiler, eksportere data i det binære bikubeformatet
• Laster, manipulerer og laster ut registre i filformater (bare Windows NT -systemer)
• Angi tillatelser basert på ACL -er (bare Windows NT -systemer)
• Bokmerke brukervalgte registernøkler som Favoritter
• Finne bestemte strenger i nøkkelnavn, verdinavn og verdidata
• Eksternt redigere registret på en annen datamaskin i nettverk

.REG filer

.REGfiler (også kjent som registreringsoppføringer) er tekstbaserte, lesbare filer for eksport og import av deler av registret ved hjelp av en INI- basert syntaks. På Windows 2000 og senere inneholder de strengen Windows Registerredigering versjon 5.00 i begynnelsen og er Unicode -baserte. På Windows 9x og NT 4.0 -systemer inneholder de strengen REGEDIT4 og er ANSI -baserte. .REGFiler i Windows 9x -format er kompatible med Windows 2000 og nyere. Registerredigering på Windows på disse systemene støtter også eksport av .REGfiler i Windows 9x/NT -format. Data lagres i .REGfiler ved hjelp av følgende syntaks:

[<Hive name>\<Key name>\<Subkey name>]
"Value name"=<Value type>:<Value data>

Standardverdien til en nøkkel kan redigeres ved å bruke "@" i stedet for "Verdienavn":

[<Hive name>\<Key name>\<Subkey name>]
@=<Value type>:<Value data>

Strengverdier krever ikke <Verditype> (se eksempel), men skråstreker ('\') må skrives som en dobbeltsidig skråstrek ('\\'), og anførselstegn ('"') som bakoverstrekk-sitat ( '\ "').

For eksempel å legge til verdiene "Verdi A", "Verdi B", "Verdi C", "Verdi D", "Verdi E", "Verdi F", "Verdi G", "Verdi H", "Verdi I "," Verdi J "," Verdi K "," Verdi L "og" Verdi M "til HKLM \ SOFTWARE \ Foobar -nøkkelen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Foobar]
"Value A"="<String value data with escape characters>"
"Value B"=hex:<Binary data (as comma-delimited list of hexadecimal values)>
"Value C"=dword:<DWORD value integer>
"Value D"=hex(0):<REG_NONE (as comma-delimited list of hexadecimal values)>
"Value E"=hex(1):<REG_SZ (as comma-delimited list of hexadecimal values representing a UTF-16LE NUL-terminated string)>
"Value F"=hex(2):<Expandable string value data (as comma-delimited list of hexadecimal values representing a UTF-16LE NUL-terminated string)>
"Value G"=hex(3):<Binary data (as comma-delimited list of hexadecimal values)> ; equal to "Value B"
"Value H"=hex(4):<DWORD value (as comma-delimited list of 4 hexadecimal values, in little endian byte order)>
"Value I"=hex(5):<DWORD value (as comma-delimited list of 4 hexadecimal values, in big endian byte order)>
"Value J"=hex(7):<Multi-string value data (as comma-delimited list of hexadecimal values representing UTF-16LE NUL-terminated strings)>
"Value K"=hex(8):<REG_RESOURCE_LIST (as comma-delimited list of hexadecimal values)>
"Value L"=hex(a):<REG_RESOURCE_REQUIREMENTS_LIST (as comma-delimited list of hexadecimal values)>
"Value M"=hex(b):<QWORD value (as comma-delimited list of 8 hexadecimal values, in little endian byte order)>

Data fra .REGfiler kan legges til /slås sammen med registret ved å dobbeltklikke på disse filene eller bruke /s-bryteren på kommandolinjen. REGfiler kan også brukes til å fjerne registerdata.

For å fjerne en nøkkel (og alle undernøkler, verdier og data) må nøkkelenavnet gå foran med et minustegn ("-").

For eksempel, for å fjerne HKLM \ SOFTWARE \ Foobar -nøkkelen (og alle undernøkler, verdier og data),

[-HKEY_LOCAL_MACHINE\SOFTWARE\Foobar]

For å fjerne en verdi (og dens data) må verdiene som skal fjernes ha et minustegn ("-") etter likhetstegnet ("=").

For eksempel, for å fjerne verdiene "Verdi A" og "Verdi B" (og dataene deres) fra HKLM \ SOFTWARE \ Foobar -nøkkelen:

[HKEY_LOCAL_MACHINE\SOFTWARE\Foobar]
"Value A"=-
"Value B"=-

Slik fjerner du bare standardverdien for nøkkelen HKLM \ SOFTWARE \ Foobar (og dens data):

[HKEY_LOCAL_MACHINE\SOFTWARE\Foobar]
@=-

Linjer som begynner med semikolon regnes som kommentarer:

; This is a comment. This can be placed in any part of a .reg file
[HKEY_LOCAL_MACHINE\SOFTWARE\Foobar]
"Value"="Example string"

Gruppepolicyer

Windows -gruppepolicyer kan endre registernøkler for en rekke maskiner eller individuelle brukere basert på retningslinjer. Når en policy først trer i kraft for en maskin eller for en individuell bruker av en maskin, blir registerinnstillingene som er angitt som en del av policyen, brukt på maskinen eller brukerinnstillingene.

Windows vil også se etter oppdaterte retningslinjer og bruke dem med jevne mellomrom, vanligvis hvert 90. minutt.

Gjennom sitt virkeområde definerer en policy hvilke maskiner og/eller brukere policyen skal brukes på. Hvorvidt en maskin eller bruker er innenfor rammen av en policy eller ikke, er definert av et sett med regler som kan filtrere på plasseringen av maskinen eller brukerkontoen i organisasjonskatalogen, spesifikke brukere eller maskinkontoer eller sikkerhetsgrupper. Mer avanserte regler kan settes opp med uttrykk for Windows Management Instrumentation . Slike regler kan filtrere på egenskaper som dataleverandørnavn, CPU -arkitektur, installert programvare eller nettverk som er koblet til.

For eksempel kan administratoren opprette en policy med ett sett med registerinnstillinger for maskiner i regnskapsavdelingen og policyer med et annet (lock-down) sett med registerinnstillinger for kioskterminaler i besøkerområdet. Når en maskin flyttes fra ett omfang til et annet (f.eks. Endring av navn eller flytting av det til en annen organisasjonsenhet), brukes den riktige policyen automatisk. Når en policy endres, brukes den automatisk på nytt på alle maskiner som for øyeblikket er omfattet.

Retningslinjene redigeres gjennom en rekke administrative maler som gir et brukergrensesnitt for å velge og endre innstillinger. Settet med administrative maler kan utvides, og programvarepakker som støtter slik fjernadministrasjon kan registrere sine egne maler.

Redigering av kommandolinjer

Registeret kan manipuleres på en rekke måter fra kommandolinjen . Den Reg.exeog RegIni.exeverktøyet verktøy er inkludert i Windows XP og nyere versjoner av Windows. Alternative steder for eldre versjoner av Windows inkluderer Resource Kit -CDene eller den originale installasjons -CDen til Windows.

En .REGfil kan også importeres fra kommandolinjen med følgende kommando:

RegEdit.exe /s file

Den /s betyr at filen vil være stille slått sammen til registret. Hvis /sparameteren utelates, blir brukeren bedt om å bekrefte operasjonen. I Windows 98, Windows 95 og minst noen konfigurasjoner av Windows XP får /sbryteren også til RegEdit.exeå ignorere innstillingen i registret som lar administratorer deaktivere den. Når du bruker /sbryteren, RegEdit.exereturnerer ikke en passende returkode hvis operasjonen mislykkes, i motsetning til den Reg.exesom gjør det.

RegEdit.exe /e file

eksporterer hele registret i V5 -format til en UNICODE .REG-fil, mens noen av

RegEdit.exe /e file HKEY_CLASSES_ROOT[\<key>]
RegEdit.exe /e file HKEY_CURRENT_CONFIG[\<key>]
RegEdit.exe /e file HKEY_CURRENT_USER[\<key>]
RegEdit.exe /e file HKEY_LOCAL_MACHINE[\<key>]
RegEdit.exe /e file HKEY_USERS[\<key>]

eksporter bare den angitte (under) nøkkelen (som må være vedlagt i anførselstegn hvis den inneholder mellomrom).

RegEdit.exe /a file

eksporterer hele registret i V4 -format til en ANSI .REG-fil.

RegEdit.exe /a file <key>

eksporterer bare den angitte (under) nøkkelen (som må være vedlagt i anførselstegn hvis den inneholder mellomrom).

Det er også mulig å bruke Reg.exe. Her er et eksempel for å vise verdien av registerverdien Versjon:

Reg.exe QUERY HKLM\Software\Microsoft\ResKit /v Version

Andre kommandolinjealternativer inkluderer et VBScript eller JScript sammen med CScript , WMI eller WMIC.exeog Windows PowerShell .

Registertillatelser kan manipuleres gjennom kommandolinjen RegIni.exeog SubInACL.exeverktøyet. For eksempel kan tillatelsene på HKEY_LOCAL_MACHINE \ SOFTWARE -nøkkelen vises med:

SubInACL.exe /keyreg HKEY_LOCAL_MACHINE\SOFTWARE /display

PowerShell -kommandoer og skript

Bruke PowerShell til å navigere i registret

Windows PowerShell kommer med en registerleverandør som presenterer registret som en stedstype som ligner filsystemet. De samme kommandoene som brukes til å manipulere filer og kataloger i filsystemet kan brukes til å manipulere nøkler og verdier i registret.

I likhet med filsystemet bruker PowerShell konseptet med en nåværende plassering som definerer konteksten som kommandoer som standard fungerer på. Den Get-ChildItem(også tilgjengelig gjennom aliasene ls, direller gci) henter barnetastene til gjeldende plassering. Ved å bruke kommandoen Set-Location(eller aliaset cd) kan brukeren endre gjeldende plassering til en annen nøkkel i registret. Kommandoer som gir nytt navn til elementer, fjerner elementer, oppretter nye elementer eller angir innhold i elementer eller egenskaper, kan brukes til å gi nytt navn til nøkler, fjerne nøkler eller hele undertrær eller endre verdier.

Gjennom PowerShell -skriptfiler kan en administrator forberede skript som, når de kjøres, gjør endringer i registret. Slike skript kan distribueres til administratorer som kan kjøre dem på individuelle maskiner. PowerShell -registerleverandøren støtter transaksjoner, dvs. at flere endringer i registret kan settes sammen i en enkelt atomtransaksjon. En atomtransaksjon sikrer at enten alle endringene er forpliktet til databasen, eller hvis skriptet mislykkes, er ingen av endringene forpliktet til databasen.

Programmer eller skript

Registeret kan redigeres gjennom API -ene til Advanced Windows 32 Base API Library (advapi32.dll).

Mange programmeringsspråk tilbyr innebygde kjøretidsbibliotekfunksjoner eller klasser som pakker inn de underliggende Windows-APIene og derved lar programmer lagre innstillinger i registret (f.eks. Microsoft.Win32.RegistryI VB.NET og C# , eller TRegistryi Delphi og Free Pascal ). COM -aktiverte programmer som Visual Basic 6 kan bruke WSH -objektet WScript.Shell . En annen måte er å bruke Windows Resource Kit Tool Reg.exeved å utføre det fra kode, selv om dette regnes som dårlig programmeringspraksis .

På samme måte muliggjør skriptspråk som Perl (med Win32::TieRegistry), Python (med winreg), TCL (som følger med registerpakken), Windows Powershell og Windows Scripting Host også registerredigering fra skript.

Redigering uten nett

Offreg.dll som er tilgjengelig fra Windows Driver Kit, tilbyr et sett med APIer for oppretting og manipulering av registerlaster som ikke er lastet for øyeblikket lik de som tilbys av advapi32.dll.

Det er også mulig å redigere registret (elveblest) for et frakoblet system fra Windows PE eller Linux (i sistnevnte tilfelle ved hjelp av åpen kildekodeverktøy ).

COM-egenregistrering

Før introduksjonen av registreringsfri COM ble utviklere oppfordret til å legge til initialiseringskode i binære filer i prosessen og ut av prosessen for å utføre registerkonfigurasjonen som kreves for at objektet skal fungere. For binære filer i prosessen som .DLL- og .OCX-filer eksporterte modulene vanligvis en funksjon som heter DllInstall () som kan kalles av installasjonsprogrammer eller aktiveres manuelt med verktøy som Regsvr32.exe; ikke-prosessbinarier støtter vanligvis kommandolinjeargumentene /Regserver og /Unregserver som opprettet eller slettet de nødvendige registerinnstillingene. COM-programmer som går i stykker på grunn av DLL Hell- problemer, kan ofte repareres med RegSvr32.exe eller /RegServer-bryteren uten å måtte installere programmer på nytt.

Avansert funksjonalitet

Windows avslører APIer som lar applikasjoner i brukermodus registrere seg for å motta en varslingshendelse hvis en bestemt registernøkkel endres. APIer er også tilgjengelige for å la applikasjoner i kjernemodus filtrere og modifisere registeranrop fra andre applikasjoner.

Windows støtter også ekstern tilgang til registret på en annen datamaskin via RegConnectRegistryfunksjonen hvis Remote Registry -tjenesten kjører, riktig konfigurert og nettverkstrafikken ikke er brannmur.

Sikkerhet

Hver nøkkel i registret for Windows NT -versjoner kan ha en tilhørende sikkerhetsbeskrivelse . Sikkerhetsbeskrivelsen inneholder en tilgangskontrolliste (ACL) som beskriver hvilke brukergrupper eller individuelle brukere som får eller nektes tilgangstillatelser. Settet med registertillatelser inkluderer 10 rettigheter/tillatelser som eksplisitt kan tillates eller nektes for en bruker eller en gruppe brukere.

Som med andre sikrede objekter i operativsystemet, kan individuelle tilgangskontrolloppføringer (ACE) på sikkerhetsbeskrivelsen være eksplisitte eller arves fra et overordnet objekt.

Windows Ressursbeskyttelse er en funksjon i Windows Vista og senere versjoner av Windows som bruker sikkerhet for å nekte administratorer og systemet WRITE tilgang til noen sensitive nøkler for å beskytte systemets integritet mot skadelig programvare og utilsiktet endring.

Spesielle ACE -er på sikkerhetsbeskrivelsen kan også implementere obligatorisk integritetskontroll for registernøkkelen og undernøkler. En prosess som kjører på et lavere integritetsnivå, kan ikke skrive, endre eller slette en registernøkkel/verdi, selv om prosessen for prosessen ellers har fått tilgang via ACL. For eksempel kan Internet Explorer som kjører i beskyttet modus lese registernøkler/mellomværdige registernøkler/verdier for den påloggede brukeren, men den kan bare endre nøklene med lav integritet.

Utenom sikkerhet kan registernøkler ikke slettes eller redigeres på grunn av andre årsaker. Registernøkler som inneholder NUL -tegn kan ikke slettes med standard registerredaktører og krever et spesielt verktøy for sletting, for eksempel RegDelNull .

Sikkerhetskopiering og gjenoppretting

Ulike utgaver av Windows har støttet en rekke forskjellige metoder for å sikkerhetskopiere og gjenopprette registret gjennom årene, hvorav noen nå er utdatert:

• System Restore kan sikkerhetskopiere registret og gjenopprette det så lenge Windows er oppstartbart, eller fra Windows Recovery Environment (starter med Windows Vista).
• NTBackup kan sikkerhetskopiere registret som en del av systemstatus og gjenopprette det. Automatisert systemgjenoppretting i Windows XP kan også gjenopprette registret.
• I Windows NT kobler alternativet Sist kjente gode konfigurasjon i oppstartsmenyen til HKLM\SYSTEM\CurrentControlSetnøkkelen som lagrer informasjon om maskinvare og enhetsdriver.
• Windows 98 og Windows ME inkluderer kommandolinje (Scanreg.exe) og GUI (Scanregw.exe) registerkontrollverktøy for å kontrollere og fikse integriteten til registret, lage opptil fem automatiske vanlige sikkerhetskopier som standard og gjenopprette dem manuelt eller når korrupsjon er oppdaget. Registerkontrollverktøyet sikkerhetskopierer registret som standard til %Windir%\SysbckupScanreg.exe kan også kjøres fra MS-DOS .
• CD-ROMen med Windows 95 inkluderte et nødgjenopprettingsverktøy (ERU.exe) og et konfigurasjonsverktøy for sikkerhetskopiering (Cfgback.exe) for å sikkerhetskopiere og gjenopprette registret. I tillegg sikkerhetskopierer Windows 95 registret til filene system.da0 og user.da0 ved hver vellykket oppstart.
• Windows NT 4.0 inkludert RDISK.EXE, et verktøy for å sikkerhetskopiere og gjenopprette hele registret.
• Windows 2000 Resource Kit inneholdt et par ikke -støttede verktøy som heter Regback.exe og RegRest.exe for sikkerhetskopiering og gjenoppretting av registret.
• Periodiske automatiske sikkerhetskopier av registret er nå deaktivert som standard på Windows 10 mai 2019 oppdatering (versjon 1903). Microsoft anbefaler at System Restore brukes i stedet.

Politikk

Gruppepolitikk

Windows 2000 og nyere versjoner av Windows bruker gruppepolicy for å håndheve registerinnstillinger via en registerspesifikk klientutvidelse i behandlingsmotoren for gruppepolicy. Retningslinjer kan brukes lokalt på en enkelt datamaskin som bruker gpedit.msc, eller på flere brukere og/eller datamaskiner på et domene som bruker gpmc.msc.

Eldre systemer

Med Windows 95, Windows 98, Windows ME og Windows NT 4.0 kan administratorer bruke en spesiell fil til å bli slått sammen i registret, kalt en policy -fil ( POLICY.POL). Retningslinjefilen lar administratorer forhindre at brukere som ikke er administrator, endrer registerinnstillinger, for eksempel sikkerhetsnivået til Internet Explorer og bakgrunnsbilde på skrivebordet. Retningslinjefilen brukes hovedsakelig i en virksomhet med et stort antall datamaskiner der virksomheten må beskyttes mot useriøse eller uforsiktige brukere.

Standardutvidelsen for policyfilen er .POL. Retningslinjefilen filtrerer innstillingene den håndhever av bruker og gruppe (en "gruppe" er et definert sett med brukere). For å gjøre dette går policyfilen over i registret og forhindrer brukere i å omgå det ved ganske enkelt å endre innstillingene. Retningslinjefilen distribueres vanligvis via et LAN, men kan plasseres på den lokale datamaskinen.

Retningslinjefilen er opprettet av et gratis verktøy av Microsoft som går under filnavnet poledit.exefor Windows 95/Windows 98 og med en datamaskinadministrasjonsmodul for Windows NT. Redaktøren krever at administrative tillatelser kjøres på systemer som bruker tillatelser. Redaktøren kan også direkte endre gjeldende registerinnstillinger for den lokale datamaskinen, og hvis den eksterne registertjenesten er installert og startet på en annen datamaskin, kan den også endre registret på den datamaskinen. Policy -editoren laster inn innstillingene den kan endre fra .ADMfiler, hvorav en er inkludert, som inneholder innstillingene Windows -skallet gir. Den .ADMfilen er vanlig tekst og støtter enkel lokalisering ved at alle strengene som skal lagres på ett sted.

Virtualisering

INI -filvirtualisering

Windows NT-kjerner støtter omdirigering av INI- filrelaterte API-er til en virtuell fil på et registersted, for eksempel HKEY_CURRENT_USER ved hjelp av en funksjon som kalles "InifileMapping". Denne funksjonaliteten ble introdusert for å tillate at eldre programmer skrevet for 16-biters versjoner av Windows kan kjøres under Windows NT-plattformer der systemmappen ikke lenger anses som et passende sted for brukerspesifikke data eller konfigurasjoner. Ikke-kompatible 32-biters programmer kan også omdirigeres på denne måten, selv om funksjonen opprinnelig var beregnet på 16-biters applikasjoner.

Registervirtualisering

Windows Vista introduserte begrenset registervirtualisering, derved at dårlig skrevne programmer som ikke respekterer prinsippet om minst privilegium og i stedet prøver å skrive brukerdata til et skrivebeskyttet systemsted (for eksempel HKEY_LOCAL_MACHINE-bikupen), blir lydløst omdirigert til et mer passende sted , uten å endre selve applikasjonen.

På samme måte omdirigerer applikasjonsvirtualisering alle programmets ugyldige registeroperasjoner til et sted, for eksempel en fil. Brukt sammen med filvirtualisering, lar dette programmer kjøre på en maskin uten å bli installert på den.

Prosesser med lav integritet kan også bruke registervirtualisering. For eksempel vil Internet Explorer 7 eller 8 som kjører i "Beskyttet modus" på Windows Vista og nyere, automatisk omdirigere registret skriver av ActiveX -kontroller til et sandkasset sted for å frustrere noen klasser av sikkerhetsutnyttelser .

Programkompatibilitetsverktøysettet gir mellomlegg som transparent kan omdirigere HKEY_LOCAL_MACHINE eller HKEY_CLASSES_ROOT registeroperasjoner til HKEY_CURRENT_USER for å adressere " LUA " -feil som gjør at applikasjoner ikke fungerer for brukere med utilstrekkelige rettigheter.

Ulemper

Kritikere merket registret i Windows 95 som et enkelt feilpunkt , fordi ominstallering av operativsystemet var nødvendig hvis registret ble ødelagt. Imidlertid bruker Windows NT transaksjonslogger for å beskytte mot korrupsjon under oppdateringer. Gjeldende versjoner av Windows bruker to nivåer av loggfiler for å sikre integritet, selv ved strømbrudd eller lignende katastrofale hendelser under databaseoppdateringer. Selv om det er en feil som ikke kan gjenopprettes, kan Windows reparere eller re-initialisere skadede registeroppføringer under systemoppstart.

Ekvivalenter og alternativer

I Windows er bruk av registeret for lagring av programdata et spørsmål om utviklerens skjønn. Microsoft tilbyr programmeringsgrensesnitt for lagring av data i XML -filer (via MSXML ) eller databasefiler (via SQL Server Compact ) som utviklere kan bruke i stedet. Utviklere står også fritt til å bruke ikke-Microsoft-alternativer eller utvikle sine egne datalagre.

I motsetning til Windows Registry sin binærbaserte databasemodell, bruker noen andre operativsystemer separate tekstfiler for demon og applikasjonskonfigurasjon, men grupperer disse konfigurasjonene for enkel administrasjon.

• I Unix-lignende operativsystemer (inkludert Linux ) som følger filsystemhierarki-standarden , lagres tradisjonelle systemkonfigurasjonsfiler (informasjon som ligner på det som ville vises i HKEY_LOCAL_MACHINE på Windows) tradisjonelt i filer i /etc/og underkataloger, eller noen ganger i /usr/local/etc. Informasjon per bruker (informasjon som vil være omtrent lik den i HKEY_CURRENT_USER) lagres i skjulte kataloger og filer (som starter med en periode/punktum) i brukerens hjemmekatalog . Imidlertid bør XDG -kompatible applikasjoner referere til miljøvariablene som er definert i basiskatalogspesifikasjonen.
• I macOS lagres vanligvis systemdekkende konfigurasjonsfiler i /Library/mappen, mens konfigurasjonsfiler per bruker lagres i den tilsvarende ~/Library/mappen i brukerens hjemmekatalog, og konfigurasjonsfiler som er angitt av systemet er i /System/Library/. I disse respektive kataloger lagrer et program vanligvis en eiendomslistefil i Preferences/undermappen.
• RISC OS (ikke å forveksle med MIPS RISC/os ) bruker kataloger for konfigurasjonsdata, som gjør at applikasjoner kan kopieres til applikasjonskataloger , i motsetning til den separate installasjonsprosessen som karakteriserer Windows -applikasjoner; denne tilnærmingen brukes også på ROX Desktop for Linux. Denne katalogbaserte konfigurasjonen gjør det også mulig å bruke forskjellige versjoner av samme applikasjon, siden konfigurasjonen er gjort "on the fly". Hvis man ønsker å fjerne programmet, er det mulig å slette mappen som tilhører programmet. Dette vil ofte ikke fjerne konfigurasjonsinnstillinger som er lagret uavhengig av programmet, vanligvis i datamaskinens ! Boot -struktur , i! Boot.Choices eller potensielt hvor som helst på en nettverksfilserver. Det er mulig å kopiere installerte programmer mellom datamaskiner som kjører RISC OS ved å kopiere applikasjonskatalogene som tilhører programmene, men noen programmer kan kreve ominstallering, f.eks. Når delte filer plasseres utenfor en applikasjonskatalog.
• IBM AIX (en Unix -variant) bruker en registerkomponent kalt Object Data Manager (ODM). ODM brukes til å lagre informasjon om system- og enhetskonfigurasjon. Et omfattende sett med verktøy og verktøy gir brukerne muligheter til å utvide, kontrollere, korrigere ODM -databasen. ODM lagrer informasjonen i flere filer, standardplasseringen er /etc /objrepos.
• Den GNOME skrivebordsmiljøet bruker et register-lignende grensesnitt kalt dconf for lagring av konfigurasjonsinnstillinger for skrivebordet og applikasjoner.
• Den Elektra Initiative gir alternative back-ender for ulike tekst konfigurasjonsfiler.
• Selv om det ikke er et operativsystem, bruker Wine- kompatibilitetslaget , som lar Windows-programvare kjøre på et Unix-lignende system, også et Windows-lignende register som tekstfiler i WINEPREFIX-mappen: system.reg (HKEY_LOCAL_MACHINE), user.reg ( HKEY_CURRENT_USER) og userdef.reg.

Se også

• Registerrenser
• Applikasjonsvirtualisering
• LOGPARSER - SQL -lignende spørring av ulike typer loggfiler
• Liste over Shell Icon Overlay Identifiers
• Ransomware -angrep som bruker Registry

Merknader

Fotnoter

Referanser

Eksterne linker

• Windows -registerinformasjon og referanse i MSDN -biblioteket