What, if any, is the distinction between runtime engines and operating system components?
One distinction might be where it came from. I’m using LabVIEW, which requires a runtime engine to execute its programs, but that came from National Instruments, not Microsoft. So, runtime engines that come from somebody other than the OS creator are obviously not part of the OS.
But what about, say, the .NET framework? That includes a runtime engine.
Seems to me both are examples of code that stays resident and services request from programs, which would not be able to run without them.
Operating systems are the way that the programs, whether they be application programs, server daemons, runtime engines, etc… interact with the hardware. This means that the OS controls access to the memory, the processor and the various other components.
Runtime engines, at least the way I understand them, are sort of somewhere between an operating system for applications and an interpreter, and require operating systems to run.
In the case of something like an Xbox or other gaming console, certain runtime engines could be integrated into the operating system- in particular graphics might benefit from that. But more general purpose computers don’t usually have anything like that.
My understanding is that runtime engines are “part” of an operating system the same way Notepad, Solitaire, and Internet Explorer are – meaning they may not be strictly necessary, but they’re often bundled and installed together with the core OS regardless. Eventually, other programs (first or third party) start to assume the runtime’s presence and depend on it, gradually increasing its importance over time until it’s taken for granted as being part of the installation. That’s what happened to DirectX and Internet Explorer (marginalizing OpenGL and Netscape), and I believe that’s what Microsoft wants to do with the .NET runtime.
ETA: But keep in mind what friedo said. And the term “operating system” is also somewhat vague, depending on how many bundled applications you want to include in the term.
Just my $.02 that applications that ship with an OS are not part of the OS, they are just applications that ship with it.
A runtime engine (or sometimes “runtime environment” or sometimes just “runtime” as jargon) is whatever is needed to establish an environment for some application to run. This is usually something beyond what is provided by the OS but could be, as **friedo **says, part of the OS.
IMHO a runtime engine is not part of the OS if you remove it and the only thing that breaks is the application it supports, even if it uses libraries that ship with the OS. (From the OS perspective, a JVM is an application.)
“What is the difference between a runtime engine and ‘part of the operating system?’” One of them you have to install separately.
Every (non-embedded?) OS includes at least one runtime environment composed of libraries and running processes. Windows ships with native runtimes for Win32 and POSIX. The DOS subsystem and .Net run on top of Win32 so might “not really count,” but I don’t see that as a good criterion.
There are some very simple “OSes” that essentially offer no runtime environment (are just a bundle of simple drivers). In this case, though, you might as well say you’re running on bare metal.
There are also OS’s that are wholly dependent on a runtime engine - the Oberon Machine and it’s successor Bluebottle would be one. The microkernel includes the Oberon language runtimes, and the entire OS is written in Oberon (including device drive modules) - with JIT compilation, it would be possible to load the device dependent kernel and run the rest of the OS from source.
The amount of goods that ship with so-called operating systems really blurs the line these days, especially in the consumer segment. Is Windows XP an operating system? Of course, but is it just an operating system? It includes applications that are arguably apart from the operating system, but then we come back to Internet Explorer (IE). Remember the “bundling” lawsuits? Microsoft argued that IE was an integral part of the operating system, because so much of the interface depended on its libraries’ functionality. Was it really part of the operating system, or just a part of the user interface, or just part of the window manager? Or look at Linux: is Gnome part of the operating system, even though you could use any other window manager instead, or even none at all? You could say that if it’s in the kernel, then it’s part of the operating system. But what about loadable modules? What about Windows where parts of the UI were (or still are?) actually in the kernel?
A runtime isn’t an OS, nor is a framework like .NET.
All kinds of stuff gets bundled with an OS as a nicety, but isn’t actually “part of” an OS.
We’ve got the term “operating system” as used by consumers, which means one thing. That refers to the operating system sold by an OS vendor as well as all the nice stuff that the vendor saw fit to include with the OS installation media figuring that it would make you more likely to choose the product.
Then we’ve got an actual “operating system” as the term is understood by programmers and OS architect types, which includes rather less stuff. We can all agree that it includes code for memory management and controlling the hardware I/O on the various system buses. Beyond that, things get fuzzy and you wind up with something closer than a religious debate than a GQ.
So, I conclude the difference is subject to debate and reflects what somebody believes an OS is; and OSs often include runtimes that are needed by at least some applications, which are pretty easy to think of as part of the OS; and of course other parties provide runtimes that make their product work but aren’t used for anything else, which are much harder to claim as as part of the OS.
And if you poke around inside a runtime, the technology there doesn’t necessarily look different depending on whether it’s always included with an OS versus from somebody else.