[dagmx]

You’re conflating ABI with primary language for frontend development.

Android, iOS and “PC” all use the C ABI at their C stack level. They just have different languages available for their primary SDK.

Windows doesn’t use a C api primarily for example, so your PC example is wrong. Mac shares the same frameworks as iOS so is no more Swift/objc than iOS. It’s just that you can’t really ship electron (JIT) or easily use Qt (licensing) on iOS. But you can just as happily develop entire apps in the same C as you could on a “PC”. Case in point, blender builds for iOS.

Android is definitely the most out-there of the platforms because the jump from JNI to Java SDk is quite large but that is completely orthogonal to what you’re incorrectly claiming. Your comment is conflating completely opposite ends of the stack, but if we go by your definition, Android is Linux just as much as Linux distros on desktop.

[surajrmal]

Just because you can use it from C doesn't mean it's a C ABI. You can do almost anything from C, but the semantics of the APIs require additional work in order to use correctly. Just because golang can interface with C doesn't mean C APIs have a golang ABI right?

[dagmx]

Which of the platforms (other than Android) require you to do extra work to talk to the underlying system API with a C ABI?

iOS certainly doesn’t require any extra work, and even exposes several C api for frameworks as well (not even including ObjC).

And even in the case of Android, the system provides JNI facilities so it’s not foreign to the system.

[pjmlp]

ABI is the language used to write the OS, thus OP is kind of right.

While Windows has moved away from pure C, and nowadays has ABIs across C, C++, .NET, COM, WinRT interfaces, you can still program Windows applications in straight C.

The caveat is to only use APIs up to Windows XP, and Petzold's book to follow along.

[dagmx]

They’re describing higher level API that may have a separate ABI than the lower level system.

But like I said, they’re conflating the lower level ABI with the higher level API/ABI.

All the systems they mentioned have an equal C ABI available for talking to the core system.

[pjmlp]

No they don't, you cannot use C in Android outside the NDK, and even on the NDK you need to go through JNI for 80% of the OS APIs.

This is the only set of APIs exposed via a C API to Android applications,

https://developer.android.com/ndk/guides/stable_apis

You can argue that JNI technically is exposed via C, yeah if you ignore the JVM/ART semantics that go along with it.

Likewise on Windows, technically you can use bare bones structs with function pointers to deal with COM, use CLR COM APIs to call .NET via reflection, and a similar story with WinRT, but it is not going to be fun, and then there is the whole type libraries that have to be manually created.

[dagmx]

I think we’re talking past each other, and you’re largely repeating what I already covered .

My original response delineated between levels of the stack, and also already called out that Android requires you to use the NDK/JNI to use the C ABI.

I also specifically called out windows as well.

My point is that the original persons distinction of what supports a C ABI is conflating different levels of the stack. It’s not a useful distinction when describing the platforms and the windows case is why I quote “PC” since desktop semantics vary quite a bit as well

A more useful delineation of why mobile dev is harder to just do an asm hello world is that mobile dev doesn’t really have a concept of CLIs without jumping through some hoops first. So you have to pipe such a thing through some kind of UI framework as well.

[pjmlp]

If userspace needs to use NDK/JNI ABI to call the Linux C ABI, naturally the OS ABI isn't the C ABI, by definition.

[dagmx]

Why not? The NDK/JNI calls are still in user space themselves. So what delineation are you trying to make here?