27

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 peice of software will run natively on my computer? Is there likely to be software already on my computer that runs natively?

6
  • 2
    "native" implies it's designed to run on whatever platform/os it's on
    – yuritsuki
    Apr 16, 2013 at 3:30
  • Me neither... it seems like the moderators have a difficult time reading questions...
    – user30033
    Apr 17, 2013 at 2:35
  • 5
    @faB You do realize that no moderator was involved in closing the question?
    – slhck
    Apr 17, 2013 at 8:15
  • I admit, the question title made me think of the difference between running a "program" under either an "operating system" or on the processor itself (e.g. direct hardware access). Apr 17, 2013 at 18:28
  • It's not that the question is bad per se, but it's not good for this site. As evidenced by the answers, it's not something that can be answered cleanly and has a number of arguments surrounding it, which makes its closing entirely appropriate according to the FAQ.
    – afrazier
    Apr 20, 2013 at 17:21

5 Answers 5

44
+50

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.

A 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. VirtualBox emulates 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 than emulating them in an isolated environment.

A 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.


Miscellaneous

Corrections

* Thank you, Michael Kjörling, for catching some issues with this answer.

Other

The difference between "native" and "non-native" is not black and white. (Credits to afrazier)

5
  • 3
    Minor nitpick: (it's VirtualBox, not VirualBox, and) VirtualBox does not emulate the operating system, it emulates the hardware. So you can install any operating system you like in VirtualBox (subject to virtualization limitations), or even write your very own from scratch.
    – user
    Apr 16, 2013 at 8:42
  • 1
    Native also often implies that it's using the primary library set and API for the underlying platform, which can make distinctions a bit fuzzy. There's quite a few people who don't consider .NET applications to be "native" like Win32 API applications are "native", and similarly some people don't consider a KDE program running on a Gnome desktop "native".
    – afrazier
    Apr 16, 2013 at 13:17
  • @afrazier: That's because .NET applications are designed to run on the "Common Language Runtime", and need a compatibility layer to run on Windows. Or a different compatibility layer to run on Linux.
    – Ben Voigt
    Apr 16, 2013 at 13:46
  • @Ben Voigt: It's still a first-party API, the binaries are compiled to native x86/amd64 code (whether at runtime by the CLR or in advance with ngen), and the framework has been shipped with recent versions of Windows. This is part of a larger argument though, and not really appropriate here.
    – afrazier
    Apr 16, 2013 at 14:21
  • Virtual Box is not technically an emulator but a Virtualizer. An emulator of times passed has always emulated completely different hardware. Under a virtualizer, the OS & software actually runs natively on the host CPU. The difference is that the devices are virtual or emulated. It's a minor technical difference that even the Virtual Box website points out here: virtualbox.org/wiki/Virtualization
    – hookenz
    Apr 17, 2013 at 4:41
4

Native code is usually used as opposite of platform-indepedent code. If you run native software, you are running a compiled binary and not, for instance, a platform-indepedent script such as javascript or Java bytecode. Compiled C or compiled C++ are the good examples of native code.

3

There are surprisingly a couple possible answers, but the standard usually is: code compiled to the opcodes for the CPU, and running against the programming libraries of the OS that booted the computer. In this case, most code you run will be native code. Maybe some counter-examples will clear things up.

Java is not native code. It is compiled to an intermediate bytecode, which is then run on the specific chipset. Java can call native code. Eclipse is a great example - for speed, Java calls out to some platform native graphics calls.

If you run WINE, an MS Windows API emulator, that is not native code. Though you're executing code designed for that chipset (x86), you are not running the code for the OS that booted it, but replacement libraries. MAME runs binaries for different CPUs AND operating systems.

Scripts are not native code. They are written in a higher level language which then has to be converted at runtime to code that runs on your CPU.

There are some blurry lines. Your web browser runs as native code,, but it can also run Java (compiled to bytecode) or Javascript (a script interpreted language).

1
  • .NET, VBA, XUL, IA-32 (on AMD64 CPUs, at least), ...
    – user
    Apr 16, 2013 at 8:46
3

It depends a lot on the context. To me, "native" means an application uses the features and mechanisms the operating system provides, rather than rolling their own. That can apply to user interface features (buttons, windows, file-chooser dialogs), as well as to features under the hood (e.g. integration with "Open with...").

For example, on Windows, a native app would use "WinAPI" to get the same buttons, scrollbars, etc. as other applications. They behave exactly the same in system apps (notepad) as in native third-party apps.

Java applications often use "Swing" and look completely different, because they draw their controls themself, rather than using the system ones. The benefit is that the program looks the same on every OS.

Another option to build a GUI is a cross-platform toolkit like "QT". QT will ask the OS to draw the controls for it, so they should look very much native, no matter whether you are running Windows, OSX, or Linux. A QT text box will look just like a windows textbox, however it isn't exatly a native one, but a kind of emulation. You might notice small differences in the details (e.g. the context menu, input methods, etc.).

Note when people say "native", they often mean a program is compiled to machine code rather than to an intermediate code, which is ran in a virtual machine (like Java and .NET programs). In the above examples, the WinAPI and the QT app are using machine code, whereas the Java program is compiled to Java bytecode. This usage is a bit problematic nowadays, because many users would consider a well done .NET application native for Windows - it is just an .exe, uses the exact same controls and APIs under the hood, and is almost indistinguishable from a program compiled to machine code.

Likewise, I'd consider a program that uses GTK, knows about the Unix file system structure and perhaps comes in a .deb package native for Ubuntu or Gnome. There are even first-party Gnome apps written in javascript that one could call native! The same applies to Windows 8 "Metro" apps, that can be written in a variety of languages, some compiled, some not.

2

To put in more abstract terms, it's like letting someone else your trust executing a program in a different language.

  • Native means the OS will use the fastest, simplest dialect he knows, binary.

    Pros: fast, large availability of language that can talk to each other since it's down to metal. Cons: security, complex API, restricted to OS capabilities, also compilers are hard to make, because a program, once compiled, is released into the wild.

  • Not native, means your code will not be executed directly by the OS. He can be executed in many many different ways, the main ones being interpreted and running a bytecode version of your program in a virtual machine.

    Pros: the API almost ever change, so it's much easier for programmers to work (at least when they stick to this particular language). Cons: performance (it's often a mild decrease, it can rarely become a problem), and not everyone will actually use this particular language, so it can also be a problem to adopt this technology. Security can also be a problem, but it's much more under-control. Somehow.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .