An Introduction To And History of Darwin

proclus writes "Roberto Donhert of Aqua icon theme fame (screenshot) has written a concise review of Darwin OS. The article covers the origin and evolution of Darwin OS, as well as the various Darwin distributions that are available for PowerPC and x86 architectures. OSnews has the story. The only thing that I would add is the contributions of Torrey Lyons of XonX, who created the XDarwin Xserver that made so much of this possible. BTW, Roberto also has a commentary about the SCO situation running at OSnews."

Comments

Here's a condensed history of Darwin...

[andrewski]

We had this thing called Openstep for Mach, and we kind of like updated the Openstep API and called it Cocoa. Then, it was already like 1999 and we thought 'Jeez, we'd better put a newer UNIX than 4.3 BSD on there, so FreeBSD was there and we used it. But we used like version 3.0 of FreeBSD, so we had to kind of port what we could of FreeBSD 4.5 to Darwin, and next year we'll probably have FreeBSD 4.8 under the hood. Anyway, the documentation is a mess!

Love,
Steve Jobs

Re:Here's a condensed history of Darwin...

[commodoresloat]

... Like, when we finally got OS X working, we used it to write a paper, but it was, like, 2002, and everybody was like "BEEPBEEPBEEPBEEPBEEP, I wanna listen to techno!", so we, like, reinvented the walkman and the jukebox in one fell swoop, then brought the music industry into the twenty-first century almost as an afterthought, but people still think we're dying! And it was a really good paper. Oh well, guess I'll just go fly my plane.

omg

[ceejayoz]

Good God... a Geocities link, on the Slashdot front page?

Hell, it was probably Slashdotted by the editor looking at it to approve the submission!

Re:omg

[Anonymous Coward]

...it was probably Slashdotted by the editor looking at it ...

You must be new here.

GNU-Darwin supports PPC

[proclus]

It is important to note that GNU-Darwin maintains and supports nearly 10,000 packages for Mac OS X users, in addition to our 8000 for Intel and AMD based computers. We are going to be on these platforms for the duration. Here are the links.

http://www.gnu-darwin.org/packages.shtml
http://www.gnu-darwin.org/x86.shtml

I've written an article which clarifies the relationship of GNU-Darwin to Apple.

http://www.kuro5hin.org/story/2003/1/20/191655/929

Yves de Champlain has also written a very helpful article explaining Apple's relationship to open source and free software.

http://www.osxfaq.com/Editorial/open/index.ws

Regards,
proclus
http://www.gnu-darwin.org/

Re:GNU-Darwin supports PPC

[Graff]

To quote your own words in this press release :

First, we are making explicit and binding the following policy. GNU-Darwin will not support or distribute any software which links to proprietary libraries, and that includes Cocoa, Carbon, CoreAudio, etc. There will be no native package manager from GNU-Darwin (pkg_add suffices).

Second, we will be moving our operations to x86, and we are putting the ppc collection into maintenance mode

This certainly sounds like you have turned your back on ppc. You have put your ppc collection it into "maintenance mode", this obviously means that you are treating it differently then the x86 versions. Just what is your definition of "maintenance mode"? If you are continuing your support of ppc then why make such negative statements?

Honestly proclus, you have proven yourself to be just another troll on the various Macintosh forums. You come on these types of forums decrying doom and gloom upon all things Macintosh because of Apples so-called crimes of making proprietary code. You spam the forums with messages of inane questions that you answer yourself, pumping your post count up. You make all sorts of threats of taking your repackaged toys away from the ppc and then you turn right around and claim that your support is still 100% for the platform.

There are a lot of people who are sick of this. We don't need your utilities, we have plenty from Fink or DarwinPorts. If you want to play your social activist game, go play it somewhere else because it is just falling on deaf ears here.

Re:GNU-Darwin supports PPC

[proclus]

We are eager to hear constructive criticism about the Distribution, but it is wrong to spread falsehoods. There is nothing mystical or religious about that, is there?

It is a falsehood to say that GNU-Darwin doesn't support PPC, and our enemies have used this spectacular lie to undermine our credibility. One might speculate about their motives, but no one can deny that it is wrong and immoral. It is sad that so many people have been taken in by the deception.

more Yves

[proclus]

Actually, Yves wrote a whole series, which is quite excellent. Here are the links.

http://www.osxfaq.com/Editorial/open/
http://www.osxfaq.com/Editorial/open/index2.ws
http://www.osxfaq.com/Editorial/open/index3.ws
http://www.osxfaq.com/Editorial/open/index4.ws

Regards,
proclus
http://www.gnu-darwin.org/

Re:more Yves

[Zork the Almighty]

Here's a few more links :

The history of :
hereand
here

And introduction to
here

Glad I could be of help.

What I really want..

[dadragon]

What I really want is documentation on how to do Darwin system calls from assembly on the PowerPC.

I know that you fill certain registers and then use the "sc" call, but which registers do what?

Re:What I really want..

[ZigMonty]

I haven't done this in a while but, IIRC, you put the number of the syscall you want to make in r0 and the arguments in r3 and up (like a normal function call). The result is put into r3.

Now, if the system call succeeds, control is returned to the instruction *after* the next instruction (ie. it skips one). If the syscall fails, the instruction is not skipped.

Hmm... that's not very clear. Here's an example:

li r0, [syscall_num]
li r3, [arg1]
li r4, [arg2]
[etc...]
sc
b ERROR
[code for if the syscall succeeds]
b END
ERROR:
[code for if the syscall fails]
END:

If the call succeeds, the branch to ERROR is not executed. To find the syscall number you need, have a look at /usr/include/sys/syscall.h.

Re:What I really want..

[dadragon]

There are a bunch at IBM's technical library, and also Motorola's tech library. The Linux ABI is well documented, as are the other BSDs, but not Darwin.

Here is one, "PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors"
Here is one that is PowerPC Linux specific.

Re:What I really want..

[bsartist]

The Mach-O (Darwin) ABI is documented in this PDF. Or, have a look at libffi for a working example - it's part of GCC 3, and supports Darwin.

Common Mistake

[dhovis]

Roberto made one common mistake in his writeup on Darwin. Darwin does not use a pure Mach kernel. It uses a kernel called xnu. Xnu is a hybrid kernel containing Mach message passing code, but also a lot of BSD stuff. Xnu isn't quite monolithic, but it isn't a microkernel either. The BSD stuff was added into the kernel space to improve performance over pure Mach.

Re:Common Mistake

[mrseigen]

It can't stand for "Xnu's Not Unix"... Darwin is based off of a chunk of the BSD tree, right?

What, then, could it stand for?

Re:Common Mistake

[dhovis]

I believe that Apple's long discarded "Copland" next generation OS had a kernel that was called NuKernel. Some of that code was probably merged into the OS X kernel, hence xnu. Remember that Apple used to sell Macs with NuBus expasion slots.

I swear to Jesus that I am not trolling.

[Elwood P Dowd]

Whether or not I get modded down, I implore the gnu-darwin folks to give me a listen:

What is the advantage to gnu-darwin over FreeBSD or GNU/Linux? No, really, what's the advantage? If it's IOKit & Mach that give you a hardon, then what's the advantage of gnu-darwin over GNU/Hurd?

I understand and identify with the desire for a free operating system, so I understand why y'all don't like Open Darwin 'n' the APSL. So... what's the draw?

Re:I swear to Jesus that I am not trolling.

[proclus]

Many people are interested in the technical advantages of Darwin, which is certainly part of the equation. I thought that GNU-Darwin would be an exciting way to do my work.

http://www.apple.com/scitech/stories/cornell/

We are also about the freedom part, which is why we are so excited to bring software freedom to Apple users. That is why we make sure that our software works with OS X, and we help newbies with it.

Finally, there are problems with the APSL from a free software perspective. If you already have a free OS, and you are happy with that, then you should stick with it.

Regards,
proclus
http://www.gnu-darwin.org/

Re:I swear to Jesus that I am not trolling.

[bursch-X]

The advantage over HURD ist that it's actually working, I guess.

Re:I swear to Jesus that I am not trolling.

[Sentry21]

What is the advantage to gnu-darwin over FreeBSD

You can run the same OS (theoretically) on x86 and PPC? It's a nicer system (opinion)? FreeBSD sucks (opinion)? The FreeBSD 'help' is usually more abusive than helpful (experience)?

or GNU/Linux?

Linux has all kinds of problems (every time I try to compile Linux, it gets about 30 seconds into make bzImage and errors out). Don't want to be associated with Linux zealots? Linux can be a pain to run on PPC? You can run the same (command-line) apps on GNU-Darwin as on OS X?

If it's IOKit & Mach that give you a hardon, then what's the advantage of gnu-darwin over GNU/Hurd?

Darwin doesn't use Mach? Darwin's actually usable at this point? Darwin has drivers for hardware supported by OS X? Darwin works on PPC (does Hurd)?

Hack value?

Just some ideas. Personally, I'd use Open Darwin, but there's always reasons. The question people should be asking isn't 'Why?' but rather 'Why not?'

--Dan

Re:I swear to Jesus that I am not trolling.

[PygmySurfer]

GNU-Darwin just happens to be the best-selling UNIX on the market today mostly because of the Mac OS X GUI layer running on top of it.

Actually, that'd be Darwin, not GNU-Darwin.

Re:I swear to Jesus that I am not trolling.

[Ranger Rick]

GNU-Darwin just happens to be the best-selling UNIX on the market today mostly because of the Mac OS X GUI layer running on top of it.

No matter how much the GNU-Darwin people want you to think otherwise, Apple (more specifically OpenDarwin and people in the BSD group at Apple) are the ones doing all the work on Darwin.

It's amazing Shantonu even bothers making the OpenDarwin distribution anymore when the GNU-Darwin folks immediately start reselling it at a $15 premium (check the timestamps on those e-mails...).

Re:no, thank you

[proclus]

Wouldn't you like some of this fruit. There are some fine apples, very smart. ;-}

Regards,
proclus
http://www.gnu-darwin.org/

Ugh

[Anonymous Coward]

Um......here are the mistakes just on the first page (not including the odd description of microkernel modules):

The differences between a Microkernel ... and a Monolithic Kernel ... is that a Monolithic Kernel is a large chunk of code, where a Microkernel consists of small message passing cores or Modules, with several different Daemons...

The difference between a microkernel and a monolithic kernel is that a microkernel has offloaded most system services to outside the protected boundary.

The Open Step Develpment Environment ...
History, Mach, BSD, OpenSTEP ...

It's ONE word. Capitalized as "OpenStep" or as "OPENSTEP", the former being the standard (the latter being NeXT's later marketspeak).

[OpenStep] is a true object oriented programming environment developed by Avie Tevanian and others at CMU.

Avie Tevanian worked on Mach at CMU. It is an operating system kernel. OpenStep was developed much later by developers at NeXT. Had nothing to do with CMU. It is a development library built on top of Objective-C and Display PostScript, and ran on top of several operating systems (Solaris, NT, Mach/BSD). I do not think that Avie worked on OpenStep significantly while he was a NeXT, but I'm not sure.

Re:Ugh

[Mneme]

But wait, there are more errors

• In Mach, device drivers are IOKits ( Input-Output kits).

  No. In Darwin there is an Embedded-C++ framework called IOKit for writing device drivers. It doesn't come from Mach (Mach is written in C), it is a masterpiece of design that was written from scatch at Apple, inspired by DriverKit, which was an Objective-C framework with the same intent. (Yes, NeXT put Objective-C in the kernel. At the time, they were running on PC hardware and needed a way to write drivers that minimized developer time.)

• The differences between a Microkernel, like what is used in Mac OS X and Darwin, and a Monolithic Kernel ... a Microkernel consists of small message passing cores or Modules, with several different Daemons or "servers" that communicate between the modules

  No. Darwin does not use Mach as a microkernel, and neither did NeXT's kernel. Mach is used in Darwin because it provides an excellent core for the OS with a clean API. But given the way it shares its address space with the BSD layer and IOKit, you cannot call the Darwin kernel a Microkernel. Yes, Mach makes it easy to have a chunk of a device driver out in user space, and Apple encourages developers to do this when they can, but some Linux device drivers do that, too.

In my opinion, IOKit is what makes Darwin special. The way it uses inheritance and its concepts of drivers having different interrelationships on different `planes' (e.g., power, USB topology, code dependencies, etc.) make it easier to write drivers and support things like dynamic device attachment and power management that Linux still struggles with.

Re:Ugh

[DJSpray]

As a developer writing IOKit drivers for MacOS X, I have to respectfully disagree with calling the Embedded C++ framework a "masterpiece of design." I'll grant it this: it works. But it doesn't support expedient coding, porting, or good modern C++ practice.

The limited dialect of C++ has been a major hassle, and the embedded C++ standard seems to be completely arbitrary. There are a lot of consequences for the C++ developer trying to write good code in the kernel. This is all allegedly done for the sake of a lower footprint and efficiency, but I just plain don't believe this arguments. I will believe that supporting these C++ features, especially as GCC has gone through revisions, would cause binary ABI compability thrashing... but that's a problem to be solved by the kernel developers. Solving it by turning C++ back (mostly) into C is not helpful.

Here's what "EC++" means to me:

- no exceptions: means that you can't have non-trivial constructors. So you're expected to use macros to generate a default constructor for your class, which initializes the base class reference count and what-not.

- no non-trivial constructors: means that you can't properly use constructor chaining and set up const members.

- not being able to set up const members means that your class can't be initialized containing reference objects.

- instead of using constructors the way Bjarne intended, there's a paradigm of using init() methods and explicitly calling the superclass init(), checking for errors everywhere.

- for memory management, I have to explicitly manage reference-counting in certain circumstances. This is because copy-construction and assignment operators can't be implemented properly in order to create a true smart-pointer class.

- the CF (CoreFoundation) container classes won't work in the kernel. To work around this, there is a simplified version of these containers available, where we have OSArray and OSNumber and what-not instead of CFArray and CFNumber. In certain circumstances, such as when working with the registry, voodoo magic results in user-space CF container objects being magically transmogrified into OS container objects. The design of both frameworks is biased towards the Objective-C runtime and not very "C++" ish.

- One feature that would have been of great utility in the kernel, where loadable modules fit into a single environment: namespaces! Instead, we're expected to preface the names of classes with com_mycompany_myproduct... uglifying everything in sight. This can be eased a little using macros, but then we've got... macros. What was the rationale that the EC++ consortium used for banning namespaces?

"The typical target CPU for the Embedded C++ specifications does not have much memory. Therefore, the size of application programs cannot be very large. Under such conditions, names seldom, if ever, come into conflict.." but the kernel is not a typical embedded application; it is precisely a place where many drivers from many different vendors will be prone to name collision.

Actually, Apple's documentation is silent on the subject of namespaces (as it is silent on many subjects). The compiler accepts them, but using them results in problems when using the macros for defining our default constructors...

- RTTI. No dynamic cast; instead we use another... wait for it... macro. With "fake" RTTI in the OSObject base class taking the place of a standard language mechanism.

Now, templates, streams, and STL, I'm actually in favor of keeping out of the kernel. (Although the standard string class, and perhaps istringstream would be nice, if it could be implemented without STL and templates). So I don't want to see all of C++ banned. Forbidding exceptions arguably makes some sense, but the consequences in this implementation cascade into a lot of pain.

Modern C++ practice calls for declaring const things const, using references instead of pointers where practical, and maintaining an allocation-is-initialization style. Embedded C++ bans "mutable," bans RTTI, forces explicit initialization, screws up const members and the use of reference members, and basically results in banning much of the modern C++ world that helps make code more robust. I don't think this is progress!