I have misread you then. I suppose the main problem that Unix solved
fifty years ago was the need for OS on a not very big (but cheap!)
machine. There were quite a few such systems and various such 16,
18-bit machines. So Unix was one of many, and what made it successful
was rewriting in C (I think I have read about it somewhere). Various
guys ported C compiler to their machines and to test it, they compiled
Unix sources (I am sure I have read about this). So as C gained
popularity, so did Unix gained popularity and C was the prog lang of
Unix, thus with every new Unix install C gained even more popularity.
Ouch!!! This is so much important that you have missed in this statement, as this is a great example of not seeing the forest because of all the trees. You are right that C and UNIX's success was intertwined but I think you are missing the drivers for that. They were successful because of other things and because they were successful, we have them today.
So, Tomasz let me try again .. as an old f*rt that lived this era and played a role in it. Wrote some of the memos that 'justified UNIX instead of a commercial solution, etc.' UNIX was hardly a slam and it could have easily not been successful, a lot of things had to occur for the result we see today.
First ignore UNIX, Multics, or anything else. Please concentrate on the systems that IBM, BUNCH, DG, and DG had in the 1960s and 1970s. An IBM term was 'access method.' Every program has to use a specifically defined scheme to read the data: ISAM/VSAM or in DEC's case RMS. One of my friends once said of RMS, it was not so bad that RMS had 256 to a thousand optional features on each QIO call, but Culter had to check for each one of them sequentially. Yecch!!!!!
Unix as a programming system was a real breath of fresh air -- just treating files as an unstructured bag of bits and the program figure out how to deal with them was giant and very much against the thought of the times. And if you used ASCII, not a binary format, it means that humans might even be able to debug it the system using the data!! Don't write huge programs to solve every possible problem you encounter with your system. Instead, write little ones that can be hooked together and reuse the different smaller programs. Build a library of complete simple programs.
BTW: UNIX was not the only system in those days exposing these types of ideas. I believe that it was Bert Sullivan (Ivan's brother) who built a system at Lincoln labs that using what IIRC was Simula objects, that could hook up small things together to manipulate something larger - not unlike Doug's pipe ideas. This stuff gave way to the later OOB programming movement [and I would suggest much of the C++ we live with today too, but I digress].
The idea of lots of little programs that cooperate with each other is not what IBM and the like wanted/was providing. They were selling closed 'solutions' complete SW systems ("walled gardens" controlled by them or their programming minions) and yes needed the big iron they sold. Note the IBM 'solutions were not sold to engineers, their products were sold on the golf course to the 'managers' of what we know call IT shops.
FWIW: DEC was in a strange position. It had come from serving the engineers, but systems like VMS have slowly become more and more interesting to the enterprise and that was a much more lucrative market. Remember what did Charlie Brown (AT&T's CEO) do after they were broken up -- he wants to go after IBM!!! AT&T's new marketing folks even change the name of the codebase from the 'Programmers Workbench' to 'System III' because they are afraid 'programmer' will not play well in enterprise sales.
The point here is that the 'enterprise type of system is really different than engineers at BTL, Lincoln Labs, much less in the research campuses of important universities.
The important thing is that the latter group (not enterprise) did not have as much money but was a completely different population. UNIX is 100% a 'Christiansen style Disruption' ( read his book completely if you have not, please). It's a 'lessor technology,' running on smaller equipment, targeting a new and different consumer who does not care that it is 'not as good' as the established products. If you compare UNIX to IBM's OS or VMS for that matter, UNIX does not have the 'features' that are valued by the 'enterprise market.'
Ken/Dennis, et al, clearly do not care -- they were building something they (the engineers) needed and wanted (thankfully). And yes it had to run on modest hardware because that is what they could afford and had access to. But because since the HW was modest, that forces a mindset of what are we really doing on the SW? How can we do it effectively. The designers are asking an important research question? Maybe some of these other schemes are not necessary.
You are correct the C grew because of UNIX, but you kind of have it backward. I'm a perfect example of what happened. These new microprocessors from Intel/Zilog/Moto/MOS Tech became available to us (engineers mind you). Hey, I was at CMU in the mid-1970s, I even had access to the BLISS sources, but most people did not. A BLISS cross compiler binary cost $5K per CPU!!! And by the time what would become the M68K shows up (I had access to the experimental chip that was not numbered) I was at Tektronix and I then did not have BLISS sources. But I did have the UNIX sources and those included a C compiler that dmr had written for the PDP-11. So I retargeted it. Same story with Steve Ward's crew in the RTS at MIT, although they used both dmr and Steve's compilers. I know that same song played again at Purdue, also in UNSW, as well in the EU in a couple of places if you look on the USENIX tapes.
It was not that we tested our compiler by porting UNIX. We wanted a C compiler for whatever program/project we had for these new devices. Most of the time we cross-compiled on our local UNIX box, of course. This was true of the C8086 and Z80 tools I had in 1978/79. But we all ran it on our PDP-11s or later Vaxen. It takes a few years before 'JAWS' start and we see all the UNIX ports, but the C vs. Pascal wars were well underweight by that time, and the UNIX vs. VMS vs. TOPS vs. Tenex vs. VM/CMS vs. TSS vs. MTS, etc. wars had already become the stuff of legend.
The key point is that UNIX was inexpensive and worked on modest hardware. Yes C came with it and that is why I think we use it not BLISS, BCPL, or some flavor of PLx today.
It's simply a Christiansen style Disruption Technology -- something valued by a new market that grew faster than the old market. But the problem we have with UNIX is as it displaced the old market, the old ideas/behaviors of the other players that survived started to added back into the new system their old scheme (with new names mind you -- but the same effect).
i.e. those not willing to learn from the errors and why success occurred in history will repeat the errors of before. Sadly, I have personally lived this statement multiple times in my professional employment.