I will be talking about different types of executables or at least the ones used by major OSs. Again this is a bit more nerdy, sorry. Here they are:
- .EXE files - IBM OS/2, Dos and Windows use the .EXE executable file format. In these operating systems the .EXE file extension is required. The code within the files are typically instructions for the x86 architecture or one if its variants. At one point Windows NT was ported to the PowerPC(but NOT Macintosh), this port includes some PowerPC exes as well.
There is a 'header' in the file that tells the computer what operating environment the program is to be run in. As far as I know/recall, it is a two letter prefix that is looked up in a table. This table includes entries for every OS type, bit-rate combination the OS can handle. If the OS reads a prefix it can't handle an error is shown from the OS.
Each header is followed by a "entry point" where the computer can execute some code. Early Windows programs often included two "entry points", one Windows and one Dos. The Dos entry point usually printed out a message saying something like "This is a Windows program". This protected against some variants of Dos from trying to execute the Windows part and getting messed up. Some very clever programs had two interfaces(one Windows and one Dos). Even more clever programs launched Windows along with the Windows counterpart.
The .NET framework also uses the .exe format, in this case for transparency. These .EXE files contain a Windows 32-bit prefix and x86 code that points to the dll file that is responsible for loading the framework. Like Java, .NET code is platform neutral and once the framework is started the neutral code entry point is called.
On none-windows platforms the program can be ran by first checking for the presents of the framework launch code(a sanity check) then launching the .NET entry point.
Lastly I should point out that resources like icons and mouse pointers are embedded in the executable. -
- .COM files - Used in Dos, these files are like lit-weight exes. My understanding is the can not contain anything more complicated then 16-bit code and have a limited size. For that reason they are no longer needed. I don't think resources can be embedded in these executables.
- .BAT files - these are not executables themselves but rather script files to run other executables(or commands)
- Mac OS(pre-X) - I'm not sure how executables work in Mac OS(pre-X). I think that the resource fork for a file says whether it is executable or not. The resource fork is a hidden file on the hard disk that contains resources of a file(icons and mouse pointers for executables and meta data for other files). One interesting thing (that I will discuse more in a different blog entry) is the fact that Mac OS had two types of executables in later versions, Motorola 68k and PowerPC. The PowerPC had an interpreter to translate the 68k code to PowerPC code on the fly. The two pieces of code where written after Apple decided to change CPU architecture.
- UNIX executables - In UNIX(or Linux) executables do not require an extension and most often don't have one. A file is executable if the "executable" flag is checked on the file system entry for the file.(the same place where the OS stores who owns the file and what premissions are set on it). This flag is often dropped when files are transmitted over the internet, which is why one often has too set the flag again when one downloads a program on UNIX. (or Linux). If a file is set as executable and it's not, the user will get an error when they try and execute the file. Scripts can also be set as executable. UNIX files can not easily have none-code embed in them. (remember this for the next section). UNIX and Linux are available on all sorts of platforms including the Amazon Kindle, so unlike Windows the code within them can be for any architecture.
- Mac OS X - For years Mac OS X baffled me since although the OS is based on Free-BSD(a flavour of UNIX), it uses a none-standard way of packaging executables.(sigh, Apple once again does their own thing). Native Mac OS X programs are packaged in appname.app folders under a sub folder called OSX. Resources and even libraries are found in other sub folder of the appname.app folder. The finder(the macs version of Explorer.exe) has been programmed to run the UNIX executable it finds in any folder that ends in ".app".
Make sense? OK, let me reiterate. The finder knows that when you double-click on a folder with a ".app" at the end of it, it should open it and launch the program located in the "appname.app/someapp.bin". If that program needs any resources to run they are found in the appname.app folder. Confusing but it does make things a tiny bit easier to keep track of since, files needed for a programme can not be as easily but separated from the program. Now if your still confused, contact me(in the comments) and I'll quickly jump on my Mac and take a screenshot.
- Java - Java runs executables by finding the entry point amongst the neutral byte-code. Java devices like Androids and Blackberries both run Java but have different entry points. I feel this could take a while to explain and this blog entry is a bit of a dry topic so I will leave this for another time.
Thank you for reading this, hopefully your learned something.
