Skąd okno dialogowe Uruchom wie, gdzie są aplikacje?

72

Jako zaawansowany użytkownik często używam okna dialogowego Uruchom.

Rozumiem, dlaczego działają następujące polecenia, ponieważ znajdują się one w PATHzmiennej środowiskowej.

mspaint
diskmgmt.msc
explorer

Te polecenia działają również w CMD.

Poniższe polecenia działają w biegu, ale ich nie ma PATHi nie działają w CMD.

firefox
winword
iexplore

Skąd program Run wie, gdzie są te pliki?

windows run-dialog mt025
źródło

Odpowiedzi:

90

Po wykonaniu polecenia z okna dialogowego Uruchom system sprawdza App Pathstutaj klucz rejestru:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

i

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

PRZYKŁAD

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\filezilla.exe

(default) dane wartości mają pełną ścieżkę do pliku wykonywalnego.

Jeśli nie zostanie znaleziony, sprawdza każdy folder zawarty w ŚCIEŻCE.

Natomiast wiersz polecenia nie odwołuje się do tych kluczy rejestru. Przeszukuje tylko ŚCIEŻKĘ.

w32sh
źródło
5
Ach, to prawdopodobnie wyjaśnia, dlaczego nie możesz mieć wielu programów o tej samej nazwie, które działają jako otwarte z opcjami. Zły design.
curiousdannii
2
Tak, prawie. Ale Otwórz w oknie dialogowym czyta z HKCR\ApplicationsiRegisteredApplications
w32sh
4
Microsoft udostępnił film na ten temat: channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-133-App-Paths
magicandre1981
6
Możesz oczywiście użyć startwbudowanego narzędzia, które wyszukuje ścieżki aplikacji.
Neil,
1
Jest to dość dobrze udokumentowane tutaj . Wyjaśniłem również, w jaki sposób cmd wykonuje tutaj swoje wyszukiwanie - to trochę szczególny przypadek inny niż interfejsy API Win32.
Bob
4

Odpowiedź w32sh poprawnie wskazuje, że dodatkowe klucze wyszukiwane w oknie dialogowym Uruchom są tutaj:

  • HKEY_CURRENT_USER \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ App Paths \
  • HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ App Paths \

Istnieje oficjalna dokumentacja tych ścieżek .

Ważnym faktem na temat tych kluczy jest to, że nazwa klucza (np. „Filezilla.exe”) nie musi w żaden sposób pasować do pełnej ścieżki. W systemie Windows 7 wartością może być nawet prosty wiersz polecenia, podobny do tego, który może być użyty jako „cel” skrótu.

Na przykład miałem to w swoim rejestrze:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\jedit.exe]
@="\"C:\\WINDOWS\\system32\\javaw.exe\" -Xms24M -Xmx512M -jar \"C:\\Program Files\\jEdit\\jedit.jar\" -reuseview"

Nie mogę sprawić, by działało to w systemie Windows 10, ale nadal możesz wskazać dowolny plik, w tym plik wsadowy, np

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\jedit.exe]
@="C:\\Program Files\\jEdit\\run-jedit.bat"

Pozwala to wpisać „jedit” lub „jedit C: \ foo \ bar \ coś.txt”, aby uruchomić JVM z odpowiednimi opcjami i uruchomić / ponownie użyć jEdit .

O ile widzę, nazwa klucza musi kończyć się na „.exe”, więc aby utworzyć alias „abc”, należy utworzyć klucz „abc.exe”, nawet jeśli nie wskazuje on pliku „.exe” .

IMSoP
źródło
Nie działa tutaj, jeśli użyję dodatkowych przełączników po nazwie pliku wykonywalnego.
w32sh,
@ w32sh Hm, myślę, że to się zmieniło w Win 10 :(
IMSoP
-1

W wierszu poleceń znajduje się zmienna środowiskowa o nazwie PATH lub% PATH%. Zawiera serię lokalizacji do przeszukania.

Garhoogin
źródło