DOS Executables Explained [Byte Size] | Nostalgia Nerd

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
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,, 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 and even
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 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!

Add a Comment

Your email address will not be published. Required fields are marked *