Let me approach this as one cranky old programmer from the 70's to another(?)
One common technique in the old days when we were writing a library was to have an "init" call that created some kind of "cookie" (usually a pointer or array index). Then we'd force the client to supply the cookie back to us on every other call to the library. That allowed us to do whatever bookeeping our library required (in a re-entrant manner) without bugging the client with all the implementation details. As a C programmer you should be very familiar with this style, because C uses it for all its file I/O, as did Unix. Microsoft liked to call them "handles" instead of "cookies". Unix called them "files" or sometimes "file handles".
A large amount of what OO languages do is to just add some extra syntax around this technique. Now instead of all your calls starting with LibnameCallname (cookie, ... they start with cookie.callname(.... But really, in a lot of ways this is just a syntax change to make things easier for us programmers (saves us typing that extra unneeded Libname on everything).
Now in a way, OSes (including Unix, which used the file as its basic paradigmn for damn near everything), are already OO, and have been OO for decades. How they handle OS calls is really just a linkage detail. It doesn't matter much to us as systems programmers, except that the linkages have to match. The only real problem with calling C++ from C isn't that its "OO". The problem is that C++ uses some custom name-mangling algorithm for its symbols, which not all C compilers can deal with.
In truth, there's a bit more to it than that. However, if someone were to write all their new OS calls in C++, you can bet the C compiler vendors would find a way to bridge the gap, so that you could call them in your comfy old LibnameCallname(cookie,... style from C.
What you are actually saying you don't like it seems to me is what Parnas first referred to back in 1972 as Information Hiding - The idea that developers can be more productive if the details about how the various parts of a program work are hidden from the other parts.
It was very contraversial at the time. Even as late as the early ninties I used to hear big arguments about it. Fredrick Brooks even argued against it in The Mythical Man-Month. (BTW: If you haven't read TMM-M, you need to.)
The thing is, almost nobody argues against it today. There is a reason for that. Even Fred Brooks admitted he was wrong twenty years later. From his esay titled, Parnas was Right, and I was Wrong about Information Hiding -
Parnas was right, and I was wrong. I
am now convinced that information
hiding, today often embodied in
object-oriented programming, is the
only way of raising the level of
software design.
To be fair, both sides would agree that on very small systems (like, for instance, the embedded systems you have been playing with?) information hiding is not nearly as nessecary. It is only when systems start getting really large that a fully interconnected system will start falling down under its own weight. However, today most programs are that large. That's the main reason the arguments have ceased.
