On Windows, what filename extensions denote an executable?

Question

On Windows, *.exe, *.bat, *.cmd, and *.com all represent programs or shell scripts that can be run, simply by double-clicking them. Are there any other filename extensions that indicate a file is executable?

EDIT: When I jump into a new project (or back into an old project!), one of the common things I want to do when looking around is to find out what tools there are. On Unix (which I've used for decades), there's an execute bit, so this is as simple as:

find . -executable -type f

I figured that on Windows, which seems to have a much more complex mechanism for "is this executable (and how do I execute it)", there would be a relatively small number of file name extensions which would serve roughly the same purpose.

For my current project, *.exe *.bat *.cmd is almost certainly sufficient, but I figured I'd ask if there was an authoritative list.

Answer 1

The basic "executable" files (the ones Windows looks to execute via the PATH) are stored in an environmental variable called PATHEXT. You can see this from a command prompt:

C:\>set PATHEXT

On my machine, I get this (WinXP):

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

This is not an exclusive list. Windows will also execute other files (for instance, screen savers have an extension of .scr and are executables); Windows will also allow execution of other file extensions, but the ones listed above are the default executable extensions.

Answer 2

On Windows, what filename extensions denote an executable?

Denote to what?

I know that question probably sounds a bit confusing at the moment, but the question matters. As I explain why it matters, the question will become more clear.

Although Ken White's answer of the PATHEXT variable (in the command prompt's "environment") is a nice and short answer, and that answer may work well for you, the answer is incomplete. The reason that is incomplete is that the correct answer is different based on what you are trying to do.

For example, you might try to:

• Run a program from a "traditional command prompt" ("CMD"), by typing its full filename
• Run a program from a "traditional command prompt" ("CMD"), by typing the base filename, but leaving off its extension
• Use the "start" command that is built into the "traditional command prompt" ("CMD")
• Run a program from PowerShell
• Run a program from the "Run" menu item, found on the start menu
• Run a program from Explorer, by trying to double-click an icon related to a file ending with the extension
• Tell Microsoft Internet Explorer to open a downloaded file
• Run a program using a function from the Microsoft Windows API. (This is something that end users don't typically do, but computer programmers may do this, and so the information is relevant to them.)

Some of these methods of running programs may use different methods of determining what filename extensions may be supported. In particular, using CMD may be different than the Run menu.

For instance, Wes's puzzling blog: Customizing Windows Run Command... notes different locations being checked, including the registry key.

The answer may also depend on what version of Microsoft Windows is being used. In Windows 10, I just typed the name of a zip file at a command prompt, and it opened up Windows Explorer. I seem to remember that not working in Windows XP (although in Windows XP, I could type "start filename.zip" and get the same sort of effect). So either my memory is faulty, or Microsoft has been trying to make improvements in newer versions of Windows. (Hopefully, for me, the latter.)

In Windows 10's traditional command prompt (running "CMD"), when I go to the location (using the "CD" command) of a zip file, and type "filename.zip", then the file will open. When I go to that location, and type "filename" (leaving off the ".zip" file extension), then Windows does not find the file. However if I run "ECHO %PATHEXT%" and then "SET PATHEXT=%PATHEXT%;.ZIP" (and then "ECHO %PATHEXT%" again, to make sure I had the desired effect), then I can type "filename" and the command prompt will find the .ZIP file. So, that is the effect of the %PATHEXT% variable.

You may be able to see another list of extensions by running the ASSOC command. For example, running that command shows multiple lines of output including the following (on my system) - ".zip=CompressedFolder". Then, I can see what that runs by typing "FTYPE | FIND /I "CompressedFolder"". (That is meant for the traditional command line. PowerShell won't like those unescaped quotation marks.) (If you just type "FTYPE" without the rest of that command line, you'll see quite a bit more output about other extensions.)

If I type "ASSOC | FIND /C "."", on my Windows 10 computer, then I find that I have 339 lines of output when I check for file associations that way.

MS KB 162059 is all about adjusting how Internet Explorer opens Office documents.

So, asking for the list of default executables is too vague. Different components of Microsoft Windows may use different resources, so the question needs to be more specific for a precise answer.

The question did mention using Explorer to double-click on an icon. To see the list of executables used by that, I believe you'll be wanting to check out the registry. You can run this from a command prompt:

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

(I'm not going to list them here. There are 286 of them on my Windows 10 computer.)

That lists the extensions. To see more information, including details about the extensions:

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

So, as you can see by now, this seemingly innocent question can actually be a quite complex topic. I believe I've made my case on why a question should be quite specific in order to be able to get a complete answer that totally addresses how a single component of Windows may determine the filename extensions. In a nut shell, there isn't just one single answer for Windows, since Windows has multiple components that behave in different ways. Hopefully I've begun to show that, and pointed to some additional resources that show relevant information.

Answer 3

A common one for installer programs is .msi.

Answer 4

.vbs is a script. and .js

But if you know some history then you'd be able to put things in context better. I suppose if I hadn't used computers for as long as I have, I might also focus on knowing which extensions are executables..'cos they're quite exciting and seem fundamental.. and I suppose they are.. But notice how with time, .COM died out a lot after DOS, just mainly known I suppose after that if at all, in windows 9x in command.com shell. Maybe old NTs used them a lot. Scripts.. vbs came around win9x time perhaps.. so new ones appear. ps1 is even newer than vbs.

.COM is very old.. i'm not sure if windows xp for examples relies on any .COM files. But it has a command.com more for legacy apps I guess.

.BAT is a script..back from DOS days. still in use today. .VBS is more modern but .BAT is still used and won't go out of use any time soon, and people sensibly use both. There's .CMD which I haven't used but probably not so different to anything. There's ps1 (powershell. this is more modern than vbscript) If we're talking scripts in a loose sense, there are .REG

Really the term executable only applies to EXE and .COM(.COM being basically extinct.. more a win9x thing (the command prompt in win9x was command.com , there was no cmd.exe) , and COM files are a DOS thing. But not NT's CMD for example NT's command shell is cmd.exe though as mentioned there is a command.com in NT I guess for legacy apps but NT most probably doesn't rely on it)

.MSC e.g. start..run..services.msc They are not executables..I suppose they are a kind of script.. services.msc seems to be written in xml) But if going that loose then one might go a step further to non system things, and say HTML pages are one 'cos they are interpreted.. like a script. But not by the OS though.. .CPL are not scripts.. look at them in notepad. People tend not to think of them as executables or scripts, maybe 'cos only MS developers write them. (or if others do then that's very uncommon!)

Answer 5

One need to understand low level stuff to get a right picture:

• CreateProcessA function expects (but not requires as it checks for magic signatures too) .exe or .com (or something esoteric). for batch files they explicitly stated:

  To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.

  Unofficially it might work though: https://stackoverflow.com/questions/21553379/createprocess-is-able-to-execute-batch-files-but-documentation-says-the-opposit

• Today the .exe file represents different types: win16, win32, CRL, what else? Seems CreateProcessA analyzes file's magic signature to differentiate.

• ShellExecuteA defined verbs: edit explore find print runas open and last two of them are responsible for launching interpreter (runas is for Administrator/elevated) based on registry leaves in HKEY_CURRENT_USER/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/FileExts.

  For open verb you can dump relevant registry DB with:

  # ext => type
  cmd /c assoc
  # type => command
  cmd /c ftype
  

  Most file types are depending on some executable interpreter:

  # cmd /c assoc .vbs
  .vbs=VBSFile
  # cmd /c ftype VBSFile
  VBSFile="%SystemRoot%\System32\WScript.exe" "%1" %*
  

  and even has "strange" non-executable semantic:

  # cmd /c assoc .ps1
  .ps1=Microsoft.PowerShellScript.1
  
  # cmd /c ftype Microsoft.PowerShellScript.1
  Microsoft.PowerShellScript.1="C:\Windows\System32\notepad.exe" "%1"
  

• Among all file extension associations few are marked as "self-executable", from ftype output:

  batfile="%1" %*
  cmdfile="%1" %*
  comfile="%1" %*
  exefile="%1" %*
  piffile="%1" %*
  scrfile="%1" /S
  

  Meaning:

  for i in batfile cmdfile comfile exefile piffile scrfile; do cmd /c assoc $i; done
  batfile=Windows Batch File
  cmdfile=Windows Command Script
  comfile=MS-DOS Application
  exefile=Application
  piffile=Shortcut to MS-DOS Program
  scrfile=Screen saver
  

• cmd interpreter was own rules, introducing PATHEXT env var, see documentation on start command: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/start

  If you run a command that uses a first token that isn't a command or the file path to an existing file with an extension, Cmd.exe uses the value of the PATHEXT environment variable to determine which extensions to look for and in what order. The default value for the PATHEXT variable is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

• Similar logic in PowerShell https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables

  The $env:PATHEXT variable contains a list of file extensions that Windows considers to be executable files. When a script file with one of the listed extensions is executed from PowerShell, the script runs in the current console or terminal session. If the file extension is not listed, the script runs in a new console session.

  To ensure that scripts for another scripting language run in the current console session, add the file extension used by the scripting language. For example, to run Python scripts in the current console, add the .py extension to the environment variable. For Windows to support the .py extension as an executable file you must register the file extension using the ftype and assoc commands of the CMD command shell. PowerShell has no direct method to register the file handler. For more information, see the documentation for the ftype command.

• Windows comes with where.exe (analog of popular Linux which) https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/where and it states:

  If you do not specify a file name extension, the extensions listed in the PATHEXT environment variable are appended to the pattern by default.

• Win+R accepts names without .exe or .bat or .cmd but requires extension for other types, even they are listed in PATHEXT! So you need to type in: gpedit.msc and slmgr.vbs, short version won't work!

  Actually people reverse-engineered Run Dialog, it is RunFileDlg from shell32.dll, you can call it yourself with rundll32 shell32.dll,#61 and the list of supported suffixes is .pif;.com;.exe;.bat;.lnk;.cmd https://stackoverflow.com/questions/62386258/how-are-commands-on-run-dialog-executed

• Other environment (like https://en.wikipedia.org/wiki/Windows_shell or https://en.wikipedia.org/wiki/File_Explorer ) might have different interpretation of file extensions.