Linked by Thom Holwerda on Mon 7th May 2007 15:39 UTC, submitted by Kelly Rush
SkyOS After months of work, there is now a new complete C++ API for SkyOS, which replaces the old C API. The C++ API consists of more than 150 classes, including support for thread and process information, full GUI support, and gesture support, to name a few. Additionally, news about the LiveCD and some of the technology behind it has been updated, including a few screenshots of the LiveCD in action.
Order by: Score:
Onwards and upwards, SkyOS!
by Almafeta on Mon 7th May 2007 15:47 UTC
Almafeta
Member since:
2007-02-22

I'm just waiting for the SkyOS team to support my HD so I can try it out...

Reply Score: 4

Kudos to Robert
by Kelly Rush on Mon 7th May 2007 15:52 UTC
Kelly Rush
Member since:
2005-06-30

Robert has been working on the C++ API for quite a while now, and while I'm sure he would rather have been working on more visible stuff, this is probably one of the biggest and more important updates SkyOS has had in a long time. Kudos to him on sticking through it. ;)

Reply Score: 5

Colour me unconvinced
by nevali on Mon 7th May 2007 16:01 UTC
nevali
Member since:
2006-10-12

I don't yet know the details of this, but there's a reason why every OS provides APIs in C: just about every language out there can call functions written in C. Unless you make use of a binary language-agnostic standard like COM, the same doesn't generally apply to C++, Objective C, or indeed any of the other object-oriented languages out there.

As a developer, only having a C++ API would make me quite cautious.

Reply Score: 5

RE: Colour me unconvinced
by Shannara on Mon 7th May 2007 16:36 UTC in reply to "Colour me unconvinced"
Shannara Member since:
2005-07-06

I agree, Robert have just limited the development on SkyOS to just C++ type languages. Effectively removing a lot of the developer community ... Way to go ;) I was looking forward to developing on SkyOS, now Robert made that impossible.

Reply Score: 5

RE[2]: Colour me unconvinced
by Almafeta on Mon 7th May 2007 16:50 UTC in reply to "RE: Colour me unconvinced"
Almafeta Member since:
2007-02-22

Aren't most languages nowadays Cplusplus-like, anyways?

Reply Score: 1

RE[3]: Colour me unconvinced
by BrianH on Mon 7th May 2007 17:14 UTC in reply to "RE[2]: Colour me unconvinced"
BrianH Member since:
2005-07-06

Aren't most languages nowadays Cplusplus-like, anyways?

No, particularly not at a binary level. On many platforms C++ code isn't even compatible with that generated by other C++ compilers on the same platform.

The object model of most OO languages nowadays is single inheritance with interfaces, not multiple inheritance like C++. Many of the newer languages are even more interesting than that, but in completely different ways than C++ on a semantic level. Even on a syntax level most languages that supposedly are derived from C++ have more in common with each other than they do with C++, having fixed many of the glaring mistakes of the C++ syntax in similar ways.

Still, the C language is so semantically weak that it really is a poor foundation for an API. C has mostly been used as a least-common-denominator language, both its strength and its weakness. A strength, because its semantics can be a subset of most languages, so it can be possible to write code to interface to C libraries. A weakness, because the language is so limited and unsafe that you have to write lots of wrapper code around those libraries just to be able to use them safely and easily.

At least with C++ you can write a powerful API that does most of the work for you, as long as you are careful in the design of that API. If you are careful enough the API can even be designed with easy interoperability in mind. We'll have to see if that is the case here.

Reply Score: 5

RE[4]: Colour me unconvinced
by Vanders on Mon 7th May 2007 18:07 UTC in reply to "RE[3]: Colour me unconvinced"
Vanders Member since:
2005-07-06

On many platforms C++ code isn't even compatible with that generated by other C++ compilers on the same platform

 The cross-vendor C++ ABI solved that problem several years ago. Unless you are using old compiler(s), but otherwise it's a non-issue these days.

Reply Score: 3

RE: Colour me unconvinced
by JonathanBThompson on Mon 7th May 2007 16:54 UTC in reply to "Colour me unconvinced"
JonathanBThompson Member since:
2006-05-26

If you know C++ well enough and design correctly, it is actually entirely possible to create a C++ API that's compatible with every language that can call C linkage functions, and it won't look significantly different regardless of which language is used. However, most C++ people are too purist to have considered it, or think it's ugly, whatever...

I gave a presentation on the solution I proposed at WalterCon 2006 in reference to solving the Fragile Base Class problem, which is something that's likely to sooner or later become an issue with the SkyOS C++ API. It requires a major change in the API, of course, so there's no backwards compatibility with existing code.

Reply Score: 5

RE[2]: Colour me unconvinced
by Vanders on Mon 7th May 2007 18:08 UTC in reply to "RE: Colour me unconvinced"
Vanders Member since:
2005-07-06

Do you have a link to your presentation or the material you presented?

Reply Score: 2

JonathanBThompson Member since:
2006-05-26

I'm not aware of any videotape of my presentation, and I did it off of a few notes I wrote up, which are not a full formal document, sadly. The best I can do is without typing everything fresh as a dump of my brain is provide links to others that commented about it that were there, and IIRC there's only really one person that posted that online.

Look under the heading for Sunday, October 29th, second paragraph, here:

http://haiku-os.org/news/2006-11-01/my_experience_at_waltercon_2006

WalterCon is a rather informal affair, with just a hint of organization of cats attempting to herd cats ;)

Reply Score: 1

RE[2]: Colour me unconvinced
by Shannara on Mon 7th May 2007 18:40 UTC in reply to "RE: Colour me unconvinced"
Shannara Member since:
2005-07-06

The point is, if Robert wiped out half the development community, or did what you suggested above. I have not found anything on the site yet, to convince me that he did as you have suggested.

Reply Score: 1

RE: Colour me unconvinced
by vege on Mon 7th May 2007 19:52 UTC in reply to "Colour me unconvinced"
vege Member since:
2006-04-07

but there's a reason why every OS provides APIs in C


Not every. Just to mention the better known ones: MFC for Windows is C++, so is the whole BeOS (plus Haiku, Zeta) API.

Surely, there are darker and lighter sides of a decision like this. This one lets the coders do more powerful coding, while enshorting the list of compatible platforms. It may be worth.

Edited 2007-05-07 20:06

Reply Score: 1

RE[2]: Colour me unconvinced
by JonathanBThompson on Mon 7th May 2007 20:09 UTC in reply to "RE: Colour me unconvinced"
JonathanBThompson Member since:
2006-05-26

As both a BeOS developer and a Windows developer (amongst other things) let me clarify:

MFC is not an API, but rather a fairly thin C++ wrapper/frameworks around the C API of Windows.

Also, not the entire API of BeOS/Zeta/Haiku is pure C++: there are quite a few things in them that are straight C, even in the GUI API, but most definitely anything that talks to the kernel is straight C.

Reply Score: 2

RE[2]: Colour me unconvinced
by galvanash on Mon 7th May 2007 20:24 UTC in reply to "RE: Colour me unconvinced"
galvanash Member since:
2006-01-25

Not every. Just to mention the better known ones: MFC for Windows is C++, so is the whole BeOS (plus Haiku, Zeta) API.

Although you are right on BeOS, it is most definitely the exception, not the rule. And even then it is not a pure C++ API. Be's API is a C++ wrapper around a C based kernel. Technically, it could be considered a framework, but since it is the _primary_ programming interface for the OS calling it an API is entirely appropriate.

As for MFC, it is not an API at all. It's a framework and the 2 are not the same thing. Windows has a C API (Win32) just like Linux (and just about every other unix variant). MFC is conceptually equivalent to GTK++, it is a wrapper around a C API.

I personally think replacing a C based API with a C++ one is a bad decision, and I dont think that is really what we are talking about here. Although the article states this is a C++ API, Im pretty sure it is actually a wrapper around the existing C API.

I could be wrong but if I am I question the sanity of the development team as throwing away a working C API and replacing it with a C++ one is essentially starting over - EVERY piece of software written for this OS would be instantly rendered incompatible. Im pretty sure that is not the case here.

Reply Score: 2

RE[3]: Colour me unconvinced
by vege on Mon 7th May 2007 21:21 UTC in reply to "RE[2]: Colour me unconvinced"
vege Member since:
2006-04-07

(also @ JonathanBThompson)

Yes, there are exceptions for BeOS, although the main concept is having a C++ API for the OS which practically forces any not strictly low-level software to be developed in cpp.

Due to the meaning of the term we are talking about (Application Programming Interface), MFC is an API which - of course - does not cover the whole OS API (= is not the Windows API), but in some ways quite important part of that and also is an "official" push to go with C++. I admit, I was not properly clear while mentioning, sorry for that.

And yes, I would also be interested to know if the announcement is about a whole replacment or just a new layer - or somehow combined. I also think an all-radical decision could be very confusing for the whole development process.

Reply Score: 1

RE: Colour me unconvinced
by OSGuy on Mon 7th May 2007 20:34 UTC in reply to "Colour me unconvinced"
OSGuy Member since:
2006-01-01

I am a C++ programmer my self and I would have to say that in my opinion C++ is a better way to go. Having class-based API or to be more precise, Object Oriented API is more powerful and flexible than pure C based APIs.

Edited 2007-05-07 20:36

Reply Score: 1

RE[2]: Colour me unconvinced
by nevali on Mon 7th May 2007 21:32 UTC in reply to "RE: Colour me unconvinced"
nevali Member since:
2006-10-12

I am a C++ programmer my self and I would have to say that in my opinion C++ is a better way to go. Having class-based API or to be more precise, Object Oriented API is more powerful and flexible than pure C based APIs.


Many C APIs are object-oriented, they just don't require an object-oriented programming language in order to be used.

The idea of needing an OOP language to write in an OOP fashion is a fallacy I thought had died out a decade or so ago.

Reply Score: 3

RE[3]: Colour me unconvinced
by bnolsen on Tue 8th May 2007 03:46 UTC in reply to "RE[2]: Colour me unconvinced"
bnolsen Member since:
2006-01-06

If anything c++ as a language allows the compiler to be more "anal" and also allows the code to be more self documenting than 'c'. However it requires a bit of experience and a ton of discipline to make this a reality.

Compilng c++ using max warnings and keeping away from templates (stl), and multiple inheritance should result in fast compiling, fast executing and very portable code.

Templates really aren't that bad, but c++ is hurt with scoping issues where closures aren't allowed, which would be awesome for writing understandable stl adapters.

If there only were a "perfect" language...

Reply Score: 2

v Here come the flames...
by bobjohnsonmilw on Mon 7th May 2007 16:05 UTC
v comment locked?
by helf on Mon 7th May 2007 16:37 UTC
RE: comment locked?
by Adam S on Mon 7th May 2007 17:08 UTC in reply to "comment locked?"
Adam S Member since:
2005-04-01

Since when do comments get locked and cant get voted back up?


"Comment locking" has been around since v3 rolled out, there just wasn't a way to show it in the UI. Future comments about moderation will be voted down. If you want to discuss it, create a conversation on v4 beta.

Reply Score: 1

RE[2]: comment locked?
by Anonymous Penguin on Mon 7th May 2007 20:51 UTC in reply to "RE: comment locked?"
Anonymous Penguin Member since:
2005-07-06

Adam, this makes it an absolute mockery of peer moderation: either you have it or you don't (I was never in favor of peer moderation to begin with).
I'll boycot posting in this place and I'll make a hell of a fuss everywhere else until this issue is solved.

Reply Score: 0

RE[3]: comment locked?
by Adam S on Mon 7th May 2007 20:58 UTC in reply to "RE[2]: comment locked?"
Adam S Member since:
2005-04-01

I'll make a hell of a fuss everywhere else until this issue is solved.


There's no issue, AP. When certain posts are modded to -5, they get *automatically* locked (most of the time, it doesn't even take an admin to autolock a post, the system knows when a comment is that bad based on certain factors). It's always been that way, and it that certainly doesn't make a mockery of anything.

This is, and always has been, an admin controlled site. So, although we allow our readers to do 95%+ of the moderation, some comments we intentionally lock down. And in those cases, I don't think we need to justify our actions.

That said, I'll remind you, it's been this way for 3 years now, and no one has complained because it wasn't transparent. If it's only a problem now that we've shared more of how the site works, that's certainly a convincing reason to lock it down further and keep our readers in the dark.

Reply Score: 1

RE[4]: comment locked?
by Anonymous Penguin on Mon 7th May 2007 21:10 UTC in reply to "RE[3]: comment locked?"
Anonymous Penguin Member since:
2005-07-06

"That said, I'll remind you, it's been this way for 3 years now, and no one has complained because it wasn't transparent."

Then I am missing something, because till today I had always been able to mod up a post with a -5, and I did it quite often.

Reply Score: 1

RE[5]: comment locked?
by Adam S on Mon 7th May 2007 21:15 UTC in reply to "RE[4]: comment locked?"
Adam S Member since:
2005-04-01

Then I am missing something, because till today I had always been able to mod up a post with a -5, and I did it quite often.


Not all of them. There are MANY locked posts, and like I said, the algorithm means most of them were locked by the system, not an admin. If you want to discuss, please open a "conversation" on v4 beta and we can continue this. I don't want to have a major subthread in this SkyOS article.

Reply Score: 1

RE[3]: comment locked?
by mikesum32 on Mon 7th May 2007 23:01 UTC in reply to "RE[2]: comment locked?"
mikesum32 Member since:
2005-10-22

It's a rather asinine thing to do. "We know what's best for you."

Reply Score: 2

RE[4]: comment locked?
by Johann Chua on Tue 8th May 2007 03:44 UTC in reply to "RE[3]: comment locked?"
Johann Chua Member since:
2005-07-22

Repeat after me: The Internet is NOT a democracy. Moderators are not fascists or dictators. Your civil rights are not in danger.

Reply Score: 2

RE[5]: comment locked?
by __xodam__ on Tue 8th May 2007 20:54 UTC in reply to "RE[4]: comment locked?"
__xodam__ Member since:
2007-04-06

Repeat after me: The Internet is NOT a democracy. Moderators are not fascists or dictators. Your civil rights are not in danger.


Now I can't say about this board, but trust me, certain moderators are indeed quite fascistic, once i was banned from a history forum because the moderator didnt like my references to historic facts, I was unbanned by the admin and other moderators immidiately, I can only pitty that not many forums are like that one.

Edited 2007-05-08 20:57

Reply Score: 0

Open demo
by Almafeta on Mon 7th May 2007 16:58 UTC
Almafeta
Member since:
2007-02-22

Now that the SkyOS page is working again, here's the most interesting thing:

"A limited freely available Demo LiveCD will be available in the near future."

This is interesting. People have been grumbling that only beta testers have been able to use Sky; hopefully, this will change once they get the chance to actually have it in their hands.

(No new build is available to beta testers, though; that's unfortunate, because I want to see if I can run it now that support has been added for more hard drives.)

Reply Score: 1

@Almafeta:
by Robert on Mon 7th May 2007 17:05 UTC
Robert
Member since:
2005-07-06

Did you actually submit a bug report about this issue? If so, you should have gotten a notification with information how to get the newest alpha build including this fixes. Please let me know if you didn't get one. (please use PM on the forum)

Reply Score: 4

RE: @Almafeta:
by Almafeta on Mon 7th May 2007 17:18 UTC in reply to "@Almafeta:"
Almafeta Member since:
2007-02-22

No; I posted on the beta forums, and was told it wasn't a goal of SkyOS.

If that was wrong, I'll post a bug report.

Reply Score: 2

SkyOS API
by jello on Mon 7th May 2007 17:20 UTC
jello
Member since:
2006-08-08

I suppose the C++ API sits on top of the C API.
This said both should be available to developers.

As a beta tester I can't wait to try it out.

EDIT: typo

Edited 2007-05-07 17:21

Reply Score: 1

RE: SkyOS API
by Robert on Mon 7th May 2007 17:32 UTC in reply to "SkyOS API"
Robert Member since:
2005-07-06

partially. For instance the FileManagement/Query/Process/Date/Time/DesktopCommunication etc. classes make use of the native C libraries where appropriate. Obviously the new API doesn't replace the standard C library at all.
GUI classes as well as a few new Utility classes are "native" C++ implementations, meaning that they will replace to old libskygi C library completely.

Reply Score: 5

Comment by Darkness
by Darkness on Mon 7th May 2007 17:25 UTC
Darkness
Member since:
2005-08-27

BeOS also had/has a C++ api..., you don't here anyone complaining there ;-)
Edit: and C++ API is not a wrapper around C API, it's a completely new API

Edited 2007-05-07 17:28 UTC

Reply Score: 5

WoW
by Lakedaemon on Mon 7th May 2007 17:32 UTC
Lakedaemon
Member since:
2005-08-07

Changing from PE to ELF
Changing the API from C to C++
(partially) Porting Wine and Java...

Robert is a man of many challenges ^_^

I wonder what shall come next for SkyOS.

Anyway, congrats Robert !

Reply Score: 4

c++ is fine for bindings
by elanthis on Mon 7th May 2007 17:57 UTC
elanthis
Member since:
2007-02-17

You can write a language binding for a C++ API just fine for almost every single interesting language, including Python, Java, C#, Lua, Perl, etc.

C++ is link-compatible with C (when symbols are exported using extern "C"). If a runtime can load C modules, it can also load C++ modules with C entry points, and thus it is absolutely no harder to write C++ modules than it is to write C modules for those runtimes.

Reply Score: 3

RE: c++ is fine for bindings
by nevali on Mon 7th May 2007 18:51 UTC in reply to "c++ is fine for bindings"
nevali Member since:
2006-10-12

C++ is link-compatible with C (when symbols are exported using extern "C"). If a runtime can load C modules, it can also load C++ modules with C entry points, and thus it is absolutely no harder to write C++ modules than it is to write C modules for those runtimes.


Er, yes, of course you can export symbols as extern "C", but only functions which are compatible with a C-style calling-convention: you can't export class members, or for that matter whole classes, let alone namespaced symbols (without losing the namespacing). If every API was declared extern "C", there wouldn't be any sense in calling it “a C++ API", it'd just be "a C-style API that happened to be written in C++ [entirely an implementation detail]". Producing "a C++ API" ceases to be an implementation detail, because it dictates the language bindings you must use unless you're incredibly careful. And yes, BeOS's APIs were all C++, but aside from projects like Haiku it's not really had a lot of longevity; it would be stretching the truth a little to say that BeOS's API was a good example of a successful C++-only API.

As has been said, the C bindings are typically the greatest common factor between languages (which is both a strength and a weakness, of course), which is why they're provided. There are methods—such as (XP)COM—that you can use to make C++ classes callable from non-C++ code, but you really have to plan ahead for it. Inevitably, as soon as you create bindings for any sort of interpreted language, you'll find that you're having to encapsulate your classes in very C-like wrappers.

Reply Score: 2

RE[2]: c++ is fine for bindings
by BrianH on Mon 7th May 2007 19:13 UTC in reply to "RE: c++ is fine for bindings"
BrianH Member since:
2005-07-06

Inevitably, as soon as you create bindings for any sort of interpreted language, you'll find that you're having to encapsulate your classes in very C-like wrappers.


Unless your language is either open-source (or extensible with native-code extensions like REBOL 3), at which point your wrapper code will only be as C-like as your language's underlying source code (or plugin API). A well-designed modular language implementation can wrap C++ code with ease, particularly if it already needs to on other platforms and so is prepared for the task.

Reply Score: 2

Adam S Member since:
2005-04-01

My Post gets -5 rating? WTF?!?! The flaming already started when i posted this.


Hey, if the last comment didn't deserve it, this one certainly did. Look what your peers did to you: they handed you a big fat -5 in minutes.

Reply Score: 1

bobjohnsonmilw Member since:
2006-04-06

Wow. I've officially lost any hope for this site comments if that's the case then.

I've staved off the ridicule i get for reading this site from coworkers, now I'm off of it completely.

they handed me a -5 for proactively trying to stem the impending flamewar?

i'm at a loss for words...

See ya. Apparently this site is overly moderated, and thus, useless.

It's been fun osnews. I've been reading here for like 5 years or so. It was good until you started allowing comments.

Reply Score: 0

Adam S Member since:
2005-04-01

they handed me a -5 for proactively trying to stem the impending flamewar?


You were modded down, and I think everyone knows why: you started your comment daring people to reply, and then you posted an off-topic comment ranting about the mod system that YOUR FELLOW READERS applied to you. That's against the forum rules and you were properly penalized. There ARE portions of the site where you can discuss it, you chose the wrong venue, and you were dealt with. Those are the site rules, always have been. I'm sorry you're upset with them, but if your mind is made up -- see ya.

Reply Score: 1

bobjohnsonmilw Member since:
2006-04-06

I'm not upset with the rules, I'm not upset at all. What is annoying is that yet another site has been ruined by it's moderation system, and the abuse of it. If you really think that my post was flamebait, then it's clear why the quality of articles posted, and comments have continued to decline. Additionally, I didn't start anything about the moderation system until it was used stupidly.

Sheesh, I remember when the internet still had an actual purpose, other than being full of people trying to make themselves feel important.

Reply Score: 0

Adam S Member since:
2005-04-01

Ok... ok. The mod system is what it is, for better or worse. It seems to work fairly well and keep most of the trolls at bay. At this point, I guess I'd ask you to

1. Take it offline with me or anyone else. If you want: adam at osnews DOTCOM.

2. Take it to the conversation here http://www4.osnews.com/conversation/463fdd2d which is already about moderation

3. Accept that peer moderation has its downsides and move on

or

4. Actually leave.

I hope you choose one of the first three, but if we continue on here, you're probably going to get modded down again, as am I.

Reply Score: 1

Chicken Blood Member since:
2005-12-21

A suggestion if I may:
Don't get hung up on the modding system. It's fundamentally flawed as people can't be trusted. Just ignore it. Who cares if some loser didn't agree with what you wrote and decided he would flout the modding rules? Just pity him/her and move on.

Reply Score: 0

Nice move
by computrius on Tue 8th May 2007 00:42 UTC
computrius
Member since:
2006-03-26

This is a very good move on Roberts part. Somehow gui design just seems to go hand in hand with object oriented programming better.

Reply Score: 3

C++ APIs are not binary resuable (?)
by agnus on Tue 8th May 2007 09:29 UTC
agnus
Member since:
2006-05-10

But is it not that C++ APIs aren't binary reusable except by using the same language AND the same compiler AND the same versions of both the language and the compiler? For example:

namespace Foo
{
class Bar {
public:
virtual void echo(char* text);
}
}

How could the binary implementation of the above be reused from any other language and / or compiler?

Edited 2007-05-08 09:30

Reply Score: 1