The PC and clones were very slow writing to the screen if you used the BIOS or DOS so it was widespread practice for application programs to write directly to the memory-mapped screen, do I/O space operations, register interrupt handlers, etc.

Thus application code often looked like device driver code, maybe you (the application developer) wrote code that wrote to the screen directly or you used libraries that did. By the late 1980s there were text-mode UI frameworks that supported resizable windows, the mouse, and widget sets like you’d use in a GUI application today.

Just like most C dialects outside UNIX, but for C it counts as features.

There were portability issues with C compilers, for example, value preserving vs sign preserving integer promotion rules.

But Pascal was unusable without extensions. I mean that. I wrote programs in Pascal.

For example, Wirth's Pascal had no provision for programs that had more than one source file.

I wouldn't consider RatC or Small-C that usable without the pile of Assembly code they needed to be usable beyond bare bones control flow statements.

Like I say, two weights two measures.

Nothing was non-trivially usable on an IBM PC without a pile of assembly code.

Integrating C with assembly was easy. Pascal originally didn't support that at all. And academics were utterly horrified by things like Turbo Pascal.

The usual argument, C extensions for inline Assembly and dialects outside UNIX, no problem, it was great.

The fact that Pascal extensions existed, and Modula-2 as evolution from Pascal was a standard since 1978, doesn't count.

Even the bad early C compilers were far more usable than Pascal. I know this, because where I worked at Data I/O we tried a whole bunch of them - Pascal, Fortran, and C.