8 ms·

I can see his point but it seems to rely on redefining what the term "API" means. You could as well say "The Windows API isn't just .NET - it's Win32 and a whol

by zik 4y ago

I can see his point but it seems to rely on redefining what the term "API" means. You could as well say "The Windows API isn't just .NET - it's Win32 and a whole lot of other things". Which is kind of true, but we don't usually call all of those things an API. We call some of those individual parts APIs, just like we do with UNIX. And other parts we'd call filesystem conventions and so on. I think he's arguing that you need to know all of those things to program with the OS and he's right, but that's still not how we conventionally use the word "API". It's more of a "standard" and the POSIX standard actually does define a lot of this.

jart 4y ago
The API is the tip of the topological order of interfaces provided by the platform. For example, .NET would NOT be Windows' API because .NET depends on WIN32 (or even more appropriately, NTDLL) which makes .NET important but non-essential. It doesn't make sense to define "the API" as including all the layers of turtles that wrap the canonical one. Just like we wouldn't say that the UNIX userspace utilities like cp/mv/ls are "THE unix API" because those tools all depend on the system calls. On UNIX the system call interface is THE api for the UNIX operating system, and it IS what people commonly refer to as the C API. It's just a more formal definition of the C API and it is defined by the Open Group. It's abstract and language agnostic because it's provided by well-understood and widely encoded binary interfaces which have been defined to nearly exactly model the abstract so-called C definition. Therefore when we say "C API" we aren't necessarily including things like all the manipulations possible in an implementation intended only for a single language like C, e.g. glibc header files or a thunk that irons out some weird piece of legacy assembly technical debt like 386BSD's affinity for the carry flag. Because unless kernels are willing to implement the same degree of SYSCALL instruction fascism that Microsoft implements with NT then no UNIX vendor really has the right to make that claim that the ordinals they copied from the System V codebase. So people who think that "system Libc" and "system API" are the same thing are generally missing the forest for the trees. Dynamic shared objects are stupid and they aren't systems. A libc is just a tool for interfacing with real system apis.

by zik 4y ago

jart 4y ago

The API is the tip of the topological order of interfaces provided by the platform. For example, .NET would NOT be Windows' API because .NET depends on WIN32 (or even more appropriately, NTDLL) which makes .NET important but non-essential. It doesn't make sense to define "the API" as including all the layers of turtles that wrap the canonical one. Just like we wouldn't say that the UNIX userspace utilities like cp/mv/ls are "THE unix API" because those tools all depend on the system calls. On UNIX the system call interface is THE api for the UNIX operating system, and it IS what people commonly refer to as the C API. It's just a more formal definition of the C API and it is defined by the Open Group. It's abstract and language agnostic because it's provided by well-understood and widely encoded binary interfaces which have been defined to nearly exactly model the abstract so-called C definition. Therefore when we say "C API" we aren't necessarily including things like all the manipulations possible in an implementation intended only for a single language like C, e.g. glibc header files or a thunk that irons out some weird piece of legacy assembly technical debt like 386BSD's affinity for the carry flag. Because unless kernels are willing to implement the same degree of SYSCALL instruction fascism that Microsoft implements with NT then no UNIX vendor really has the right to make that claim that the ordinals they copied from the System V codebase. So people who think that "system Libc" and "system API" are the same thing are generally missing the forest for the trees. Dynamic shared objects are stupid and they aren't systems. A libc is just a tool for interfacing with real system apis.