OSNews

That's a controversial question, but most kernel developers would say there is no advantage to writing kernels in C++ rather C because the kernel is the part of the system that does resource management, especially memory management, so we prefer to write in languages that don't do any implicit resource management (other than the call stack) in order to maintain maximum control.

I think there's a few factors here.

First is that kernel developers feel comfortable with C. C++ is a multi-paradigm language and when you have other developers starting to write crazy templates, or insanse object hierarchies, other people aren't going to appreciate their way of thinking.

C is simple. You've got macros, structures, and functions. That's it. There's much less room for "creative" types that want to inject wacky way of doing things.

There's no reason you can't write a successful, tight kernel in C++. It's just that it would probably work better with a tight knit group of developers, and not the freestyle of the linux kernel.

Well, why not?

There are a lot more than 2 FOSS Unix systems in the world.

But please tell me: why do people feel the need to ask 'Why?'? It seems pretty obvious not every OS has the same set of priorities and goals.

Yeah, every OS has the same priorities and goals: Provide a nice interface for programmers and users. However, NOT EVERY SYSTEM needs to be a Unix clone. I agree with the gist of the OP, we've got too many Unix workalikes around.

However, NOT EVERY SYSTEM needs to be a Unix clone. I agree with the gist of the OP, we've got too many Unix workalikes around.

No, not every system needs be a unix clone.

However, as far as OSes go, Unix has a lot going for it as a hobby or educational OS.

1) Well documented. Lots of books and articles document the internal architecture of a Unix OS.

2) Tool suite. Writing a Unix kernel gives you access to the vast array of GNU tools which adds meat and functionality to your OS quickly.

3) Examples. Minix, Linux, BSDs, etc all provide ample working examples you can refer to when crafting your hobby OS.

With a Unix based OS, you pretty much need to write the kernel, implement enough necessary system calls and compile up a bunch of free software to flesh the thing out and give you something that you can work easily with.

If you wanted to write a VMS clone, you get to write the kernel, shell, editors, utilities, etc.

Creating an OS today, particularly a Unix inspired one, is not particularly rocket science, but that doesn't make it a trivial task. Still of lot of basic work coding the fundamentals, writing your device drivers, and debugging the darn thing.

And once you write one OS, then you have ideas on what and where to go next. It's difficult to have those idea simply using an OS, or even reading their code. You need to work through the problems that others did to better understand why and how things are done, so you're better educated on why you should or should not change them.

If you wanted to write a VMS clone, you get to write the kernel, shell, editors, utilities, etc.


Why should all new kernels be clones?

There are already 2 F/LOSS Unix system in the world: BSD and Linux, why is there a need for a third one?

There is already one dominant OS in this world, why still create a site called "OSnews"?
Because he fellt like it, that's probably why but it doesn't matter, what matters is that you too can enjoi it, and ignore when you think is too much.

... We think there is no essential difference between c and c++ without ...

Even single inheritance is a significant difference between C and C++ semantically. Constructors, and their side effects, make the language behavior enough different to matter to a kernel developer.

Not saying that this is necessarily bad, only that it's a real difference.

You would have been right if you had typed it "Unix" which is the way the name of this new OS is written anyways.

"UNIX" is the concept, "Unix" is the trademark.

I immediately wondered about the name and wondered if they had secured someone's blessing that had some historical claim to the name. But I can find no mention of the issue on their site at all.

That business about UNIX vs Unix won't cut it if the trademark lawyers start cruisin' for a fight. A number of years ago, if I remember, QNX had to run ads declaring that QNX is not Unix. And that name doesn't even have U or I.

The only thing I can figure is that they expect the for educational purposes clause to save them.

http://www.invalidsoftware.net/home/modules/news/

That's a whole bunch of people writing kernels in C++, some of them with exceptions. Personally, I can say that my kernel's use of exception handling has made development/debugging go at least 1.5x faster than without.

Choices is one of the older C++ operating system
kernels in existence. http://choices.cs.uiuc.edu/
We have recently added exception handling support and done some initial evaluation as well.
The paper is at
http://choices.cs.uiuc.edu/exceptions.pdf

What a blast from the past. I'm surprised that the paper doesn't reference Brevix, which codified the interruption-into-exception model of hardware exception handling back in '93. Of course, Brevix exceptions were language-independent, and designed in from the begining.

It's interesting to see how Choices has bolted-on an exception model.

I look forward to seeing how you develop a fault model that incorporates Choices exceptions

Well, the first screenshot says:

COPYRIGHT (C) 2005 NUAA CS DEPT.

from the site:
Copyright © 2005-2006, The UnixLite Software Foundation

from whois:
...
Registrant Organization:Nanjing University of Aeronautics and Astronautics
...
Registrant City:Nanjing
Registrant State/Province:Jiangsu
Registrant Postal Code:210001
Registrant Country:CN
...

You are right! AS/400 do run and run and run ....

We have and 810 box and the machine pretty much requires no maintenance at all. Although, it does do a PWRDWNSYS on the weekends for safe measure. The interface is a breeze to work with. I can move through the screens an eye blistering rate. Mostly I work with output queues and writers which is by far better than anything in windows or even lpd.

Almost everything on our box is homegrown. We do not use a package other than for EDI and AS/2. We have in-house RPG programmers. RPG was never a laguage that I can get into (fixed form is eewwww), but it does do the job quite well whether it's for screens, reports, you name it.

Unfortunately, upper management tends to see the AS/400 as an old dinosaur because it doesn't have a pretty GUI. Of course, you can write a client/server GUI application but the green screen is far superior in my opinion.

The AS/400 can run Unix stuff as well. Perl has been ported to it as well as other similar applications. If it can run in PACE, then you're good to go. It also does SMB (like Samba) so I can see the AS/400's network drives.

Oh, and everything is an object. A lirbrary is an object, a member is an object, etc. The OS is an object oriented OS where everything is an object.

The only thing I have issues with is that there aren't any open source methods of accessing the AS/400 data. I mean, there doesn't appear to be and open source ODBC driver or any anything of that nature that can maybe work with perl, python or php. So, let's say I wanted to setup a FreeBSD webserver to access AS/400 data then I can't. Unless, I maybe use Linux binaries running under emulation (which I have never tried) but who would really want to do that? For me, it's either all or nothing. I guess maybe the only other alternative is Java and JDBC, but then I'd have to copy packages and stuff over from Websphere Studio or something.

All in all, the AS/400 is a solid machine. I just wish it was more 'open'.

IBM's OS400, which runs their AS400/iSeries servers, which sell like hot cakes, and which run and run and run and run and run for months and months and years and years, and that customers love, is written in C++.


That would be quite interesting if it were actually true. The part of OS/400 applicable to this discussion (the SLIC, or System Licensed Internal Code) is written in Assembly. The SLIC handles most of the duties that the kernel in a Unix would be handling plus quite a few more. OS/400 proper may be written in C++, but the kernel certainly isnt, and mostly for exactly the reasons usually given for why implementing a kernel in a high-level language is stupid.

ps. And no, saying that it is only a hardware abstraction layer is not correct. The SLIC implements an entire virtual machine (the MI) for OS/400 to run on top of. All user level programs and the OS itself run on top of this VM, and the VM hides most stuff one would normally associate with the kernel from the user (and even from the OS) (memory management, low-level scheduling, etc). Its quite a bit more than just a HAL.

I'm not up to date on the details of the history of the AS/400, at least architecturely. But I know the machines existed bak in the late 80's, and I know the current machines run PPC CPUs. It was always my understanding that the legacy software still runs on the current machines.

Was the VM that deep in the system, where applications are written to the VM, not the core processors? or do they pull a similar trick like Apple did/does with their 68K->PPC->Intel layers.

Anyone know?

Yes. It was that deep. The MI has been part of the AS/400 design since inception (1989).

I should clarify a bit. OS/400 apps are not bytecode and are not interpreted, it is quite different from say Java or Smalltalk. It is more like a compile on demand system (Im simplifying for ease of explaining this of course). A program always retains its MI instruction sequence. Because of this it is possible to move a program between hardware architectures, i.e. the native instruction sequences will be generated as needed.

The best take I've seen on the pragmatic approach to C++ is Koenig and Moo's "Rumination on C++".

Both operator overloading and multiple inheritance have a place in a pragmatic C++, if they are used properly.

Koenig's concept of classes as abstract data types and using multiple inheritance for interface definition turns out to be very effective.

I totally agree with you on 1. If only c had namespaces.

2 and 3,5 are not necessary, since structs and functions play this role.

4 is part of C standard, it can change.

C is very good for kernel programming, it only needs some polishing-> namespaces and betetr type checking.