Programs manage resources. Operating systems explicitly manage resources for the benefit of other programs.

I think that is the key notion.

https://en.wikipedia.org/wiki/Operating_system

Handling resources isn't the definition of an OS.

Also asking "what is art?" is not the same as asking "what is an operating system?"

Art covers just about all human activity, the definition is extremely wide. I wouldn't say an OS has a definition that wide.

Providing services to other programs is indeed the key notion.

I learned to program on an SDS Sigma 5. [1] The machine booted by reading the first card in the reader and executing the instructions punched on that card.

The card could be a boot loader to start the BTM (Batch Timesharing Monitor) operating system from disk. Or the card could be a little program all of its own.

A particularly useful one-card program was a card deck printer. You would put it at the front of the deck and boot the machine. This card had a simple loop to read the next card into memory, then print that line on the printer, and repeat until the card reader was empty. (One of my first optimization adventures was modifying the code to be double-buffered: read the next card into memory while the previous card is printing. Twice as fast!)

That card certainly handled resources, but no one called it an OS. It didn't manage and provide services to other programs, it was just a one card program.

Another popular one card program was the bird chirp card. It pulsed the front panel speaker to make it sound like birds were chirping. We didn't think of that as an operating system either. :-)

[1] https://en.wikipedia.org/wiki/SDS_Sigma_series

Early operating systems only had one program run at a time.

What if that one program is a Virtual Machine interpreting bytecodes for a language like Lisp or Smalltalk? From one point of view, only one program is running on the hardware, however many Smalltalk 'Processes' (really, cooperative green threads) could be running simultaneously. This was once the case for Smalltalk. It may have been the case for Lisp machines.

>> Handling resources isn't the definition of an OS.

Well, it certainly is part of the definition of a useful OS. A car doesn't have to be able to turn right. It is still a car, just not a useful one.

Operating system program starts user program.

User program does not start operating system program.

Job done.

VirtualBox is a user program that starts operating system programs.

oooo. Good point. My definition has been corrupted :)

Running programs without an OS used to be the norm not the exception. An OS has at minimum the ability to load and run other programs, additionally it may provide many other functions such as process separation, filesystem access, multi-tasking, device drivers, APIs, and so forth. If you look at the progression of operating systems over time you can see them becoming more and more sophisticated. Back in the early '90s, for example, if you were playing a DOS based video game each game would have to have its own low level drivers for things like video and audio cards. Today the OS handles that and the games just use an API (like DirectX or OpenGL).

I think API’s, and the ability to run different applications, usually within the OS, are the major distinction here.

I think it boils down to the concept that an OS should serve as a middle layer of abstraction between a program and hardware, and provide some sort of meaningful way to make that stream of communication more simple and useable for humans.