The Execution of All Things

A list of executable file formats that didn’t make it. That said, if you want to load up an Adobe AIR application, we can’t stop you.

By Ernie Smith

Today in Tedium: Whether the way you roll is .EXE, .APP, or .SH, you most assuredly rely on some executable things in your life as a computer user. Maybe you don’t even realize it—after all, Android and iOS really go out of their way to separate you from the process of direct file execution—iOS with a whole flippin’ App Store. Of course, the nature of execution is such that every type of computer has its own way of doing things, and that way of doing things may not be compatible with any other. As a result, it leads to a lot of incompatiblity over time—some of which we’re talking about today. Continuing on our list of things that didn’t make it, we now lean really hard on once-common file formats that execute things—or, at least, look like they do. Today’s Tedium executes some code. (Got a problem with the list? See the disclaimer.) — Ernie @ Tedium

The Sample

Find your next favorite newsletter with The Sample

Each morning, The Sample sends you one article from a random blog or newsletter that matches up with your interests. When you get one you like, you can subscribe to the writer with one click. Sign up over this way.

Today’s Tedium is sponsored by The Sample. (See yourself here?)

4143361191 740b39328f z

Dennis Ritchie and Ken Thompson running UNIX on a PDP-11, utilizing teletype-style terminals, in case you’re wondering how old we’re talking here. (Kenneth Martin/Flickr)

1. a.out File Format

Era: 1960s-1990s

Operating Systems: anything related to UNIX

Most common file extension: a.out

This is one of those executables that has a famous name attached to it. Ken Thompson, one of the primary developers of UNIX, built this executable format, which stands for “assembler output,” was one of the first types of executable that was supported by modern computing platforms.

Thompson developed the format in 1968 for the PDP-7 minicomputer, and it gained fame a few years later after Thompson and his Bell Labs colleagues developed UNIX with the help of said executable.

Later versions of UNIX moved to other executable formats, most notably the Executable and Linkable Format (ELF) format leveraged by most UNIX-based systems today, as well as the Mach-O format used natively for MacOS executables.

While primitive by today’s standards, a.out had a long life—it was supported by Linux, for example, until version 5.18 of the kernel, which came out only back in May.

8021910227 25c61dcaae c


2. COM file

Era: 1970s-1990s

Operating Systems: CP/M, MS-DOS

Most common file extension: .COM

This is one of the most important executable formats of the pre-Windows era, and is used in a variety of programs as a fundamental part of the DOS ecosystem, especially small utilities.

Originally developed as an executable for the CP/M line of computers by its developer Digital Research, the executable is very simple in nature, so much so that it wasn’t unheard of for programmers to allow the executables to self-modify themselves. But this simplicity meant that most programmers quickly outgrew it, especially because it had a size cap of 64 kilobytes.

It did have one important use in the Windows environment in the pre-Windows XP days, in the form of the WIN.COM file, which is the primary loader file for most early versions of Windows. As noted in a 1991 InfoWorld article, WIN.COM is actually custom-made for your system upon install, rather than something Microsoft includes on the install disk.

(Unlike .COM files, another common bit of file nomenclature from the DOS days, the .BAT scripting file, is still fully available in modern Windows environments, serving a similar role as a UNIX shell script.)

2263267707 76c93927a5 c

(Stefano Petroni/Flickr)

3. Commodore 64 executable files

Era: 1980s

Operating systems: Commodore 64

Most common file extension: None before emulation, .PRG after emulation

While most people loaded executable formats from disks using the Commodore 64’s iconic LOAD “*”,8,1 command, the 8-bit computer obviously was executing specific files when you did that. The Commodore didn’t need a specific file format for its executables, but later computers very much did—which meant that in emulator-style formats, C64 programs would often be shared using the .PRG format.

In a book on using the Ophis assembler with the Commodore 64, author Michael C. Martin puts the PRG format like this:

The PRG format is ludicrously simple. It has two bytes of header data: This is a little-endian number indicating the starting address. The rest of the file is a single continuous chunk of data loaded into memory, starting at that address.

Despite this dead simplicity, or perhaps because of it, the C64 amassed a massive library of programs, including many commercial titles.


(Super Snapper/Unsplash)

4. Amiga Hunk format

Era: 1980s-1990s

Operating systems: Amiga

Most common file extension: None

If you ran an executable application on an Amiga, this was your format. Built for running applications on the Motorola 68k processors, the format was initially managed by Commodore, and applications could be built from an array of distinct hunks that were joined together within program units.

A noteworthy feature of the format compared to most of the others on this list was that it was not dependent on file extension, because Amiga uses another detection method, reliant on the file header, to understand whether a file is executable or not, called a “magic cookie”—essentially, it looks for a specific set of bytes to know whether the file is executable.

Modern Amiga-style operating systems such as AROS or MorphOS, while still able to run Hunk files, tend to support the more-common ELF-style executable format, which is used in UNIX-style operating systems like Linux and FreeBSD.

GeoWorks startup screen

Ah, GeoWorks.

5. GEOS File Format

Era: 1980s-1990s

Operating Systems: GEOS/GeoWorks

Most common file extension: .GEO

As you probably know about me, I am a GeoWorks enthusiast, enough of one that I recently added it to my Twitter bio. And I have to be honest, I have never seen the .GEO executable file format outside of the context of GeoWorks.

As I noted in my piece on the Windows competitor, not a lot of external apps were developed for the DOS frontend, in part because there wasn’t initially an SDK that could be natively used on the platform. Instead, you needed to acquire a Sun workstation to develop for it, something few companies (besides the firm that ultimately became AOL) were willing to do.

But once you did get a hold of that SDK—it’s available on WinWorldPC if you’d like to take a crack at it—you were able to program applications for the system that would appear in the .GEO format, which only worked in GeoWorks. One can understand, given all that, why it never got third-party uptake.

A Computer Chronicles clip on IBM’s TopView, the application that introduced the concept of the PIF.

6. Program information files

Era: 1980s-1990s

Operating Systems: Shell programs that ran on top of DOS, such as Windows, TopView, and DESQview

Most common file extension: .PIF

In many ways, executable files sometimes are used as ways to interpret information given the context, rather than executing the data themselves. This is very much true of the PIF file, effectively a shortcut file for DOS-based shells, most notably Windows, that told the shell how to run the DOS program.

In Windows, these files are treated as executables, but are basically pseudo-executable, essentially being interpreted by Windows before it runs the actual executable.

The concept pre-dates Windows, originally being implemented on IBM’s TopView, the first multitasking workspace for DOS-based computers, though in that setting it was purely in text mode and mostly limited to IBM’s own programs.

The concept wasn’t perfect, though. A 1991 InfoWorld piece from writer Brian Livingston suggested that Microsoft was poorly optimizing PIF files through its default PIF file. “Unfortunately, Microsoft’s factory settings in this PIF are designed for the worst possible case,” he wrote. “This is almost guaranteed to harm the performance of your DOS sessions.”

When you’re done reading this article, play this video on your computer in full screen.

7. Windows Screensaver File Format

Era: 1990s-(very faintly in the) present

Operating Systems: Windows

Most common file extension: .SCR

In the era of cathode ray tubes, having a solid screensaver was important, taking on a similar role in many offices to, say, putting a picture on your smartphone. It was a cute way of showing personality, especially if you were a fan of flying toasters or the Energizer Bunny (the latter being the subject of one of the best-ever Medium posts).

At least in Windows, screensaver files are treated as executables, meaning that when you pull up a screensaver on the Internet Archive, it’s actually an executable file. While that means you can run a screensaver at will, it also meant that it was at risk of being exploited, whether by Trojan horses or by malformed screensaver files.

While Windows technically supports this feature today—in fact, with light modifications, you can run a Windows 3.1-era screensavers in modern versions of Windows—screensavers have become significantly less common in an era of LCD screens, which face fewer burn-in risks, and if you try to load one on your laptop, Windows dialog boxes actually discourage you from using them because of the fact that they waste energy you could otherwise use.

8. Palm Resource Code

Era: 1990s-early 2000s

Operating system: PalmOS

Most common file extension: .PRC

A container file format for executing programs on a Palm-derived device, this file format is used for sharing applications built for the early PDA and mobile OS.

One notable quirk of Palm OS is that it doesn’t technically rely on a traditional filesystem, but instead uses a database to store information on the device. As a document on Palm’s file specs put it:

When one of these databases is loaded into a Palm Powered™ handheld, the database is stored in memory in a format that is similar to, but different than the format described in this book. The in-memory format of Palm databases is subject to change and is not documented by Palm, Inc.

So essentially, the PRC file loads the equivalent of an application into a database stored on the device, rather than simply loading the PRC file itself. Fun stuff.


A Nokia E61, one of many Symbian phones made by the company. (Wikimedia Commons)

9. Symbian Software Installation Script (SIS)

Era: 2000s-early 2010s

Operating system: Symbian

Most common file extension: .SIS

While the Symbian operating system, used most famously in smartphones in the pre-Android era, used files in the .APP format or .EXE format when the applications were installed on its final system, these executables were nothing like the ones you might find on a Mac or Windows machine, of course.

Specifically distinct to Symbian, however, is the SIS format, a package format that was used to help install those applications to the device. Essentially, the file format is built around installing and building the application to the device, along the lines of a .PKG file on a modern Mac operating system.

One notable quirk about SIS files is that while they could be linked from the web, the Symbian’s internal browser did not treat them like an executable on most application download sites, so they just appeared as text files within the system, as the book Nokia Smartphone Hacks explains. As a result, you were likely better off downloading the file to a regular computer and transferring them to the Symbian device that way.

Adobe AIR

TweetDeck grew quickly on the back of Adobe AIR, though once Twitter acquired it, they immediately moved away from the programming framework. (via WebUpd8)

10. Adobe AIR Installation Package

Era: 2000s-2010s

Operating Systems: Windows, MacOS, Linux, iOS, Android, BlackBerry

Most common file extension: .AIR

This executable format was in many ways Adobe’s embrace of the fact that Flash had evolved into a native programming environment of its own—think of it as Adobe’s attempt to turn Flash into something like Java.

Its 2008 launch was well-timed, as it allowed the company to take advantage of the burgeoning mobile revolution, adding support for websites with standalone applications that could be extended across platforms to mobile apps. Fittingly, two very famous apps were created with the AIR technology—Angry Birds, one of the earliest viral mobile games, and TweetDeck, an alternative Twitter client for power users. It was a great way to get around Steve Jobs’ thoughts on Flash.

Technically this is not truly dead, but in a maintenance mode. In 2019, Adobe handed off the development reins of this software to the Samsung subsidiary Harman International, which is maintaining it in part because it is used for a number of enterprise use cases. Notably, Harman revived a key use case that Adobe killed—Android support.

This decision to maintain it only for enterprise use does have some dissenters—a petition has called on Adobe to open-source the technology, though it only has 16 signatures. Maybe you might feel compelled to make it 17.

If you follow that story arc of file formats pretty closely, you might notice something interesting—over time, the formats grew increasingly complex and niche.

Adobe AIR, for example, was essentially a stand in for all of Flash’s capabilities in an executable format, while the .COM format essentially didn’t live to the modern day because it had strict limitations on its design. Sometimes, the executables weren’t actually executables, but simply treated that way by the operating system, such as in Windows’ handling of the .PIF.

And to be honest, formats are still evolving. WebAssembly is basically the hottest thing on the planet right now from a programmer standpoint, and it’s essentially an executable format for Web browsers.

Were some things made executable that perhaps shouldn’t have been? Sure. I bet Microsoft, with all its traditional security challenges, is probably regretting its decision to treat screensavers as a form of executable file.

Making executable files front facing was a necessity of an earlier era of computing, but I have to imagine companies like Google and Apple just want you to think about using the application, rather than how the sausage is made. The problem with that of course, is that there’s still sausage, and someone will be curious to look under the hood to figure out how it was built. I’m sure someday Apple will figure out a way to ensure you never think about executing files ever again.

Everything has to execute somehow. The question is whether you’ll get to see it.


Find this one an interesting read? Share it with a pal, and please—practice safe file execution. You don’t want to get a virus.

And thanks to The Sample for giving us a push this time. Be sure to subscribe to get an AI-driven newsletter in your inbox.

Ernie Smith

Your time was just wasted by Ernie Smith

Ernie Smith is the editor of Tedium, and an active internet snarker. Between his many internet side projects, he finds time to hang out with his wife Cat, who's funnier than he is.

Find me on: Website Twitter