The excuse is to use a reusable OS for game development that installs on a computer and just runs an application. Operating systems change too much and machine coding gets depreciated and broken over time.

The excuse is to use a reusable OS for game development that installs on a computer and just runs an application. Operating systems change too much and machine coding gets depreciated and broken over time.

This is a bad idea, the OS has to change when the hardware changes. (Drivers get you part of the way but unless you are writing the drivers yourself you will be forced to update key components of your OS at some point in order to stay compatible with modern hardware).

Old idea. There's a reason why console development is nice. You have a fixed OS and fixed hardware. Also did you just create three thread one after another? Why?

This is essentially what frameworks like .Net or Java do (although these are far from the first to do this). They specify a virtual machine which is essentially "a fixed OS", and even "fixed hardware" in the sense that the bytecode/instruction set is fixed. The idea, as suggested, is that you don't need to worry about changes in hardware or OS because you're targeting a virtual, as opposed to real, OS/hardware combination that doesn't change.

Actually, anything above assembly can get you a lot of the way there if you use cross platform libraries (assuming they're maintained, but the same is true of the virtual machine or any "reusable OS"). Even C is defined in terms of an "abstract machine". The only problem is that users aren't typically set up to compile code, but languages like Python and Ruby get around this by making compilation typical.

I know of some developers who have written their own virtual machines for ease of porting, but as far as I know they didn't get a lot of use out of the engineering investment - one or two games tops before the abstraction and tool debt became too significant.

Having to dual-boot into a special OS in order to play a game would be a dealbreaker for most. I don't even want to fire up Parallels half the time.