I was already coding C and C++ at the age of 16, having learnt Timex BASIC, Z80 and 6800, Turbo BASIC, GW-BASIC, Turbo Pascal, in the previous six years, starting with Timex BASIC at the age of 10.

It helped the books I got with my Timex 2068, the local library, the computer magazines with listings like the British Input ones, and our school computer labs with MS-DOS. 3.3.

Not 8, but surely at 10.

We surely did, in those days you couldn't get computer games when you felt like, even pirated ones.

You either endless played the fews that you had, or eventually got to learn BASIC, and the more curious ones could even got one of those machine language books from the local library.

Which is why notions like freestanding, monitor and such also exist.

Channels are basically messaging queues in Java.

Kind of, the mistake was not doing like PL/I where besides default machine specific sizes, the developer could explicitly assert the required sizes.

Is that really that much of a big deal, though? Before stdint, if one needed that level of accuracy, one would do your own equivalent of stdinit by hand, and adjust those definitions when porting to another compiler/platform. The same goes for your local boolean type.

I think the only real annoyance is that each programmer/team did it with their own convention (I32, INT32, i32, int32, WORD, Word bool, BOOL, Bool, etc., etc.); standardizing helps with putting everyone on the same page more than it helps porting. It doesn't prevent people from reverse-typedef-ing standard names to local "dialectal" names, though.

But I also think that one should only rarely use raw integer types, in an ideal world; the elephant in the room is that typedef is kind of the second "billion dollars mistake" [1]. C is a weakly typed language and there's no practical way to undo it (besides transpilation), so there's double no point to leave behind raw types.

[1] For those not too familiar with C, typedef defines a "type alias", not a type: https://en.cppreference.com/cpp/language/typedef

The deal was dealing with #ifdef spaghetti to define all of those, especially when mixing libraries across platforms.

Ifdef soup is still horrible, so those times (which I didn't experience firsthand) must have been abysmal.

If you want to know how bad it can be, only need to take a look at GCC's implementation of `stddef.h` for `size_t` and `ptrdiff_t` etc.

https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/s...

There's a simpler way to define these types in newer versions of C which have `typeof`, we can take advantage of the fact that `sizeof()` always returns a `size_t`, `ptr - ptr` always returns a `ptrdiff_t`, and a literal L'c' has type `wchar_t`, etc.

    typedef typeof(sizeof(0)) size_t;
    typedef typeof(nullptr) nullptr_t;
    typedef typeof((void*)0-(void*)0) ptrdiff_t;
    typedef typeof(L'\0') wchar_t;
    typedef typeof(u8'\0') char8_t;
    typedef typeof(u'\0') char16_t;
    typedef typeof(U'\0') char32_t;

Don't need ifdef soup to test what the sizes of things are on different architectures - we just utilize the compiler's implementation of those types.

Traditionally your compiler supported one type of computer and just defined them to what they were on that computer.

C99 kinda fixed that with the `(u)int_leastN_t` types (which are hardly used in practice though). And shame that it took Microsoft 16 years to even start supporting C99 though so we were basically forced to keep using our own custom integer typedefs long after the C standard had fixed the issue.

Agreed, but it could have been there since day one, given the languages in 1960's.

Well, Microsoft has considered C done for quite some time, and after C++20, they don't seem to be in a hurry to keep up with ISO either for C or C++ (there are discussions on support channels about customer relevant C++23 and C++26 features, none on C past C17), similar to how Apple and Google are handling their in box compilers as well.

I thought most implementations of C have stdint (intN_t, leastN_t and fastN_t etc).

These are C99 features which MSVC only got around 2015 (of course a decade later those are safe to use in portable code).

They're also in C++11. When did MSVC get that? Is it also possible they got it before the C++11 standard? And of course Microsoft has its own different spellings: BYTE, WORD, DWORD, QWORD

PL/I among other systems languages predating C, had the ability to explicitly define bit sizes for its types.

C survived because UNIX carried it.

I have had the suspicion for a while now, that any attempted discussions about the merits of C's design that try to connect this to its success, are missing a massive part of the picture if they don't mention UNIX.

We don't make this mistake about JavaScript; nobody tries to argue that the confusing semantics of the "var" keyword or the "==" operator somehow were actually instrumental to its success. It's obvious that JavaScript won because it was what was on the web. Maybe C is not much different.

I don't agree. UNIX was an extremely niche operating system until Linux won the data center, at that time both C and C++ were already extremely popular outside the UNIX world. C won because it was so easy to adapt to new hardware architectures (even GPU shading languages are just minimally extended flavours of C and C++).

> UNIX was an extremely niche operating system until Linux won the data center

UNIX was ubiquitous in the data center well before Linus even posted his first version of Linux on USENET.

Everything ran on SunOS, HP-UX, IRIX, AIX, etc.

Most people only cared about C, because they needed to work on UNIX, and UNIX was taking over the server room and all 1980's graphical workstations.

C was pretty much ignored on 8 bit home computers, outside some toy compilers for CP/M.

In the 16 bit days, it was yet another language alongside BASIC compilers, Pascal, Modula-2, Assembly.

C is so tied to UNIX, that POSIX had to be created so that any non-UNIX operating system could provide a cozy home for their C compilers.

UNIX/POSIX is for all practical purposes the runtime most C applications rely on, there are naturally some exceptions like free-standing or Windows (which eventually gave up and add to start improving its support).

It is only due to historical accident that Microsoft gave up on Xenix, instead of replacing their MS-DOS efforts.

I don't know about you but I need zero POSIX to write C on Windows. Not even much of the (mostly bad) C standard library. I use snprintf for convenience (but I don't have to), and memcpy, that's about it.

And many projects properly abstract their OS layer so they aren't tied to POSIX.

Maybe Unix is tied to C, but C isn't tied to Unix.

> UNIX was an extremely niche operating system until Linux won the data center

?!? What a claim!

Sorry, what? Most of data centers were running a UNIX operating system back in the day. What operating system do you think they were running?

There is a weird moment toward the end of the 1990s when Microsoft is trying to show their NT is a serious competitor in this space.

Traditionally this was a profitable niche, Microsoft would like to take a fat piece of that, and instead what happened is that Linux destroyed the profit margin. A million dollars overhead that would have kept a hungry UNIX® vendor alive on your project didn't turn into an extra million dollars on Microsoft's balance sheet, instead it evaporated because Linux is "free". And so then Microsoft lost interest.

Yeah, and one of the ways to show it was a serious OS for DoD projects was to have a POSIX subsystem, which had they kept it around, Linux would never have taken off on the PC, and there would be no need for WSL 40 years later.

The POSIX subsystem is a box checking exercise. The reason the box was there isn't satisfied but the box was checked and Microsoft hoped that's good enough. If you need "a Unix" and they give you NT and circle the stuff about POSIX you don't go "Oh, perfect" you ask them to fix the requirements document so that you can have an actual Unix next time.

WSL is Redmond going OK yeah, here you go, an actual Unix.

There was also SUA and Interix in the meantime, before WSL came to be.

The point still stands, that POSIX checkbox was relevant enough for spending the money in engineers salary during Windows NT 3.51 development.

It was a requirement on government contract tenders. If you didn't support POSIX, you didn't get the contract and the government would have continued using SunOS or AIX or something instead of Windows NT. Remember that POSIX was designed to make these OSes somewhat interchangeable - they wouldn't order something they knew was incompatible with everything they already had.

WindowsNT was the other operating system of that time.

That's way way later. UNIXes were the ones running in 70s and 80s. WindowsNT and Linux only later came to take a slice and, still later on, Linux won the day. How anyone would consider UNIX "niche" is beyond me.

In the other direction then, IBM mainframes.

With Win32, OS/2 and POSIX subsystems.

My point is that C's popularity quickly outgrew the popularity of UNIX, especially during most of the 1990s before Linux made UNIX accessible to us "PC peasants". Most 1990s PC games were written in C, and C was also the dominant high level language on 16/32 bitters like the Amiga or Atari ST.

Nope, they were mostly written in Assembly.

On the consoles it took until PlayStation for C to take off among game devs.

Additionally many Amiga games used Blitz BASIC and AMOS.

Anyone involved in the Demoscene early days would be 100% Assembly as well.

On PC, it required until Watcom with its great MS-DOS extender for devs to finally move away from Assembly in mass.

> Nope, they were mostly written in Assembly.

I was there, Gandalf ;)

(and note how I specifically wrote "dominant high level language", not "dominant language", since assembly coding was indeed very relevant on those machines, for UI apps 100% assembly was quite rare though, and hybrid C/ASM seems to have been more common).

Dominant in which part of the planet?

In my part of the Iberian Penisula it was Turbo Pascal on PC and AMOS/Blitz Basic on Amiga.

With lots of inline Assembly anyway.

If id Software is any indication, apparently they wrote their games in C since their inception in 1990 with Commander Keen.

> Nope, they were mostly written in Assembly.

It depends: for the classic 8 bit home computers, games were mostly written in assembly. Later DOS games were commonly either written in Pascal or C, but quite a bit off Assembler code was often used for the more performance-critical code sections.

The critics were always disingenuous , ignoring that Modula-2 came out already in 1978, designed for systems programming and fixing Pascal initial flaws.

Also most of those extensions ended up in ISO Extended Pascal revision, also usually ignored in such criticism.