Hello, and welcome to Byte Size.
Today's episode is all about the DOS executables & scripts.
You know how I love such relevant subjects for today.
Ahhhh, command line operating systems.
My favourite.
These were the days when installing new software meant navigating to the A: drive, requesting
a directory listing, finding the necessary installation program and typing out it's file
name to execute it.
Then post installation, you could navigate to your new directory, find the program file
and execute that... likely only to be told you've run out of conventional memory, or
something to that effect.
Glorious times indeed.
But finding these executables to run wasn't always straight forward.
Some software could contain multiple executables, and it was your job to work out which one
sounded like it was most appropriate for the task.
You might, for instance, have a game installed in a directory with;
Run.bat Game.exe
Execute.com Setup.exe
executables all present.
Of course you could look at the readme.txt file for instructions, or just go ahead and
run what felt like the most appropriate.
Usually it was a .bat file, and that's because a .bat file is simply a set of DOS commands
bundled into a text file; a DOS script if you will.
The .BAT extension actually stands for batch, as it's a batch of DOS statements.
Therefore the reason for it's presence is usually to run the correct executable, with
the correct command line statements, or even a setup file first, if it hasn't already been....
setup.
Batch files could actually be incredibly complex.
I remember creating a jumping menu for my PC which ran on boot and provided a nice,
friendly set of options for me to choose.
YOU MASSIVE NERD.
So what about the actual executables themselves?
Specifically .COM and .EXE in the good old DOS days.
Well, let's start with .COM files, with the .COM standing for COMMAND.
This is the original program file; one inherited from Digital Research's CP/M operating system,
which was really the base-line for 86-DOS on its inception.
Microsoft would of course purchase 86-DOS from Seattle Computer Products and the rest
is history, but the basis of the .COM file would remain the same.
Rather than being in a particular format, a .COM file is really just a memory image.
DOS would simply pick up the file contents, plonk it into memory at a fixed address and
then run the 16 bit machine code.
Perhaps the most well known file to use this extension is the DOS command-line interpreter,
command.com, which would relinquish & load itself back into memory after a program had
finished running.
However, this basic method meant that file sizes were limited to 64KB, which was fine
for most programs in the early 80s running under CP/M, but with the additional memory
offered by IBM-PC compatibles, requirements outgrew this limitation, and this is where
the .EXE extension comes from.
.EXE stands for Executable and makes up for the shortfalls of .COM files.
Originally these executables were based around the MZ format (after Microsoft coder Mark
Zbiokowski).
At it's most basic level this meant that the header of an EXE files starts with the letters
MZ, but also defined the structure of the files.
Executables allowed for much larger programs, especially when DOS extenders came into use,
and also laid the foundations for Windows and even OS/2 to use similar structures, all
bundled under the .exe extension.
This new executable also ran under Multitaskig MS-DOS 4, with the ASCII identifier of NE
(standing for New Executable) hidden within, along with resources such as bitmap graphics,
all contained in one nice package.
Of course we still use derivatives of this in Windows even today.
It was around this time where we also witnessed the lines blur between .COM and .EXE files.
DOS utilities like Edit.com and even Command.com were increasing in size and so new rules were
required to allow their size to exceed 64KB.
Adding flexibility into the program loader meant that .COM and .EXE could be renamed
with the alternate extension, but would still run fine, with the operating system seeking
header information and determining how to load the file where appropriate.
With 32 bit versions of windows however, both the .com file and for the majority of users,
batch files became irrelevant, and we moved to what you may call a less diverse culture
of executables.
Although we'll get to things like .MSI files in another episode.
Regardless, we should cover something important before I leave.
Something which sometimes caused me issues as I tired to work out why my executable wasn't
running as expected, and that's run order.
Throughout their time, the run order of these DOS files has remained the same.
If you have 3 exectuables, with the same name and different extensions, they'll run in this
order.
.Com .exe
.bat
Although I always thought it would be better if batch files ran first, so you could sneak
some extra command line options in there without confusing the end user, but it doesn't really
matter does it?
So, if you want to run bob.exe, but you've got a bob.com in the same directory then typing
bob, will just run the .com, that is, unless you type their extensions as well - bob.exe
- in the command line.
So, I hope that has cleared up a mystery I'm sure has been nagging you for almost 40 years.
I for one, feel better.
Thanks for watching!