What is the difference between the a.bat, a.com and a.exe extensions?
Originally, a .COM file was a literal blob of 8086 code (that is, 16-bit x86). It is meant to be loaded at a fixed address, and the loader would jump straight to the first byte of its address. It's also limited in size.
An .EXE file has more header information. So it has required structures for things like dynamic linking, where code from a DLL can be patched into the .EXE's memory space at load time.. It originally comes from DOS, but it's today used in Windows.
However DOS and Windows eventually went to a model where the file extension in a .COM and .EXE didn't mean anything. The program loader first checks the first two bytes of the file. If it happens to be the string MZ (legend has it this stands for the initials of an early Microsoft employee), it will treat it as an EXE, otherwise it will load it as if it were a COM file. Since MZ doesn't map to a sensible x86 instruction to start a program, they can get away with this. Net effect: In some versions of DOS/Windows, an .EXE can be named with .COM and vice versa. For example, in many versions of DOS/Windows, the famous COMMAND.COM was actually an EXE.
I am not sure how much the previous paragraph applies to NT based versions of Windows. I'd imagine by now they've abandoned the .COM stuff altogether.
Lastly, a .BAT file is a list of commands to be executed as if you typed them at your command prompt. However these days most people name them as .CMD.
.bat is a batch file. It is interpreted.
.exe is a regular executable program file.
A .com file, at least for MS-DOS, has many meta-data missing and is loaded into a specific offset in the main memory. It is smaller than .exe
I assume you mean for Windows?
"a.bat" is supposed to be a batch file, the Windows/DOS equivalent of a script file.
"a.com" and "a.exe" are supposed to be equivalent these days. However, back in the Windows 3.x days, a "com" file was a DOS executable, where an "exe" file was a portable executable, or a Windows-based executable. This is a gotcha these days, as files in the format "www.example.com" can exist on your hard drive, and many people mistake such a file for a web link. Even worse, Windows typically tries executing "com" files before "exe" files.
A bat(ch) file is a script that is executed by the command interpretor.
A exe file is compiled binary code to be executed directly on the cpu.
A com file is a relic from the past to create a small exe.
.BAT - Batch File: list of commands (basically a text file with command-line commands)
.COM - DOS Executable loaded into a fixed block of memory (stems back from before multi-tasking)
.EXE - Executable file - standard application on the Windows platform
While EXE and BAT files often serve a similar purpose, they use completely different file formats. Both file types can be used for creating executable content in Windows, but BAT files are limited in the commands they can perform. Since BAT files contain human-readable text, they can be easily edited and therefore are often used for custom scripting tasks. EXE files, on the other hand, contain complex binary data that is built using a compiler. Since EXE files support more complex commands than BAT files, most Windows applications are saved in the EXE format.
I was also looking for the same query and found something that have pasted here.
Please refer the below link, you will find it useful, it perfectly answers your question:
Difference between .BAT and .EXE
Actually, .com and .exe are both binary executable files, whereas .bat is basically a batch file. Now suppose you have got many files with the same name, but different extensions.
For instance, a.com, a.exe and if you are running through the command prompt file a. It will first execute a.com (only if it exists), else it will run a.exe. Or say a.exe is also not there then it will look for a.bat execution.
A .BAT (short for "batch") file is a plain text file that contains a
series of Windows commands.
An .EXE (short for "executable") file is a binary file that contains
much more complex executable binary code.
A .COM file was a DOS executable and nowadays its same as .EXE.
.bat file effects directly on the performance of CPU.
While, the .exe file will be compiled by interpreter and then executed on CPU.
Related
In my experience, #f::Run mailmaster will launch mailmaster.exe when pressing #f, but throws when doing #f::Run QQMusic:
I had to provide the full path for QQMusic.exe whereas I didn't have to provide the full path for mailmaster.exe.
According to the documentation:
Run can launch Windows system programs from any directory. Note that executable file extensions such as .exe can be omitted.
Run notepad
Since both mailmaster.exe and QQMusic.exe are non-system programs and they are not included in the Path environment variable, why AutoHotkey is giving different behaviors for them?
And performance-wise, providing the full path versus just the .exe name, which is faster?
It's specified in the documentation:
Target
A document, URL, executable file (.exe, .com, .bat, etc.), shortcut (.lnk), or system verb to launch (see remarks). If Target is a local file and no path was specified with it, A_WorkingDir will be searched first. If no matching file is found there, the system will search for and launch the file if it is integrated ("known"), e.g. by being contained in one of the PATH folders.
So pretty much if it's found in PATH.
You can try this for example by typing notepad, mailmaster and QQMusic in cmd or powershell. Notepad is found in PATH, and on your system I'm assuming mailmaster is as well, and QQMusic isn't.
You should get the same results as with the AHK Run command.
As for performance, I don't know, I guess this is something you could benchmark.
I'd guess that providing the full path is more efficient.
But maybe finding something from PATH is very well optimized on the the Windows side of things, so maybe there is little to no difference.
I'm trying to get my head around a DLL load library problem. The Windows Dynamic-Link Library Search Order is supposed to be
Memory
Known DLL's
Application Directory
System Directory
...etc,
as discussed at https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order and at many other places.
When I run a Windows Executable (Desktop Application) from a Batch file, does it inherit the 'application' folder from the Batch File? (Because I'm running out of other explanations)
Nope, you can't consider a batch file an application at all.
It's more like a script, as it needs to be run through an actual application/executable program (like the DOS runtime, or CMD on Windows)
You can setup environment variables much like in old DOS times (if you need to define a Paths variable) through sysdm.cpl, but I'm not sure that would help for DLL searching
When we build a project, we can define that under which subsystem we want to run our program in windows. But how it would affect the output exe file. Or in other words when we call a CreateProcess() API we just pass it an exe file, So which header inside the exe file, it
checks to determine that which subsystem going to handle this process? Or it uses some other method in order to accomplish it?
i guess, i will look into EXE header
Look
http://www.delorie.com/djgpp/doc/exe/
http://www.fileformat.info/format/exe/corion-mz.htm
Tools update:
I like:
http://www.heaventools.com/PE-file-header_viewer.htm
http://www.mitec.cz/exe.html
You Can:
http://blogs.msdn.com/b/securitytools/archive/2010/01/28/how-to-view-the-header-of-an-exe-dll.aspx
online :http://exe.urih.com/
In the primary header of executable, that information is present. As you are talking about .exe(or rather binary), linker stage is performed. Linker is part of OS, and every OS has a code number through which it is recognized as its binary.
As in case of windows and CreateProcess(), consider reading this
Is their a way to zip a file without VB Script.I got a lot of examples on web to zip file or folder using vbs but i want to do it in a single BAT file.
Yes and no. There is no built in way to do this inside windows. You can use a external application like vbscript, a exe file like 7zip, rar, lots of resources can do this. Since windows is application poor when it comes to command lines is not really surprising. But no you do not need the VB Script for anything.
Just not so easy out of the box. Maybe makecab could do it for you? As a general rule you have a hard constraint in your question. A single BAT file which in general can not do almost anything without the support of hundreds of preinstalled or commonly installed other applications.
Could you specify a the constraints a bit better. Tel WHY you need this particular constraint? And what does it mean as even most of the bat command you use require more than one file.
I'm writing a program to detect which ".exe" file is generated by "Visual Basic6". I found that at the "entry point" of each vb file, there is an address at offset 1 from "entry point" which points to a location that contains the string: "vb5!", is that a certain signature? Can I be sure that in every vb files this string is exist?
Then, I want to find the certain address of the beginning of the code, so that I can recognize every vb file from an other vb file.
Not exactly sure what you're trying to accomplish, but every VB6 exe, DLL or OCX will contain an import to MSVBVM60.dll. If it contains that, you can be pretty sure it's a VB6 exe.
About this
Then, I want to find the certain
address of the beginning of the code,
so that I can recognize every vb file
from an other vb file.
VB6 doesn't embed the same kind of metadata in the exe that .net does, so it'll be impossible to extract any "VB Code" from the executable. Depending on how it was compiled, you MIGHT be able to retrieve functionnames and such, but that's only if the PDB (program database) was embedded into the exe and not compiled into a seperate PDB file.
Worse, there are plenty of tools out there to compress an exe (any exe), and if that's done, there's almost no way you'll be able to tell where the exe came from, at least not from simply looking at the contents of the exe file.