Gdzie instalować małe programy bez instalatorów w systemie Windows?

35

Na platformie Windows większość dużych aplikacji jest dostarczana z własnym instalatorem, który konfiguruje foldery poniżej C:\Program Files, być może w niektórych innych miejscach i być może dodaje klucze rejestru itp.

Ale wciąż istnieje wiele narzędzi, które składają się tylko z, .exea może również z READMEjednego .dlllub dwóch.

Jak mam zainstalować takie narzędzia? Bezpośrednio C:\Program Files? Wszystko w jednym podfolderze pod C:\Program Files? Gdzieś pod C:\Users\Me? Gdzieś zupełnie inaczej?

A może różne podejścia do narzędzi tylko .exez tymi, które mają również inne pliki, a może tylko te z .dlls muszą być traktowane inaczej ...

Czy istnieje jakikolwiek standardowy zaakceptowany sposób? „Najlepsza praktyka”? Jeśli odpowiedź zależy od wersji systemu Windows, korzystam z systemu Windows 7.

W szczególności to, co może uderzyć ludzi jako oczywistą odpowiedź, wydaje się mieć pewien haczyk:

Próbowałem ręcznie utworzyć nowe podfoldery pod C:\Program Files. Właściwie myślałem, że już to zrobiłem, ale Windows wyświetla okno dialogowe Odmowa dostępu do folderu docelowego . To spowodowało, że pomyślałem dwa razy, zamiast ślepo kliknąć Kontynuuj .

Odmowa dostępu do folderu docelowego

Zakładając, że w ciągu wielu lat stawały temu przeciw sobie większe umysły niż moje, chciałbym zapytać społeczność, czy przyjęto jakąś „najlepszą praktykę”.

hippietrail
źródło
3
Z jakiego punktu widzenia zadajesz to pytanie? W szczególności, czy jest to aplikacja, którą piszesz, czy próbujesz zainstalować czyjąś aplikację?
Harry Johnston,
2
@HarryJohnston: Służy do instalowania aplikacji innych osób. Pobrałem kilka programów zaprojektowanych do przeglądania lub edycji bardzo dużych plików, a kilka nie miało instalatorów. Ale to samo dotyczy większości narzędzi wiersza polecenia również w systemie Windows, z których mam kilka.
hippietrail
@UltraDEVV: Chcę wiedzieć, czy inni rozważali ten problem i zdecydowali się na „najlepszą praktykę”. Chcę wiedzieć, jakie są dostępne rozwiązania, zanim zdecyduję się na instalację w C:\Program Filesinnym miejscu i podam informacje na temat potencjalnej bariery dla C:\Program Filesbycia oczywistym rozwiązaniem.
hippietrail
Więc przeczytaj moje! superuser.com/a/815831/354352
UltraDEVV 24.09.14
@UltraDEVV: Już przeczytałem twój i już na niego głosowałem. Fajnie jest patrzeć, jak to pytanie śpiących ożywa po trzy i pół roku odpoczynku!
hippietrail

Odpowiedzi:

25

Posługiwać się C:\Tools

lub C:\Users\<user>\Tools
 

Używam wielu małych programów bez instalatora i zalecam następujące czynności:

  • Zapisz je wszystkie w C:\Tools
  • Jeśli program składa się z jednego pliku, umieść go bezpośrednio pod C:\Tools
  • Jeśli program składa się z wielu plików, umieść go pod C:\Tools\ProgramName
  • Narzędzia SysInternals mają specjalną kategorię, C:\Tools\_SysInternalsponieważ jest ich wiele

Po prostu przenoszę się C:\Toolsz maszyny na maszynę podczas migracji, działa jak urok.

Praktyczna próbka (skrócona lista):

C: \ Tools \ autoexec-elevated.bat
C: \ Tools \ cleanup.bat
C: \ Tools \ BabelMap.exe
C: \ Tools \ netmon.exe
C: \ Tools \ notifu.exe
C: \ Tools \ putty.exe
C: \ Tools \ UDPixel.exe
C: \ Tools \ battery.vbs

C: \ Narzędzia \ 3dclip-1.5.1 \
C: \ Tools \ alternatestreamview \
C: \ Tools \ blender-2.71-windows64 \
C: \ Tools \ Notepad ++ \
C: \ Narzędzia \ QueryExpress \
C: \ Tools \ winscp555 \
C: \ Tools \ Xinorbis \

C: \ Tools \ _Sysinternals \ accesschk \
C: \ Narzędzia \ _Sysinternals \ Autoruns \
C: \ Tools \ _Sysinternals \ zależy22_x64 \
C: \ Narzędzia \ _Sysinternals \ zależy 22_x86 \
C: \ Narzędzia \ _Sysinternals \ LogonSessions \

Mam nadzieję, że to daje pomysł.

EDYCJA: Informacje rozszerzone

Podejrzewam, że w trakcie instalacji w twoim pytaniu Jak mam zainstalować takie narzędzia? masz na myśli ręczną konfigurację, coś w rodzaju kopiowania plików.

Ogólna zasada: użyj ręcznie utworzonych folderów dla ręcznie obsługiwanych plików. Pozwól, aby foldery systemowe były używane przez procesy (instalacyjne), których nie kontrolujesz bezpośrednio. Natychmiast uzyskasz korzyść z rozpoznania, która zawartość jest „twoja” (i możesz ją swobodnie kopiować), a którą aplikacją zarządza instalator.

Dlatego podczas instalacji ręcznej (przez kopiowanie) trzymaj się z dala od

  • C:\Program Files - programy tutaj znalezione nie mogą być po prostu migrowane, muszą zostać ponownie zainstalowane (daje świetną wskazówkę do migracji)
  • C:\Program Files (x86) - jak wyżej, ale w systemach 64-bitowych przechodzą tutaj programy 32-bitowe (może podpowiedzieć, czy konkretna aplikacja jest 32-bitowa, czy 64-bitowa)
  • C:\ProgramData- znalezione tutaj magazyny aplikacji pokazują, że programy te przechowują niektóre ze swoich danych na swój własny sposób. Ale zapytałeś o umieszczenie swoich programów w Data? To nie jest dobry pomysł.
  • C:\Users\Steven\AppData- znowu, umieszczenie programów w Data nie jest dobrym pomysłem. Jeśli zapytałeś o dane, możesz napisać kilka interesujących rzeczy na temat tej ścieżki. Ale w przypadku programów po prostu „nie”. :)

Możliwa ścieżka

  • C:\Users\Steven- może być Twoim alternatywnym rootem, jeśli jest to komputer współużytkowany i chcesz zachować porządek, więc zdecydujesz, że nie będziesz tworzyć globalnych katalogów. Możesz rozważyć C:\Users\Steven\Toolsdla swoich programów lub nawet C:\Users\Steven\Desktop\Toolsjeśli chcesz korzystać z wygodnego dostępu do folderów pulpitu dostępnego za pomocą skrótu z wielu miejsc w systemie Windows. Ale lepiej może być poprzedni i nadal możesz umieścić skrót do tego folderu na pulpicie lub w razie potrzeby.

Edycja: Dodatkowa przydatna wskazówka:

Jeśli chcesz, aby niektóre małe programy były rozpoznawane w menu Start systemu Windows 10 (do przyrostowego wyszukiwania ich nazw lub natychmiastowego podwyższania za pomocą Ctrl+ Shift+ Enter), dodaj tam skróty i uruchom je raz . (Następnie możesz je usunąć.)

miroxlav
źródło
Brzmi dobrze, ale czy jest to poparte dokumentacją najlepszych praktyk, czy coś takiego? Jeśli tak, to naprawdę poprawiłoby odpowiedź.
@DoritoStyle - może być konieczne sprawdzenie aktualnej dokumentacji najlepszych praktyk w firmie. Jeśli znasz jakieś bardziej ogólne dokumenty dotyczące najlepszych praktyk, daj mi znać, a ja to sprawdzę.
miroxlav
1
Używam „C: \ Utility”, ale poza tym używam tego samego podejścia!
Jon Schneider
Czy coś innego, zamiast „Narzędzi”, zadziała równie dobrze: Gdybym użył czegoś takiego jak C:\Otherlub C:\Users\<user>\Other, czy byłoby to uważane za „legalne” jak „Narzędzia”?
Henrik,
@Henrik - ponieważ nie ma standardu, używaj tego, co pasuje do twoich uczuć i jest wystarczająco jasne. Na przykład próbowałem C: \ Progs (nazwa przywołuje małe programy bez instalatora), ale pod koniec dnia wydawało się to nieintuicyjne, więc przywróciłem nazwę z powrotem do Narzędzi.
miroxlav
11

O ile mi wiadomo, nie ma uniwersalnego podejścia.

Umieszczanie aplikacji C:\Program Filesjest dość standardowym sposobem. Dostaniesz ochronę dostępu : zwykli (i nieuprawnieni) użytkownicy nie mogą pisać C:\Program Files. Abyś nie mógł przypadkowo usunąć, zastąpić takich plików; i są lepiej chronione przed wirusami.

Dlatego pojawia się ostrzeżenie - żądanie podniesienia uprawnień - podczas próby utworzenia folderu w C:\Program Files.

Dlatego C:\Program Filesjest najbezpieczniejszym miejscem na pliki wykonywalne.

Jednak nie nadaje się do (przenośnych) aplikacji, które przechowują swoją konfigurację w pobliżu, .exeponieważ nie będą w stanie zapisać zmian konfiguracji.


C:\ProgramDatasłuży do przechowywania danych aplikacji udostępnianych użytkownikom. Domyślnie wszyscy użytkownicy mogą tutaj tworzyć pliki i foldery, ale tylko użytkownik, który je utworzył, może modyfikować pliki.

Z tego folderu można łatwo korzystać w przypadku udostępnianych aplikacji / narzędzi. Jednocześnie nigdy nie widziałem aplikacji w tym folderze.


Jeśli umieścisz aplikacje w swoim profilu użytkownika C:\Users\<username>, inni użytkownicy systemu nie będą mieli do niego dostępu. Masz wszystkie uprawnienia do swojego profilu, więc nie otrzymasz ostrzeżenia o bezpieczeństwie. Właśnie dlatego Chrome instaluje się w profilu użytkownika: może się łatwo aktualizować bez monitowania o podniesienie uprawnień.

W trybie dla użytkownika pakiety Instalatora Windows, .msipliki instalują się w C:Users\<username>\AppData\Microsoft\Installer\<ProductId>. Więc utrzymywanie aplikacji nieudostępnionych w profilu użytkownika jest dość standardowe.

Mam utilsprofil w profilu mojego użytkownika z aplikacjami, które są przydatne tylko dla mnie. Ten folder jest dodawany do PATHzmiennej środowiskowej moich użytkowników w celu łatwego dostępu.

W przypadku aplikacji współdzielonych używam C:\toolslub podobnego katalogu, prawdopodobnie na innym dysku. Jest dodawany do PATHzmiennej globalnej .

Aleksiej Iwanow
źródło
7

Zgadzam się z już udzielonymi odpowiedziami do pewnego momentu. Ale w przypadku naprawdę małych programów (utils) zwykle umieszczam je w folderze bin (w moim przypadku E: \ bin). Programy te są zwykle pojedynczymi plikami exe lub moimi własnymi skryptami w języku Python. Dodaję ten folder do zmiennej PATH, aby móc korzystać z tych programów z wiersza poleceń (z których często korzystam).

del-boy
źródło
Zastanawiałem się również nad stworzeniem generycznego C:\Program Files\bindla tego rodzaju narzędzi i narzędzi. Dzięki za opinie.
hippietrail
5

O ile mi wiadomo, nie ma najlepszych praktyk. To Ty decydujesz, jak chcesz sobie z tym poradzić.

Zazwyczaj stosuję ten sam standard, co każdą aplikację z instalatorem. Jeśli jest to plik wykonywalny lub biblioteka, umieściłbym w którymkolwiek z nich, \Program Files\jeśli jest to 64-bitowy i Program Files (x86)\jeśli to 32-bitowy.

Pliki danych, które zwykle przechowuję w moich Usersfolderach, ponieważ zwykle są one specyficzne dla użytkownika.

Istnieją również aplikacje, takie jak Google Chrome i aplikacje Click-Once, które wdrażają się w nich Users\AppData\, jednak zwykle nie są one dostępne dla wielu profili.

Wolę pierwszą metodę, ponieważ jeśli muszę zalogować się na innym profilu lub jako administrator, nadal mogę uzyskać dostęp do aplikacji.

W odniesieniu do ostrzeżenia o pozwoleniu. To jest dokładnie to ostrzeżenie . Jest to po prostu ostrzeżenie przed użyciem folderu z niewłaściwych powodów, ale nie przeszkadza to w korzystaniu z niego.

BinaryMisfit
źródło
4
Odradzam ręczne instalowanie aplikacji w folderze Program Files, ponieważ aplikacje bez instalatorów są często starsze lub mają inne systemy operacyjne, więc nie zawsze radzą sobie dobrze z miejscem na ścieżce. YMMV.
Harry Johnston,
3
Nie polecam też ręcznego instalowania niczego %ProgramFiles%, ale z innego powodu: aplikacje bez instalatorów są często przenośne i nie masz tam uprawnień do zapisu
kinokijuf
4

Jeśli chcesz ujednolicić te aplikacje, sugeruję użycie standardów pakietu Chocolatey . Jest to dobre z wielu różnych powodów; głównie dlatego, że duża część oprogramowania została już spakowana i jest gotowa do zainstalowania z dowolnego miejsca za pomocą kilku poleceń.

Łatwo jest również tworzyć własne pakiety dla aplikacji, których nie można swobodnie dystrybuować. Prawdopodobnie masz prawo do rozpowszechniania wszystkiego, co posiadasz we własnej sieci; więc dla tych aplikacji możesz skonfigurować lokalne repozytorium . Jeśli zarządzasz wieloma komputerami lub masz ograniczone pasmo internetowe, może to być pomocne nawet w przypadku darmowych rzeczy.

krowe
źródło
2

Jeśli wybierzesz domyślne opcje instalacji cygwin, umieści wszystkie twoje pliki w katalogu c: \ cygwin. Przyjąłbym to samo podejście. Osobiście mam folder ac: \ apps. W przeszłości używałem c: \ utils i c: \ cli (skrót od wiersza poleceń). To naprawdę zależy od tego, jak chcesz uporządkować swoje pliki. Sugerowałbym, aby narzędzia jednorazowe umieściły je w folderze catchall. Jeśli chodzi o zestaw narzędzi (np. Cygwin, sysinternals, rktools), czy mógłbym zasugerować własny podfolder. Na przykład możesz umieścić wszystkie sysinternals w c: \ apps \ sysinternals. Jeśli zainstalujesz cygwin, zajmie to większość (jeśli nie wszystkie) poleceń Uniksa, które pokochałeś.

Pamiętaj, aby zmienić zmienne środowiskowe (Start> Panel sterowania> System> Zaawansowane> Zmienne środowiskowe) i dołączyć nowe ścieżki aplikacji do zmiennej systemowej PATH. Umożliwia to uruchamianie ich na żądanie z wiersza polecenia lub przy użyciu systemu Windows + R (polecenie uruchomienia).

Słońce
źródło
5
Myślę, że programiści Cygwin nie dbają o standardy Windows i kopiowanie złych nawyków (tworzenie folderów w katalogu głównym) jest błędem. Czuję się jak tworzenie \Program Fileskatalogu w systemie Linux.
Kamil
Nie wiem, dlaczego to byłoby złe. Cygwin jest przeznaczony dla środowiska uniksowego. Dlaczego Cygwin miałby spełniać standardy Windows, skoro są przeznaczone dla osób, które chcą korzystać z narzędzi uniksowych?
niedz.
@Sun dokładnie! OP poprosił o najlepsze praktyki Windows.
1

C:\Users\Me\toolName(alias% homepath% \ toolName) to właściwe miejsce do umieszczenia narzędzi, zakładając, że chcesz je dla Meużytkownika, ponieważ niektóre z tych narzędzi zapisują pliki (tymczasowe) i będą wymagały zgody użytkownika w celu zapisu do Program filesfolderu. Kolejnym plusem jest to, że nie zapomnisz go wykonać, ponieważ jest już w przestrzeni użytkownika.

Elazaron
źródło
2
Chciałbym użyć %homepath%' rather than c: \ users \ me`. Wskazuje to właściwą lokalizację, nawet jeśli domyślna lokalizacja została przeniesiona, a zatem jest bardziej przenośna. +1 za część pisania / temp.
Hennes,
stoję poprawiony i zredagowany w związku z tym, że został dodany, a nie zastąpiony, aby odpowiedzieć tymi samymi terminami, co pytanie, dzięki Hennes :)
Elazaron
0

Nie ma żadnych zasad na ten temat, możesz zainstalować je gdziekolwiek chcesz, ale instalowanie ich na OSP (partycja systemu operacyjnego) w folderze innym niż użytkownik jest ogólnie dobrym pomysłem, ponieważ otrzymasz takie same zabezpieczenia dostępu czy masz inne aplikacje; utrudnia to przypadkowe usunięcie lub zmodyfikowanie ich przez osobę trzecią (np. wirus).

Osobiście zwykle umieszczam program w „C: \ Program Files (x86)”, ponieważ większość takich programów, które napotkałem, są 32-bitowe, ale jeśli byłby to program 64-bitowy, umieściłbym go w C: \ Program Files ” Jeśli jest to program związany z systemem (np. Imagex.exe), to umieszczę go w „C: \ Windows \ system32” dla programów 32-bitowych i „C: \ Windows \ system32” dla programów 64-bitowych, aby umożliwić łatwiejszy dostęp z wiersz poleceń podczas uruchamiania wierszy polecenia z podwyższonym poziomem uprawnień, ponieważ domyślnie uruchamiasz w C: \ Windows \ system32 "; oznacza to, że możesz wpisać „name.exe” zamiast C: \ location \ name.exe ”, aby uruchomić program.

Niektóre osoby wolą oddzielić swoje programy przenośne (nie wymaga instalacji lub wykonywać nienadzorowanych zmian poza jego folderem) oraz programy nie oparte na instalatorach (nie są przenośne, ale nie wymagają użycia instalatora) od zwykłych programów, tworząc nowy katalog na ich OSP (np .: C: \ Portable Program Files (x86) lub C: \ Dumpable Program Files (x86). Radziłbym 2 z 2 ze względu na większy poziom dokładności, nawet jeśli nie brzmi jak ładny.

Podsumowując, nie ma żadnych reguł, jednak jeśli zainstalujesz je w OSP (w folderze innym niż użytkownik), będziesz w stanie pomóc chronić program przed niepożądanym odinstalowaniem / modyfikacjami (w tym złośliwymi modyfikacjami), aw niektórych okolicznościach organizacja może być korzystna (np .: wspomniany wcześniej folder system32 dla systemowych programów CLI).

Robin Hood
źródło
1
Myślę, że zasadniczo źle zrozumiałeś pytanie. Pierwsza część pierwotnego pytania brzmi „najlepsza praktyka”, a nie „jakie są zasady”.
Steven Penny
@StevenPenny Wcale nie, po prostu inne sformułowanie. Chodzi o to, dlaczego warto zrobić X lub nie.
Robin Hood
Właśnie wymyśliłem coś, co mi się podoba: Etclub Etceterajeśli wolisz prawdziwe fantazyjne bratki łacińskie. Zastanawiałem się też nad drugim miejscem Misc. Ale Etcpodpisał umowę dla mnie. :)
Henrik,
0

Myślę, że utworzenie skrótu do C:\Toolsw Send Tomenu w Windows jest najlepszą opcją, ponieważ jest zawsze dostępne z dowolnego miejsca. W ten sposób możesz szybko „zainstalować” swoje małe programy, klikając je prawym przyciskiem myszy i wybierając Narzędzia z menu Wyślij do z dowolnego miejsca w systemie Windows.

Mam ten samouczek na temat dodawania do menu Wyślij do z HowToGeek Wklejam
podsumowanie:

Aby dostać się do folderu SendTo, musisz otworzyć okno Eksploratora, a następnie wkleić następujące elementy do paska adresu.

% APPDATA% \ Microsoft \ Windows \ SendTo

Następnie wklej skrót do folderu, w którym chcesz skopiować swoje programy.

Następnie za każdym razem, gdy pobierasz nową aplikację przenośną, po prostu rozpakuj ją i wyślij w to miejsce.
Jedynym problemem jest tworzenie skrótów, które moim zdaniem warto to zrobić ręcznie.
Pozdrowienia.

UltraDEVV
źródło
Wyślij do folderu nie jest tak naprawdę nadaje się do wykorzystania jako miejsca do zainstalowania programu. Ma on konkretny cel, mianowicie umożliwienie wysyłania plików / dokumentów do dalszej obsługi przez program (np. Otwarcie pliku w Notatniku). Ponadto wszystkie pliki umieszczone w folderze Wyślij do pojawią się w menu kontekstowym systemu Windows, w tym obsługujące pliki .DLL. W większości przypadków jest to oczywiście niepożądane.
Mówię: Przywróć Monikę
1
Nie. Wygląda na to, że ty i wszyscy downvoters nie zrozumieliście, co miałem na myśli. Mam na myśli Dodaj skrót na przykład C:\Tools\ do Send Tofolderu i uzyskaj do niego dostęp z dowolnego miejsca, wtedy nie będziesz miał kłopotów z ręcznym kopiowaniem każdego z programów. Moja odpowiedź prawdopodobnie przyspieszy proces radzenia sobie z innymi rzeczami i innymi. To działa dla mnie świetnie.
UltraDEVV,
Dokonałem możliwej edycji, aby uwzględnić to dodatkowe wyjaśnienie w odpowiedzi. Odpowiedzi są głosowane w górę / w dół na podstawie odpowiedzi, niekoniecznie na podstawie szczegółów zawartych w komentarzach, więc mam nadzieję, że to pomoże.
Mówię: Przywróć Monikę
Nie, począwszy od systemu Windows Vista, %APPDATA%zmienna jest zrootowana w %USERPROFILE%\AppData\Roamingfolderze, więc w przypadku systemu Windows 7 powyższa ścieżka jest poprawna. W systemie Windows XP należy jednak dodać folder mobilny, jak wskazano.
Mówię: Przywróć Monikę
Jeśli uważasz, że twoje pytanie nie jest jasne, powinieneś je wyjaśnić. Dlaczego przesłałeś dwie odpowiedzi?
Ramhound,
0

Domyślna zmienna środowiskowa ścieżki systemowej w systemie Windows jest podobna (w zależności od zainstalowanej wersji systemu Windows):

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

Spośród tych opcji% SystemRoot% (który zwykle jest C:/) wydaje się najlepszym wyborem do odczytu / zapisu, a później będzie można łatwo do niego odwoływać.


źródło