If one is making an operating system, clearly the API that application authors use is extremely important. The whole point of an operating system is to run them. What I want to talk about is fundamental APIs, or the lowest stable level.
If you have even a passing awareness of the evolution of Microsoft Windows over the last 25 years, you know there have been a lot of APIs that have appeared, been promoted and marketed to Windows developers, and then either deprecated or relegated to just an “option”. For example, MFC. However, these APIs are all wrappers. The only time the fundamental Windows API broke incompatibly (I believe) that 16 bit applications don’t run on 64 bit; see X86-64. But the point here is that since the introduction of 32 bit Windows NT in 1993, if you coded to that API, your application will still run. If your application still runs, that means it’s the same operating system.
More recently, Microsoft for a while was promoting .NET heavily, arguably more than any of their frameworks before. It’s important to understand that at its introduction, .NET was still fundamentally a wrapper. For a while, there were rumors that it might become a fundamental API, but with the introduction of Windows 8, that won’t happen. For a really great read on this, see this ArsTechnica article. Especially fun to read are the bits about the politics, which the article only mentions in passing – you can find more scattered about the internet, like here.
Now Microsoft is saying something huge: all new APIs will be based on this new WinRT thing. Your old Win32 apps won’t break, but this time we have reason to believe they’re pretty serious – this really is the new fundamental API, and if you want your app to use new features, you will have to use WinRT. You can access WinRT from plain bog standard C, even if it’s not beautiful.
How does all of this relate to GNOME and GTK+? I think WinRT validates where we’ve been doing in GNOME with GObject Introspection. GObject may not be the most concise thing in the world (though it definitely beats C/COM), but the combination of a pure C base with added metadata and runtime support mean that all of our fundamental APIs (basically the GTK+ stack, and notably GIO for non-GUI programs) remain accessible to C and also available in other runtimes and languages.
There’s a lot more to do on introspection – we desperately need a complete documentation generator for example. It’s also pretty clear to me in that in order to truly succeed, we need to “downgrade” C to be a consumer of the API rather than a source, i.e. we need to do what Microsoft has done and define interfaces in an IDL. That will be interesting to do while still keeping around the old C APIs that don’t match the projected C binding.
TL;DR – I believe GNOME’s approach of using C with metadata and minimal runtime hooks as a fundamental operating system API is the right course, and we should keep doing what we’re doing.
Colin Walters 
Excellent read
I’ve always thought GTK should be marketed with Vala/C++/Python/etc, and C only mentioned if you really want to go there, as C is great building block, but doesn’t always lend itself to a nice user interface
I’m currently working on extracting documentation out of gir-files.
The current approach is pretty neat: It’s all about finding & implementing a minimal docbook-subset.
My wish-list for our documentation stack is pretty short:
– Get rid of all textual memory descriptions in favor of gir-annotations.
– Inform binding maintainers about the name of our self-ptr in gir.
That’s it. 🙂
+1 from me. GObject and software stack accessibility is important, if we want to be a platform. Nice read.
Wake me up when we can write gnome-shell extensions in C or other languages that support GObject-introspection.
Is WinRT really the “lowest” level? I thought it was just a replacement for win32?
I suspect it will still be built on top of the Nt/Zt functions.
@Random Any details on that? Maybe a repo? Some efforts have been started on that direction and may be good to have some degree of coordination.
The GIR has 2 big problems holding it back right now.
The first one is that you can’t use different “consumers” in the same process space. You can’t have a C program have both a python and ruby GObject extensions. And this isn’t because of ruby/python but because GObject doesn’t support it. This is a problem of not having a main CLR like .Net.
The second one you touched, because C is the base and not a “consumer” of GIR then there are little things that only happen in C code. It used to be things like GtkTreeIter would have memory problems, (don’t know if they fixed that since the last time I used it) or implementing the different data models.
I think the best solution would be to change it so that gtk has a main process that does everything, and all the languages (including C) communicate with it with a Gtk API like we know but is sent over dbus. This has the main advantage of allowing much more flexibility in terms of VM’s wanting to communicate between themselves. (Have Ruby code pass data over GObject to Javascript) And would also free up the main process to make sure the UI is silky smooth and not blocked by some data handling code.
I really like the idea of GObject-introspection but in practice it has proven to be impossible to use it to generate good bindings for .NET using gir. It is my understanding that this is down to a need for additional annotations. Are any such changes in progress for gir?
(if the issue needs explanation I would suggest talking to Andreia Gaita as she is well informed on the subject and as expressed a desire to help get the problem resolved)
Pingback: GNOME DevX, FOSDEM « Colin Walters