Hi Jiri Zr,
People don't use C because it has any tangible benefit to alternatives. C is an unsafe, insecure language and people use it because it's established, and partly because they are intimidated by new things. Tell people that the proper way to write C application in HelenOS is using new, better API that doesn't work anywhere else... and they will not bother, because it's silly.
I think you are mixing too many things together. Let's break it up, shall we?
(a) The core language of C (I am not considering the Standard C Library in this paragraph) really does not provide many sophisticated automatic safety and security guarantees, but that does NOT preclude anybody from implementing safe and secure programs in C, as can be demonstrated by projects such as seL4.
(b) On the other hard, the Standard C Library specifies (or used to specify in past revisions) some function calls that are indeed inherently and unavoidably unsafe, e.g. gets(). I believe we should avoid such parts of the ISO C at all costs, even if that means that we might shoo away potential contributors that are accustomed to use gets(). The benefits of having gets() and this particular potential contributor who insists on it just don't pay up the drawbacks.
(c) There are two fundamental categories of microkernel OS projects. One category tries to adhere to the legacy standards and APIs as closely as possible (e.g. GNU/Hurd, MINIX3). The other category tries to define its native API anew in a way their developers consider the most appropriate, despite still using a legacy core language such a C or C++ (e.g. Genode, HelenOS). Going even deeper and using a custom programming language and toolchain would be entirely possible, but probably too much of a hustle for most OS projects (there are exceptions). Thus we choose a middle ground: Using an existing core language with its existing tooling, but reshaping its run-time as we see fit.
This is what defines HelenOS. This is the purpose of the existence of HelenOS in the first place, in my opinion. Somebody who wants to use HelenOS, but insists on having the same and only native API as he/she is accustomed to from say GNU/Linux, is simply not making a good match. It's perfectly fine then for him/her to not bother to use HelenOS. It's totally NOT silly -- on the contrary, it's a perfectly logical decision that I support. I don't want HelenOS to be a better GNU/Linux than GNU/Linux.
The design of the native API is a fundamental differentiator between various (microkernel) OSes. If I wouldn't believe that it is worth designing our own native API (which of course goes hand-in-hand with the software architecture of HelenOS), I would see no reason to work on HelenOS itself. I would rather contribute to a different OS project in that case.
(d) Having said that, there is NO dichotomy between the native API and the possibility to provide a compatibility layer(s) for legacy APIs. We provide it, Genode provides it (in a totally different way), etc. Thus I really don't buy this "we lose contributors because we have a non-standard native API" argument. We can have a non-standard native API (even in a well-known core language) and at the same time accommodate ported applications via different means.
(e) It is entirely possible to implement our native API in different environments besides HelenOS, thus providing the compatibility the other way around. So for example newcomers to C could easily adopt our native API as their first API and then live with it in other environments, too. This might sound improbable, but there are actually several (usually portable) frameworks/libraries for C and C++ that try to completely replace the de iure Standard C Library with itself, defining a different and independent de facto standard -- based on the core C language, but replacing the API.
[BTW: Win32 API is yet another example of this. I haven't coded a Windows application for a long time, but I believe one does not have to touch any ISO C functions ever when coding in C in Windows.]
(f) There are simply too many diverse reasons why people are using C. I really think you are overgeneralizing in your assessment. We can probably agree that most people nowadays do not pick C because of its perfect and timeless design, but I still believe that the decision is fundamentally based on two components: The core language (syntax, intrinsic language constructs) and the run-time API.
It is easily possible to like the core C language and dislike the Standard C Library, thus there is always a space for an alternative run-time API in C.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
