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.

Solution 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.

Solution 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.

Solution 3

.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!)

Solution 4

A common one for installer programs is .msi.

View more solutions

Comments

[JJ_Australia]

It's really less an executable format and more a script format, since it still needs to be parsed by msiexec.exe.

[UNK]

additionally, you can add more - for example, add .py to let "pyscript" run "pyscript.py"!

[Naidim]

@Hello71: Are you really 12?

[studiohack]

@paradroid: no, he's really not. look at his writing style.

[JJ_Australia]

@paradroid: Does it really matter?

[studiohack]

@Hello71: paradroid said something to you.

[studiohack]

@paradroid: just so you know, the 2nd notification does not alert the user. thus the comment.

[barlop]

@Phoshi but with .py then you're going third party, and there's no end

[UNK]

@barlop; Indeed I am, but it's a useful thing to know, if tangential to the question :)

[Synetech]

Unfortunately, adding .MSC to the PATHEXT does not let you run MMC snap-ins without adding the extension (eg services instead of services.msc). :-(

[barlop]

@Phoshi I have a python script, the well known, youtube-dl.py and I can run it as youtube-dl.py<ENTER> But I just tried doing set %PATHEXT%=%PATHEXT%;.PY and I still can't run it with just doing youtube-dl

[barlop]

@Phoshi to correct myself, funnily enough I just tried it with PY and it worked so you're right Phoshi.

[sinni800]

Theres also .SCR for screensavers. They can (and do) contain actual execution code for the screensavers. They're just not in PATHEXT.

[kinokijuf]

@Synetech because there is already a services.exe.

[Synetech]

@kinokijuf, true; if you run diskmgmt (without the extension) from a command-prompt it will work, but running services won’t. However none of them will work if you try to run them from the Run dialog without the .msc extension, even though the system-wide pathext variable contains .msc.

[iBug]

Is this the search order when one tries to run an executable without specifying suffix?

[Euro Micelli]

That's not what PATHEXT is for. docs.microsoft.com/en-us/windows-server/administration/…. PATHEX is just a list of alternative extensions to append when the user "executes" a filename without an extension. cmd.exe will append each extension in order until it finds a matching file, and will act like if the user had specified that extension. What "executing that file" does depends on the specific extension (including not knowing what to do). It act exactly as if the user had typed the extension themselves. This search is only done for the first token (the "command")