Have you written a serious game engine? Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, that counts as Operating System. This is becoming less true today, as the hardware gets better and bigger and faster and resources are less constrained, but it wasn’t that long ago that many console games literally were the OS.
Your analogy and definition is one reasonable viewpoint, that the OS is the thing that bootstraps software on top of hardware and provides access to resources like memory, filesystem, network, and display, but it’s also an incomplete definition. An OS provides a standardized environment for whatever processes run inside it. In that sense it doesn’t matter whether or not it’s contained in a different OS. Ubuntu doesn’t suddenly become not an OS when you run it in a VM, it still provides the Linux OS to the processes that run inside the VM. Windows doesn’t become not an OS if it boots on a hypervisor. Similarly, even if an OS requires another OS to run, when it provides a different environment or container, it’s still serving the purpose of providing a specific Operating System to the software it runs.
Some consoles used to not provide an OS at all, the game provided all of it. The developer was responsible for handling things that would (and should) otherwise be the purview of the OS or drivers, power loss, out of memory, cables yanked, etc., otherwise they would not be allowed to publish. Nintendo did this longer than the others, in my recollection of events.
> Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling,
I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's truly needed. Or maybe it was needed in the 80s and 90s but not anymore, and maybe the mentality is simply stuck in the minds of game developers.
I remember interviewing a former game developer at a [not game] company, and we started talking about the C++ Standard Library. Candidate insisted that "the STL is slow," and that you shouldn't use it in any production software, and that if he worked on a project that used it, the first thing he'd want to do was re-write it using his own containers and allocators and so on. I would ask him questions like "what is slow about it" and "how do you know where it's slow, as used in our company's application" and "have you profiled any code that used it to find out where it's slow" and so on, and it became clear (to me) that he was probably just operating out of some ancient tribal believe that "STL = slow" that was organically passed on to him from other game developers throughout the decades.
I'm fine with that. I did eventually 'unplug' that game os to the point that it would run standalone on bare metal by adding a couple of hardware drivers.
The point was: to make a game function you have to perform the bulk of the functions that an operating system performs and the similarities are greater than the differences.
Well, Windows / Mac / Linux needs the Bios (or whatever we call it today) to run.
If you can't call those "OS"s, than what really is an OS?
I guess it's turtles all the way down.
> almost every serious game is a complete more-or-less real time operating system
Games tend to have very different requirements and different demands from the OS; they tend to regulate the OS to being (mostly) a hardware abstraction layer. In the late 1990s and early 2000s, it was a lot harder to run games on Windows NT versus Windows 9x because DOS was a lot better at getting out of the way of games.
And I wrote that stuff in the 80's, when your typical 'OS' on a computer was much closer to what a BIOS is than an actual operating system. Usually the games were far more sophisticated in terms of what their internal services provided than the equivalent OS services. The most the BIOS usually did for you was to boot your game code, change graphics modes, handle the keyboard and read and write raw media. Everything else you had to do for yourself.
Today there are far more levels of abstraction, especially when you use the various 3D engines or other large frameworks. But essentially those have taken over the role of a lot of that OS-like code.
dahart|2 years ago
Your analogy and definition is one reasonable viewpoint, that the OS is the thing that bootstraps software on top of hardware and provides access to resources like memory, filesystem, network, and display, but it’s also an incomplete definition. An OS provides a standardized environment for whatever processes run inside it. In that sense it doesn’t matter whether or not it’s contained in a different OS. Ubuntu doesn’t suddenly become not an OS when you run it in a VM, it still provides the Linux OS to the processes that run inside the VM. Windows doesn’t become not an OS if it boots on a hypervisor. Similarly, even if an OS requires another OS to run, when it provides a different environment or container, it’s still serving the purpose of providing a specific Operating System to the software it runs.
Some consoles used to not provide an OS at all, the game provided all of it. The developer was responsible for handling things that would (and should) otherwise be the purview of the OS or drivers, power loss, out of memory, cables yanked, etc., otherwise they would not be allowed to publish. Nintendo did this longer than the others, in my recollection of events.
ryandrake|2 years ago
I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's truly needed. Or maybe it was needed in the 80s and 90s but not anymore, and maybe the mentality is simply stuck in the minds of game developers.
I remember interviewing a former game developer at a [not game] company, and we started talking about the C++ Standard Library. Candidate insisted that "the STL is slow," and that you shouldn't use it in any production software, and that if he worked on a project that used it, the first thing he'd want to do was re-write it using his own containers and allocators and so on. I would ask him questions like "what is slow about it" and "how do you know where it's slow, as used in our company's application" and "have you profiled any code that used it to find out where it's slow" and so on, and it became clear (to me) that he was probably just operating out of some ancient tribal believe that "STL = slow" that was organically passed on to him from other game developers throughout the decades.
jacquesm|2 years ago
The point was: to make a game function you have to perform the bulk of the functions that an operating system performs and the similarities are greater than the differences.
gwbas1c|2 years ago
If you can't call those "OS"s, than what really is an OS?
I guess it's turtles all the way down.
> almost every serious game is a complete more-or-less real time operating system
Games tend to have very different requirements and different demands from the OS; they tend to regulate the OS to being (mostly) a hardware abstraction layer. In the late 1990s and early 2000s, it was a lot harder to run games on Windows NT versus Windows 9x because DOS was a lot better at getting out of the way of games.
jacquesm|2 years ago
Today there are far more levels of abstraction, especially when you use the various 3D engines or other large frameworks. But essentially those have taken over the role of a lot of that OS-like code.