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