I found every process running on my computer has .exe extension on task manager.
Someone said that batch file (.bat) and bytecode (maybe .class) are also executable program, but I think they are just a file running by other executable program (.bat - cmd.exe, .class - JVM, .cpl - rundll32.exe) according to what I saw on task manager
Is ".exe" the only extension of executable programs in Windows OS?
If you're talking about executing commands then all the extensions in the %PATHEXT% environment variable can be run without specifying the extension. For example *.bat, *.vbs... are all "executable" in that sense
> echo %pathext%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
If it's about binary executables then Windows doesn't care about the extension of executable files. It just checks the format and if it's a supported binary format then it'll be run. Modern Windows uses PE format which starts with the MZ magic number so if you create a *.TXT file with MZ at the beginning and run it in cmd then it'll actually be treated as an executable file. In fact many files in the System32 folder like *.SCR, *.CPL... are also PE files and still run when we double click on them. And even *.COM files in modern Windows apps are also PE files. The *.COM extension is only for differentiating with another *.EXE of the same app, but with priority in running because *.COM is put before *.EXE in %PATHEXT% by default as can be seen above:
What would be the reason for WinSCP using a ".com" instead of ".exe"?
Executables in Visual Studio: devenv.com/devenv.exe
Windows 10 wsl (not wsl-2) even supports running Linux ELF executables directly and they of course doesn't have any extension by default. Since wsl-2 the file is run inside the VM instead of directly under Windows kernel like in wsl
Depending on Windows version it may support many more executable formats. The complete list is
Raw binary instructions in old *.com format
NE *.exe format
PE *.exe format
MZ *.exe format
ELF format
And they don't depend on the extension either except for the raw *.COM file
Related
When compiling/interpreting a program from the command prompt, how does the command prompt know where to find the requested compiler/interpreter?
Are these files stored in a specific place or something like that? I'm just about getting a hang of high-level programming, but I find it pretty hard to wrap my head around what happens under the hood.
There are two parts: Where to find the file just from it's filename, and what to do with it.
Where files (programs) are searched if just the name is entered:
Windows (CMD):
There is a variable %PATH% which has a list of ;-separated directories, eg. C:\Windows;C:\Windows\system32;C.\somethingelse. It is saved somewhere in the registry and can be set either in CMD itself or with a GUI somewhere in the OS configs.
Linux etc. (Bash and many more):
Similar, there is a variable $PATH which can be set at least in the shell and various config files, and the entries are separated by :, eg. /bin:/usr/bin/even/more. Priority is from left to right.
Additionally, some shells (eg. Bash) cache lookup results in their own implementation-specific way (depending on the configuration), because it's faster than having to check every directory in the path variable (at least if the searched program is in the last dir, everything has to be checked).
What to do with the file once it's found:
Windows:
In Windows, everything works with the filename suffix.
.exe and some others are native programs to start.
.bat is a shell script which is executed like it's manually written to the shell.
For every other suffix, it's configurable which program belongs to the suffix (stored in the registry, how to comfortably change it depends heavily on the used Windows version). Eg. you could say that .py belongs to your Python interpreter, the a file foo.py will start the interpreter. Btw., the same suffix-program configuration is usen when a file is double-clicked in the GUI file explorer, and of course program installers can add their entries too without the user having to do it.
Linux:
For Linux, the suffix is not as important. The first relevant thing is a binary (yes/no) flag x (x like executable) which exists for each file on the file system, just like file name, creation timestamp etc.etc.
If the x flag is set to yes:
Linux tries to detect what kind of program it is from the content. The difference between a native compiled binary program and a not-compiled script of some scripting language is pretty clear.
A native linux program is started by the kernel, like expected. Additional binary program types could be configured, eg. there is the Wine software which runs some Windows programs on Linux, and one could add a specification how Windows exe`s can be recognized inside and that they should be started with Wine.
For a text file with the x flag, the next step is to look at the first line, which should start with a '#!' (called shebang), followed by the path of the interpreter (eg. #!/bin/bash). Shell scripts (like the bat files on Windows) are realized this way, but it's not limited to classical shell scripts: Nothing prevents anyone from making a #!/bin/python script which Python content (of course, Python has to be installed for this to work).
If the x flag is set to no:
Shells like bash with usual configuration won't do anything, independent if it is a real program just without flag or a jpg image etc. For the GUI file managers:
Again, the content (and possibly the file name suffix too) is inspected to get the type, like jpg images, mp3 music, C++ source code etc.etc. (Linux knows pretty many types), and then the fitting program is looked up in a list configurable by the user and/or program installations (mime file type id <-> program).
...
Note that in the case of eg. Python scripts (which are just normal text files, not something for the kernel to work with), it can be done with and without x flag: With flag and a shebang line, or without flag and a matching mime list entry. In the "without flag" case, the shebang won't hurt if it is there, because Python (and many other scripting languages) consider it a comment because of the #.
Regarding interpreters on unix-based systems, lots of scripts start with a so-called shebang or hashbang (#! on the first line of the script) that tells what interpreter to invoke, see https://en.wikipedia.org/wiki/Shebang_%28Unix%29 .
When you enter something like some-program some-arguments, the shell will look through each directory listed in the environment variable $PATH for an executable file named some-program (on Windows it's %PATH% and some-program.exe).
This is not specific to compilers and interpreters - it happens whether some-program is gcc, python, firefox or notepad.
I was trying to make a batch file that compresses a specific folder (using winrar) to a specific location (not the same as the folder location), password (that I can choose myself) protects it AND does all of that without a cmd screen popping up.
I have very little knowledge of programming and managed to get some things working, but not all at the same time and in the same batch file.
Also to rar that file do I need Winrar to be installed on the computer or can I reffer to the rar.exe (copied from the Program Files Windows folder to a different location)?
AFAIK it's not possible to run a a bat file without a visible CMD window without using any additional tools. Here's a link to a post how to run a hidden console: https://superuser.com/questions/62525/run-a-batch-file-in-a-completely-hidden-way
It is possible to use just the rar.exe but I would use 7zip instead. The performance is way better, it's also portable and you have many options in the command line. So your project would contain the bat file itself, the vb script file and the 7z.exe (or rar.exe). If you want, you can even create a single .exe file out of these three by creating a SFX file: http://www.7zsfx.info/en/
Hope I could help you.
I have some kind of windows appilcation, running on Windows 7 32-bit. I'm trying to register particular file extension open command with my application using windows registry. Such file extension is my own and also registered by me. The application installed in particular subdirectory within Program Files. I want my installer to register application properly for both 32 and 64-bit platfroms, since actual Program Files directory names can be different on x86 and x64 platfroms, while I need to specify path to my application, I'm using registry redirection %ProgramFiles%. Here I reproduce what records I make to registry:
// file extension
HKEY_CURRENT_USER
Software
Classes
.myext
Default REG_SZ myapp.myext
// application
HKEY_CURRENT_USER
Software
Classes
.myapp.myext
Shell
Open
Command
Default REG_SZ "%ProgramFiles%\path\to\my\app\myapp.exe" -u -i "%1"
Actual path to program files dir in my test machine is C:\Program Files
With such registration I receive an error:
Windows cannot access the specified device path, or file. You may not
have the appropriate permissions to access the item.
If I replace %ProgramFiles% with actual C:\Program Files everything works fine. Also when I'm using same path: "%ProgramFiles%\path\to\my\app\myapp.exe" to run application from console everything works fine too. What can be reason of such issue.
%ProgramFiles% evaluates to the 32 bit program files dir in a 32 bit process and the 64 bit program files dir in a 64 bit process. However, the location of your executable does not depend on the bitness of the shell, which is the thing that reads those registry settings. You want to write the following value to the registry:
"C:\Program Files (x86)\path\to\my\app\myapp.exe" -u -i "%1"
where I assume that is the path to the 32 bit program files dir. You should not be writing an environment variable into this registry key. Your install program will already know the full path to the executable, and you should simply write that.
One issue that I think may be confusing you is that you may be under the believe that the program files directories are subject to file system redirection. They are not.
As an aside, if you ever need to write an environment variable into the registry, and want it to be expanded upon reading, use REG_EXPAND_SZ rather than REG_SZ.
I dont really understand whats going on and cant see the difference:
I'm downloaded the base64.exe for creating base64 text under windows. i copied it to C:\Windows\ because its in the %PATH% variable.
Now i want to try it: echo Hello | base64 works great. Okay i dont need to append .exe and as far as i know i dont need to do it also with .bat and .com files.
But now i have some cygwin tools installed and for example tried which base64, which doesnt work, because it says that base64 is not in path. Then i typed in which base64.exe and got C:\Windows.
So my question is now: when i need to use .exe and when i dont? Is it only when i'm using cygwin tools that i need to append .exe?
Cygwin is a shell which emulates UNIX behaviour. UNIX doesn't know anything about .exe, thats why Cygwin can't find base64.exe. Under UNIX, binaries are stored without an extionsion added to their filename, e.g. just base64.
Windows CMD automatically appends .bat, .com, .exe and the like to your file names. Cygwin does not. So if you are using a linux shell you have to append it manually.
Since Cygwin is aware that it always runs under Windows it might append .exe if you want to perform certain actions in the shell itself (e.g. opening a file), to behave more friendyl to Windows users who expect this behaviour. However programs running under Cygwin might not integrate those features since they were mainly devoloped for usage under UNIX. That could be a reason why which base64 fails.
I have batch file that I am inheriting and I cannot get to work in a 64bit Windows 7 environment. The batch file makes a call to a java script, and passes two variables in it. The old on looked like this:
C:\Progra~1\salesf~1.com\ApexDa~2.0\bin\process.bat C:\Progra~1\*PATH* *VARIABLE*
This was run onm 32bit XP which has just the one program files. I have tried every way I can think of to change the being of the the path to Program fiels x86. I have tried SET PATH, SET ExecPath, %ProgrmaFiles(x86), but they all return cannot find the path specified. I am sure the answer is easy, and I know there is a much beeter way to do this, and it will be changed, but for the moment, I need this to work. Any help, much appreciated.
If you type
dir /x c:\
then this shows the directory listing in the 8.3 format. Program Files expands to PROGRA~1 and Program Files (x86) expands to PROGRA~2. So I think you'll need to change the script to use PROGRA~2
EDIT: I agree with Mark that this isn't ideal -- it depends how much you are able to change of the legacy scripts. On a Win7 machine you should be able to use %ProgramFiles% and %ProgramFiles(x86)% (note the trailing '%').
export JAVA_HOME=/cygdrive/c/Progra~1/java/jdk1.7.0_40/
This worked for me.