When people refer to running native software, emulation, and software compatibility, what exactly are they referring to? Read on as we delve into the concept of native software.

Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.

The Question

SuperUser reader Throsby is curious about what it means to run software natively. He writes:

I’ve been wondering what it means for software to run natively. What exactly is such software and how is it different from software that does not run natively? How can I tell if a given piece of software will run natively on my computer? Is there likely to be software already on my computer that runs natively?

Read on for an excellent analogy explaining exactly what it means to be native on a given system.

The Answer

SuperUser contributor Deltik offers a fantastic analogy that highlights what it means for software to be native and what kind of other software one might find on a given system:

A software is native to a platform if it was designed to run on that platform.

A platform usually refers to an operating system, but it can also be applied to devices such as the Nintendo Game Boy.

Using the Game Boy as an example, it gets its software from cartridges. These cartridges contain code that runs natively on the Game Boy.

Emulators are a layer that allows software designed for one platform to be run on another. For example, there are emulators that can execute images of Game Boy cartridges and allow you to play Game Boy games on your computer or even your mobile phone.

compatibility layer is kind of like an emulator. When 64-bit computers and operating systems became mainstream, they needed to be compatible with the existing 32-bit technologies. Since 64-bit and 32-bit architectures are very different, a compatibility layer is often needed to run 32-bit software on 64-bit machines. For 64-bit editions of Microsoft Windows, Microsoft needed to write a compatibility layer so that 32-bit programs would still work on the new 64-bit system. This is why some programs are often installed to a folder called Program Files (x86), where x86 means “32-bit”.

Compatibility layers tend to be more intimate with the native system than emulators are. VirtualBoxemulates hardware for operating systems*, and the systems that it emulates doesn’t have very much direct interaction with the host system. WoW64 is a compatibility layer in that it lets 32-bit programs run on 64-bit Windows in a more integrated way. WoW64 helps make programs compatible rather thanemulating them in an isolated environment.

translation library is a component of compatibility layers. Whenever binary code is running non-natively, a translation library helps redirect foreign, non-native calls to native calls that the system can understand. Assembly programs written for the original TI-83 might not be compatible with the newer TI-83/84 Plus calculators because some calls that made sense in the TI-83’s architecture may no longer be valid in the TI-83/84+. A translation library (probably included in shells like MirageOS) ensures that calls for the TI-83 go to the new, updated places in the TI-83/84+ calculators.

Platform-independent code is written in a language that is interpreted by something that usually runs natively. For example, PHP is a programming language that is interpreted and executed by the installed PHP binary, which has already been compiled natively for Windows, Mac, and Unix-based operating systems. The PHP code that web scripters write are independent of the platform, allowing the code to work on multiple operating systems as long as PHP is installed for those operating systems.

Have something to add to the explanation? Sound off in the the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.



Profile Photo for Jason Fitzpatrick Jason Fitzpatrick
Jason Fitzpatrick is the Senior Smart Home Editor at How-To Geek. He has over a decade of experience in publishing and has authored thousands of articles at How-To Geek, Review Geek, LifeSavvy, and Lifehacker. Jason served as Lifehacker's Weekend Editor before he joined How-To Geek.
Read Full Bio »