That is not quite true, the C specification defines the standard headers, and there are many facilities thereof which don't make much sense outside of an OS (environment, filesystem, dynamic memory allocation, threads, ...)
There is a somewhat restricted subset of C called "freestanding", which is not required to accept every "strictly conforming program", specifically the standard only requires a small subset of the standard headers to be implemented: <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>. Everything else is optional, and may be implementation-defined rather than standard-conforming.
Support for operating system facilities in no way implies those facilities are necessary.
filesystem, dynamic memory allocation, threads
All of which can be (and has been) done without an OS. Besides, there is no native C language support for any of those things. Those things are usually (but certainly not always) done by library calls, not language primitives.
My underlying point is that the premise of the question is mistaken. It's assuming that an operating system is required in order to have a programming language. That is simply untrue, and is particularly untrue for C, which is very commonly used to program microcontrollers that have no operating system. I'm working on one such system right now.
C existed as a cross platform language long before there was a C standard specification or standard headers. Specifically, C was introduced around 1972 and the first standard was 1989. (Wikipedia). There were C compilers for non-Unix systems during that time (e.g., Borland Turbo C for MS-DOS around 1987). (Wikipedia).
I was using C compilers for micros well before those upstarts like Borland and MS (or even DOS) came around. The first micro I used C on was a Cromemco System III, running CP/M. That machine was built in 1977, I think, although I was using it a few years later than that.
Comments
That is not quite true, the C specification defines the standard headers, and there are many facilities thereof which don't make much sense outside of an OS (environment, filesystem, dynamic memory allocation, threads, ...)
There is a somewhat restricted subset of C called "freestanding", which is not required to accept every "strictly conforming program", specifically the standard only requires a small subset of the standard headers to be implemented: <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>. Everything else is optional, and may be implementation-defined rather than standard-conforming.
Support for operating system facilities in no way implies those facilities are necessary.
All of which can be (and has been) done without an OS. Besides, there is no native C language support for any of those things. Those things are usually (but certainly not always) done by library calls, not language primitives.
My underlying point is that the premise of the question is mistaken. It's assuming that an operating system is required in order to have a programming language. That is simply untrue, and is particularly untrue for C, which is very commonly used to program microcontrollers that have no operating system. I'm working on one such system right now.
All true, it is also the reason why POSIX takes the role of the "C standard library" that didn't fit into ISO C.
C existed as a cross platform language long before there was a C standard specification or standard headers. Specifically, C was introduced around 1972 and the first standard was 1989. (Wikipedia). There were C compilers for non-Unix systems during that time (e.g., Borland Turbo C for MS-DOS around 1987). (Wikipedia).
I was using C compilers for micros well before those upstarts like Borland and MS (or even DOS) came around. The first micro I used C on was a Cromemco System III, running CP/M. That machine was built in 1977, I think, although I was using it a few years later than that.
The K&R C dialects were anything but portable, specially in non UNIX platforms.
There was hardly anything much portable across RatC, Small-C, and other K&R C subsets.