Jakie rozszerzenia plików w systemie Windows oznaczają plik wykonywalny?

W systemie Windows * .exe, * .bat, * .cmd i * .com wszystkie reprezentują programy lub skrypty powłoki, które można uruchomić, po prostu klikając je dwukrotnie. Czy istnieją inne rozszerzenia plików wskazujące, że plik jest wykonywalny?

EDYCJA : Kiedy wskakuję do nowego projektu (lub wracam do starego projektu!), Jedną z typowych rzeczy, które chcę robić, kiedy się rozglądam, jest sprawdzenie, jakie są dostępne narzędzia. W systemie Unix (którego używam od dziesięcioleci) jest wykonywalny, więc jest to tak proste, jak:

find . -executable -type f

Doszedłem do wniosku, że w systemie Windows, który wydaje się mieć znacznie bardziej skomplikowany mechanizm „jest to plik wykonywalny (i jak go wykonać)”, istnieje stosunkowo niewielka liczba rozszerzeń nazw plików, które służyłyby mniej więcej temu samemu celowi.

Dla mojego obecnego projektu *.exe *.bat *.cmdprawie na pewno wystarcza, ale pomyślałem, że zapytam, czy istnieje wiarygodna lista.

Podstawowe pliki „wykonywalne” (te, które Windows chce wykonać za pomocą PATH) są przechowywane w zmiennej środowiskowej o nazwie PATHEXT. Możesz to zobaczyć w wierszu polecenia:

C:\>set PATHEXT

Na moim komputerze otrzymuję to (WinXP):

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1

To nie jest wyłączna lista. Windows wykona również inne pliki (na przykład wygaszacze ekranu mają rozszerzenie .scr i są plikami wykonywalnymi); System Windows zezwoli również na wykonywanie innych rozszerzeń plików, ale wymienione powyżej są domyślnymi rozszerzeniami wykonywalnymi.

Typowym programem instalacyjnym jest .msi.

.vbs to skrypt. i .js

Ale jeśli znasz trochę historii, możesz lepiej umieścić kontekst. Podejrzewam, że gdybym nie używał komputerów tak długo, jak to robię, mógłbym również skupić się na tym, które rozszerzenia są plikami wykonywalnymi ... ponieważ są one dość ekscytujące i wydają się fundamentalne ... i przypuszczam, że są ... Ale zauważ, jak z czasem .COM wymarł znacznie po DOSie, po prostu głównie znany, ale chyba w ogóle w Windows 9x w powłoce Command.com. Może stare NT używały ich często. Skrypty .. vbs pojawiło się może około czasu win9x .. więc pojawiają się nowe. ps1 jest jeszcze nowszy niż vbs.

.COM jest bardzo stary. Nie jestem pewien, czy Windows XP na przykład opiera się na plikach .COM. Ale wydaje się, że ma Command.com więcej dla starszych aplikacji.

.BAT to skrypt .. wstecz od czasów DOS. nadal w użyciu dzisiaj. .VBS jest bardziej nowoczesny, ale .BAT jest nadal używany i wkrótce nie przestanie być używany, a ludzie rozsądnie korzystają z obu. Jest .CMD, z którego nie korzystałem, ale prawdopodobnie nie jest tak różny od niczego. Jest ps1 (powershell. To jest bardziej nowoczesny niż vbscript) Jeśli mówimy o skryptach w luźnym sensie, istnieje .REG

Naprawdę termin wykonywalny odnosi się tylko do EXE i .COM (.COM jest w zasadzie wygasły .. bardziej rzeczą jest Win9x (wiersz poleceń w win9x to Command.com, nie było cmd.exe), a pliki COM to DOS. Ale nie CMD NT, na przykład powłoką poleceń NT jest cmd.exe, chociaż jak wspomniano, w NT jest command.com. Sądzę, że dla starszych aplikacji, ale NT najprawdopodobniej na nim nie polega)

.MSC np. Start..run..services.msc Nie są to pliki wykonywalne .. Przypuszczam, że są rodzajem skryptu .. services.msc wydaje się być napisany w xml) Ale jeśli się to rozluźni, to można pójść o krok dalej do rzeczy niesystemowych i powiedzmy, że strony HTML są takie, ponieważ są interpretowane .. jak skrypt. Ale nie przez system operacyjny… .CPL nie są skryptami… spójrz na nie w notatniku. Ludzie nie myślą o nich jako o plikach wykonywalnych lub skryptach, może dlatego, że piszą je tylko programiści MS. (lub jeśli inni tak robią, to jest to bardzo rzadkie!)

Jakie rozszerzenia plików w systemie Windows oznaczają plik wykonywalny?

Oznaczać co?

Wiem, że to pytanie wydaje się w tej chwili nieco mylące, ale pytanie ma znaczenie. Kiedy wyjaśniam, dlaczego to ważne, pytanie stanie się bardziej jasne.

Chociaż odpowiedź Kena White'a na zmienną PATHEXT (w „środowisku” wiersza poleceń) jest ładną i krótką odpowiedzią, która może być dla ciebie dobra, odpowiedź jest niepełna. Niepełne jest to, że poprawna odpowiedź różni się w zależności od tego, co próbujesz zrobić.

Na przykład możesz spróbować:

• Uruchom program z „tradycyjnego wiersza polecenia” („CMD”), wpisując pełną nazwę pliku
• Uruchom program z „tradycyjnego wiersza polecenia” („CMD”), wpisując podstawową nazwę pliku, ale pomijając jego rozszerzenie
• Użyj polecenia „start” wbudowanego w „tradycyjny wiersz polecenia” („CMD”)
• Uruchom program z PowerShell
• Uruchom program z punktu menu „Uruchom” znajdującego się w menu Start
• Uruchom program z Eksploratora, próbując dwukrotnie kliknąć ikonę związaną z plikiem kończącym się rozszerzeniem
• Powiedz Microsoft Internet Explorer, aby otworzył pobrany plik
• Uruchom program przy użyciu funkcji z interfejsu API systemu Microsoft Windows. (Jest to coś, czego zwykle nie robią użytkownicy końcowi, ale mogą to zrobić programiści komputerowi, więc informacje są dla nich odpowiednie).

Niektóre z tych metod uruchamiania programów mogą używać różnych metod określania, jakie rozszerzenia plików mogą być obsługiwane. W szczególności korzystanie z CMD może różnić się od menu Uruchom.

Na przykład zagadkowy blog Wesa: Dostosowywanie komendy uruchamiania systemu Windows ... odnotowuje sprawdzanie różnych lokalizacji, w tym klucza rejestru.

Odpowiedź może również zależeć od używanej wersji systemu Microsoft Windows. W systemie Windows 10 właśnie wpisałem nazwę pliku zip w wierszu polecenia i otworzyłem Eksploratora Windows. Wydaje mi się, że pamiętam, że nie działałem w Windows XP (chociaż w Windows XP mogłem wpisać „start filename.zip” i uzyskać taki sam efekt). Więc albo moja pamięć jest wadliwa, albo Microsoft próbował ulepszyć nowsze wersje systemu Windows. (Mam nadzieję, że dla mnie to drugie.)

W tradycyjnym wierszu polecenia systemu Windows 10 (z uruchomionym „CMD”), gdy przejdę do lokalizacji (używając polecenia „CD”) pliku zip i wpisz „filename.zip”, plik zostanie otwarty. Kiedy przechodzę do tej lokalizacji i wpisuję „filename” (pomijając rozszerzenie pliku „.zip”), system Windows nie znajduje pliku. Jednak jeśli uruchomię „ ECHO %PATHEXT%”, a następnie „ SET PATHEXT=%PATHEXT%;.ZIP” (a następnie „ ECHO %PATHEXT%” ponownie, aby upewnić się, że mam pożądany efekt), to mogę wpisać „filename”, a wiersz polecenia znajdzie plik .ZIP. Tak więc jest to efekt zmiennej% PATHEXT%.

Możesz zobaczyć inną listę rozszerzeń, uruchamiając ASSOCpolecenie. Na przykład uruchomienie tego polecenia wyświetla wiele wierszy danych wyjściowych, w tym następujące (w moim systemie) - „ .zip=CompressedFolder”. Następnie widzę, co to działa, wpisując „ FTYPE | FIND /I "CompressedFolder"”. (To jest przeznaczone dla tradycyjnego wiersza poleceń. PowerShell nie spodoba się tym nieoznaczonym cudzysłowom.) (Jeśli po prostu wpiszesz „ FTYPE” bez reszty tego wiersza poleceń, zobaczysz o wiele więcej wyników na temat innych rozszerzeń.)

Po wpisaniu „ ASSOC | FIND /C "."” na komputerze z systemem Windows 10 stwierdzę, że mam 339 wierszy danych wyjściowych, gdy w ten sposób sprawdzę powiązania plików.

W MS KB 162059 chodzi o dostosowanie sposobu otwierania dokumentów Office przez Internet Explorer.

Pytanie o listę domyślnych plików wykonywalnych jest więc zbyt niejasne. Różne składniki systemu Microsoft Windows mogą korzystać z różnych zasobów, dlatego pytanie musi być bardziej szczegółowe, aby uzyskać dokładną odpowiedź.

W pytaniu wspomniano o użyciu Eksploratora do dwukrotnego kliknięcia ikony. Aby zobaczyć listę używanych przez nią plików wykonywalnych, uważam, że będziesz chciał sprawdzić rejestr. Możesz uruchomić to z wiersza poleceń:

reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

(Nie wymienię ich tutaj. Jest ich 286 na moim komputerze z systemem Windows 10).

Zawiera listę rozszerzeń. Aby zobaczyć więcej informacji, w tym szczegółowe informacje o rozszerzeniach:

reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts /s

Jak więc widać, to z pozoru niewinne pytanie może być dość złożonym tematem. Wydaje mi się, że uzasadniłem swoje pytanie, dlaczego pytanie powinno być dość szczegółowe, aby móc uzyskać pełną odpowiedź, która całkowicie dotyczy tego, jak pojedynczy składnik systemu Windows może określać rozszerzenia plików. W pigułce nie ma jednej odpowiedzi dla systemu Windows, ponieważ system Windows ma wiele składników, które zachowują się na różne sposoby. Mam nadzieję, że zacząłem to pokazywać i wskazałem na dodatkowe zasoby, które pokazują istotne informacje.