Kiedy - i dlaczego - należy przechowywać dane w rejestrze systemu Windows?

126

Jako programista narzędzia przechowujące konfigurację / opcje w rejestrze są zmorą mojego życia. Nie mogę łatwo śledzić zmian w tych opcjach, nie mogę łatwo przenosić ich z komputera na komputer, a to wszystko sprawia, że ​​naprawdę tęsknię za starymi, dobrymi czasami plików .INI ...

Pisząc własne aplikacje, co - jeśli w ogóle - powinienem umieścić w rejestrze zamiast w staromodnych plikach konfiguracyjnych i dlaczego?

Roddy
źródło
Obecnie pracuję ze starszą aplikacją, która przechowuje informacje w rejestrze (aplikacja .NET) i doprowadza mnie to do szału.
George Stocker,

Odpowiedzi:

75
  • Pierwotnie konfiguracja (WIN3) była przechowywana w pliku WIN.INI w katalogu systemu Windows.
  • Problem: WIN.INI urósł za duży.
  • Rozwiązanie (Win31): pojedyncze pliki INI w tym samym katalogu co program.
  • Problem: Ten program może być zainstalowany w sieci i współdzielony przez wiele osób.
  • Rozwiązanie (Win311): pojedyncze pliki INI w katalogu Windows użytkownika.
  • Problem: Wiele osób może współdzielić folder Windows, a mimo to powinien on być tylko do odczytu.
  • Rozwiązanie (Win95): Rejestr z oddzielnymi sekcjami dla każdego użytkownika.
  • Problem: Rejestr urósł za duży.
  • Rozwiązanie (WinXP): duże bloki pojedynczych danych przeniesione do folderu danych aplikacji użytkownika.
  • Problem: Dobre w przypadku dużych ilości danych, ale raczej złożone w przypadku małych ilości.
  • Rozwiązanie (.NET): niewielkie ilości stałych, tylko do odczytu danych przechowywanych w plikach .config (Xml) w tym samym folderze co aplikacja, z interfejsem API do ich odczytu. (Dane do odczytu / zapisu lub dane użytkownika pozostają w rejestrze)
James Curran
źródło
16
Unix: konfiguracja przechowywana w $ HOME / .your-app Tam, rozwiązana w jednej iteracji.
Leonel
33
Rozwiązanie uniksowe też jest dalekie od ideału: $ HOME jest przepełniony plikami z kropkami i nie masz pojęcia, co robi większość z nich.
grep
2
@Leonel XDG faktycznie nakazuje umieszczenie plików konfiguracyjnych w środku $HOME/.config/your-app/, rozwiązanie stworzone, aby poradzić sobie z problemem obiektów @grep. I, niespodzianka, nowoczesny Linux (i każdy na * BSD jest na tyle szalony, by używać GNOME) również ma rejestr w gconfpakiecie. FOSS hoduje wybory, to na pewno;)
nowość123456
1
@grep, Re „ nie mam pojęcia, co robi większość z nich ”, dlaczego nie? Poza tym wzdęcie jest prawie niemożliwe do porównania z systemem Windows.
Pacerier,
16

Patrząc na to zarówno z perspektywy użytkownika, jak i programisty, muszę powiedzieć, że naprawdę nie ma dobrego powodu, aby umieścić coś w rejestrze, chyba że jest to coś w rodzaju skojarzeń plików lub ustawień specyficznych dla komputera.

Wywodzę się ze szkoły myślenia, która mówi, że program powinien być uruchamiany z dowolnego miejsca, w którym jest zainstalowany, że instalacja powinna być całkowicie przenośna w obrębie maszyny lub nawet na inną maszynę i nie wpływać na jej działanie.

Wszelkie konfigurowalne opcje, wymagane biblioteki DLL itp., Jeśli nie są udostępniane, powinny znajdować się w podkatalogu katalogu instalacyjnego, aby można było łatwo przenieść całą instalację.

Używam wielu mniejszych narzędzi, takich jak programy, więc jeśli nie można go zainstalować na pendrive'ie i podłączyć do innego komputera i po prostu uruchomić, to nie jest dla mnie.

Jimoc
źródło
4
Jednak instalacja jest często wykonywana pod kontrolą administratora, podczas gdy aktualizacja ustawień musi odbywać się pod kontrolą użytkownika. Wyobraź sobie, że próbujesz zaktualizować ustawienia - aplikację działającą pod tożsamością użytkownika, która chce pisać w katalogu, który jest ograniczony tylko do uprawnień administratora. Jest to jedna z rzeczy, które rejestr ma rozwiązać.
Cheeso
@Cheeso, rozwiązaniem jest, aby każdy użytkownik miał kopię pliku wykonywalnego. Aby zaoszczędzić miejsce, a nie prawdziwą kopię, ale tylko fałszywą kopię (wskaźnik).
Pacerier
12

Polityka firmy Microsoft:

  • Przed Windows 95 używaliśmy plików ini do danych aplikacji.
  • W erze Windows 95 - XP korzystaliśmy z rejestru.
  • W systemie Windows Vista używamy plików ini, chociaż są one teraz oparte na formacie XML.

Rejestr jest zależny od komputera. Nigdy mi się to nie podobało, ponieważ robi się powoli i prawie niemożliwe jest znalezienie tego, czego potrzebujesz. Dlatego lubię proste pliki ini lub inne pliki ustawień. Wiesz, gdzie się znajdują (folder aplikacji lub folder użytkownika), więc są łatwe w przenoszeniu i czytelne dla człowieka.

Toon Krijthe
źródło
1
Czy możesz podać oryginalne łącze do dokumentu opisującego te zasady firmy Microsoft? A kiedy mówisz o zasadach, masz na myśli to, co robi Microsoft, czy masz na myśli to, co Microsoft zaleca programistom, którzy tworzą aplikacje dla systemu Windows?
Cheeso
1
ps: raymond Chen z Microsoft stwierdził, że pliki INI są przestarzałe na rzecz Rejestru i wyjaśnia dlaczego. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx Twierdzi również, że pliki XML mają wiele takich samych wad jak pliki ini.
Cheeso
8
Pliki ustawień XML = pliki INI, które są trudniejsze do przeanalizowania
Robert Fraser,
3
@Fraser Jeśli uważasz, że analizowanie XML jest trudne, to jesteś w złym interesie.
SnakeDoc,
@SnakeDoc, Harder nie znaczy trudniej. Oznacza to po prostu wolniejsze analizowanie i opóźnienia.
Pacerier,
12

Kiedy - jesteś zmuszony ze względu na starszą integrację lub dlatego, że administrator systemu Twojego klienta mówi „tak powinno być” lub ponieważ tworzysz program w starszym języku, który utrudnia korzystanie z XML.

Czemu Przede wszystkim dlatego, że rejestr nie jest tak przenośny, jak kopiowanie pliku konfiguracyjnego, który znajduje się obok aplikacji (i nazywa się prawie tak samo).

Jeśli używasz .Net2 +, masz pliki App.Config i User.Config i nie musisz rejestrować bibliotek DLL w rejestrze, więc trzymaj się od nich z daleka.

Pliki konfiguracyjne mają swoje własne problemy (patrz poniżej), ale można je zakodować i zmienić architekturę.

  • Problem: aplikacje wymagały ustawień konfigurowalnych.
  • Rozwiązanie: Zapisz ustawienia w pliku (WIN.INI) w folderze Windows - użyj nagłówków sekcji, aby pogrupować dane (Win3.0).
  • Problem: plik WIN.INI urósł za duży (i zaczął się brudzić).
  • Rozwiązanie: Zapisz ustawienia w plikach INI w tym samym folderze co aplikacja (Win3.1).
  • Problem: potrzebne są ustawienia specyficzne dla użytkownika.
  • Rozwiązanie: Zapisz ustawienia użytkownika w plikach INI specyficznych dla użytkownika w katalogu Windows użytkownika (Win3.11) lub sekcjach specyficznych dla użytkownika w pliku INI aplikacji.
  • Problem: Bezpieczeństwo - niektóre ustawienia aplikacji muszą być tylko do odczytu.
  • Rozwiązanie: Rejestr z zabezpieczeniami oraz sekcjami dotyczącymi użytkownika i całego komputera (Win95).
  • Problem: Rejestr urósł za duży.
  • Rozwiązanie: Rejestr specyficzny dla użytkownika został przeniesiony do user.dat we własnym folderze „Dane aplikacji” użytkownika i załadowany tylko przy logowaniu (WinNT).
  • Problem: W dużych środowiskach korporacyjnych logujesz się na wielu komputerach i musisz skonfigurować KAŻDY.
  • Rozwiązanie: Rozróżnij profile lokalne (ustawienia lokalne) i profile mobilne (dane aplikacji) (WinXP).
  • Problem: nie można xcopy wdrożyć lub przenieść aplikacji, tak jak reszta .Net.
  • Rozwiązanie: Plik APP.CONFIG XML w tym samym folderze co aplikacja - łatwy do odczytania, łatwy w manipluacji, łatwy do przenoszenia, możliwość śledzenia zmian (.Net1).
  • Problem: Nadal trzeba przechowywać dane specyficzne dla użytkownika w podobny sposób (tj. Wdrażanie xcopy).
  • Rozwiązanie: plik XML USER.CONFIG w folderze lokalnym lub mobilnym użytkownika i wpisany jednoznacznie (.Net2).
  • Problem: w plikach CONFIG rozróżniana jest wielkość liter (nie jest to intuicyjne dla ludzi), wymagają bardzo konkretnych „tagów” ​​otwierania / zamykania, parametrów połączenia nie można ustawić w czasie wykonywania, projekty konfiguracyjne nie mogą zapisywać ustawień (tak łatwo jak w rejestrze), nie można ich łatwo określić Plik user.config i ustawienia użytkownika są wydmuchiwane przy każdej zainstalowanej nowej wersji.
  • Rozwiązanie: Użyj elementu członkowskiego ITEM, aby ustawić parametry połączenia w czasie wykonywania, napisz kod w klasie Instalator, aby zmienić App.Config podczas instalacji i użyj ustawień aplikacji jako domyślnych, jeśli nie zostanie znalezione ustawienie użytkownika.
AndrewD
źródło
Jest to o wiele pełniejsza odpowiedź niż zatwierdzona. Dzięki @ AndrewD.
rotman
8

Czy świat się skończy, jeśli zapiszesz kilka pozycji okien i listę ostatnio używanych elementów w rejestrze systemu Windows? Jak na razie działa dobrze.

HKEY-CURRENT-USER to świetne miejsce do przechowywania banalnych danych użytkownika w niewielkich ilościach. Po to jest. Wydaje się głupie, aby nie używać go zgodnie z jego przeznaczeniem tylko dlatego, że inni go nadużyli.

Angus Glashier
źródło
i świetnie się psuje ... to plus. Mniej pracy dla użytkownika ...
SnakeDoc,
4

Ustawienia, które chcesz mieć dostępne w profilu mobilnym użytkownika, powinny prawdopodobnie trafić do rejestru, chyba że faktycznie chcesz spróbować ręcznie wyszukać folder danych aplikacji użytkownika. :-)

Chris Jester-Young
źródło
4

Odczyty i zapisy rejestru są bezpieczne wątkowo, ale pliki nie. Zależy to więc od tego, czy Twój program jest jednowątkowy, czy nie.

Jaskółka oknówka
źródło
2

Jeśli tworzysz nową aplikację i zależy Ci na przenośności, NIGDY nie powinieneś przechowywać danych w rejestrze systemu Windows, ponieważ inny system operacyjny nie ma rejestru (Windows) (uwaga - może to być oczywiste, ale często jest pomijane).

Jeśli tworzysz tylko dla platform Win ... staraj się tego unikać tak bardzo, jak to możliwe. Pliki konfiguracyjne (prawdopodobnie zaszyfrowane) są o wiele lepszym rozwiązaniem. Nie ma korzyści z przechowywania danych w rejestrze - (izolowana pamięć jest znacznie lepszym rozwiązaniem, na przykład, jeśli używasz .NET).

JohnIdol
źródło
To częściowo prawda. Mono zaimplementowało przestrzeń nazw Microsoft.win32 dla rejestrów - z wyjątkiem tego, że przechowuje ją w pliku w ~ / .mono / Registry w pliku xml i jest obsługiwana w sposób przezroczysty. Teraz, gdybyś mógł włączyć obsługę XML dla dowolnej aplikacji, niezależnie od platformy ...
Robert P
Uwaga: dostępne tylko wtedy, gdy piszesz aplikację .NET / Mono.
Robert P
Rejestr daje korzyści: dane są łatwiej dostępne w aplikacji wielowątkowej. Co ważniejsze, pozwala oddzielić dane konfiguracyjne, które są specyficzne dla komputera, od danych dotyczących użytkownika. Twoja aplikacja nie musi wiedzieć, kto jest zalogowany, gdy uzyskuje dostęp do HKEY_CURRENT_USER. Masz jednak rację co do przenośności.
James
2

Trochę nie na temat, ale ponieważ widzę ludzi zaniepokojonych przenośnością, najlepszym podejściem, jakiego kiedykolwiek używałem, jest klasa QSettings w Qt. Ogranicza przechowywanie ustawień (rejestr w systemie Windows, plik preferencji XML w systemie Mac OS i pliki Ini w systemie Unix). Jako klient zajęć nie muszę tracić czasu na zastanawianie się nad rejestrem czy czymkolwiek innym, to Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

rlerallut
źródło
Wygląda na to, że adres URL już nie działa. Odniesienie do aktualizacji powinno brzmieć qt-project.org/doc/qt-5/QSettings.html#details
Eineki
0

Zwykle, jeśli nie umieszczasz ustawień w rejestrze, używasz go głównie do pobierania aktualnych ustawień systemu Windows, zmiany skojarzeń plików itp.
Teraz, jeśli chcesz wykryć, czy oprogramowanie jest już zainstalowane, możesz zrobić minimalny wpis w rejestrze , to lokalizacja, którą możesz znaleźć w dowolnej konfiguracji. Lub wyszukaj folder o podanej nazwie w danych aplikacji.

Jeśli spojrzę na mój folder Document and Settings, widzę wiele programów używających uniksowej notacji kropkowej do ustawiania folderów: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary. .jindent .jogl_ext (itp.)

oraz w danych aplikacji, różne foldery z nazwami redaktorów lub nazwami oprogramowania. Wygląda na to, że jest to aktualny trend, przynajmniej wśród aplikacji przenośnych ...
WinMerge używa nieco innego podejścia, przechowując dane w rejestrze, ale oferując opcje importu i eksportu w oknie konfiguracji.

PhiLho
źródło
Notacja kropkowa systemu Unix, którą widzisz, prawdopodobnie wynika z tego, że wszystkie te przykłady dotyczą przeniesionych projektów typu open source, a nie dlatego, że jest to najlepsza praktyka w programowaniu w systemie Windows.
James
Rzeczywiście, nie powiedziałem, że to „najlepsza praktyka”, ale powszechna praktyka ... :) Foldery w danych aplikacji / są / najlepsze praktyki, szczególnie w przypadku dużych zbiorów danych, ale także dlatego, że są one łatwiejsze do tworzenia kopii zapasowych.
PhiLho
0

Osobiście korzystałem z rejestru do przechowywania ścieżek instalacji do użycia przez skrypty (nie) instalacyjne. Nie jestem pewien, czy jest to jedyna możliwa opcja, ale wydawało się to rozsądnym rozwiązaniem. Dotyczyło to oczywiście aplikacji, która była używana wyłącznie w systemie Windows.

chillysapien
źródło
0

(późno do dyskusji, ale) Krótka odpowiedź: Zasady grupy.

Jeśli dział IT klienta chce wymusić ustawienia związane z systemem Windows lub komponentami, które piszesz lub w których piszesz, takie jak szybkość łącza, niestandardowy komunikat o błędzie lub serwer bazy danych, z którym chcesz się połączyć, nadal jest to zazwyczaj odbywa się za pośrednictwem zasad grupy, co ostatecznie objawia się jako ustawienia przechowywane w rejestrze. Takie zasady są wymuszane od momentu uruchomienia systemu Windows lub zalogowania się użytkownika.

Istnieją narzędzia do tworzenia niestandardowych szablonów ADMX, które mogą mapować ustawienia komponentów do lokalizacji w rejestrze i zapewniają administratorowi wspólny interfejs do egzekwowania zasad, które musi egzekwować, pokazując im tylko te ustawienia, które są istotne do wymuszenia w ten sposób.

Spencer
źródło
-1

Uważam, że Rejestr systemu Windows był dobrym pomysłem, ale z powodu wielkich nadużyć ze strony twórców aplikacji i standardowych zasad, których Microsoft nie zachęcał / nie nakazał, stał się bestią, której nie da się opanować. Nienawidzę go używać z powodów, o których wspomniałeś, są jednak sytuacje, w których ma sens:

  • Pozostawienie śladu aplikacji po odinstalowaniu aplikacji (np. Zapamiętanie preferencji użytkownika w przypadku ponownej instalacji aplikacji)
  • Współdziel ustawienia konfiguracji między różnymi aplikacjami - komponentami
kgiannakakis
źródło
5
Nie zgadzam się z Tobą co do pierwszego punktu, „[a] pozostawiając ślad aplikacji po jej odinstalowaniu”. Wolałbym, aby gdy powiem „usuń się z mojego systemu”, Twoja aplikacja będzie całkowicie zgodna. Przypuszczam, że byłoby inaczej, gdybyś zapytał użytkownika, czy można coś zostawić, ale nawet wtedy prawdopodobnie chciałbym, aby był to zapisany plik konfiguracyjny. Niezależnie od licencji itp., Jeśli sprzedajesz komputer i kupujesz nowy, czy nie wolałbyś mieć pliku ustawień, który możesz załadować podczas nowej instalacji, zamiast czegoś powiązanego z komputerem, który sprzedajesz?
AgentConundrum
2
Wiele aplikacji to robi i masz rację, mówiąc, że nie jest to zbyt dobra rzecz, zwłaszcza jeśli robią to bez zgody użytkownika. Jednak często jest to funkcja, której użytkownicy oczekują od aplikacji (większość użytkowników nie wie, czym jest rejestr). Użytkownicy oczekują po prostu, że ich ustawienia zostaną automatycznie przywrócone po ponownym odinstalowaniu i zainstalowaniu.
kgiannakakis
2
Myślę, że znaleźliśmy tutaj autora złośliwego oprogramowania. Nigdy nie zostawiaj bzdur ze swojego programu w czyimś systemie, jeśli poprosił cię o odinstalowanie. Przynajmniej zapytaj ich, czy chcą zapamiętać ustawienia itp. Nigdy tego po prostu nie rób. A jeśli przechowujesz klucz licencyjny, a ja sprzedam swój komputer? A jeśli Twój program powodował problemy na moim komputerze i próbowałem go odinstalować, aby go naprawić? Cóż, resztki twojego rejestru mogą przysporzyć mi wielu problemów. Po prostu tego nie rób. Po prostu nie.
SnakeDoc,