Can i use D for OS develop.

[Brad Roberts]

On Thu, 16 Aug 2007, Sean Kelly wrote:

> kris wrote:
> > knott wrote:
> > > Paul Collier Wrote:
> > > 
> > > > knott wrote:
> > > > > Hello. Before i start, i must apologize for my poor English.
> > > > > 
> > > > > Can i use D language for OS development(Non-core - user mode devel)?
> > > > If you're talking about OS development, there are at least two projects
> > > > to write a kernel in D. You can see them at dsource.org. If you're
> > > > talking userspace development, I think you'll find that 95% of D
> > > > projects already run in userspace ;) If you're talking about something
> > > > in the middle, you can always bind D code to C APIs and disable the
> > > > garbage collector if needed.
> > > 
> > > Im talking about a userspace development in system which in early stage of
> > > development.
> > > I want to write program on system which have only small(not full) C
> > > library.
> > 
> > Tango would rather not have the full C lib either. It rather deliberately
> > uses only a handful of clib calls, and a (small) replacement for those has
> > been on the cards for years. We just never got the time to do that.
> > 
> > We'd be very interested in a lightweight replacement for those few clib
> > calls, written in D
> 
> For what it's worth, the only standard C lib call of note used by the Tango
> runtime is malloc/free.  A few others are used for convenience (memset,
> memmove), but could easily be removed.
> 
> By the way, the Tango runtime is designed in a way to makes replacing the
> "standard library" portion quite easy, which may be of interest to you if
> you're thinking about writing your own.  I'll be discussing the design at the
> D conference next week.
> 
> 
> Sean

There's others, file apis, socket apis, time apis, etc.. the list is quite 
a bit longer than you might think.

I really don't understand the desire to move off of libc.  libc provides a 
number of very useful benefits:

  -- no need to understand the kernel call semantics for every os
  -- no need to figure out how to conform to posix (and other standards) 
     for each kernel/os.
  -- no need to re-optimize for each cpu interesting low level bits like
     how to move memory the fastest
  -- good malloc subsystems are _hard_ to write (definition of good is 
     obvious debatable)

There's a big downside.. it's impossible in D to restrict usage of parts 
of a library.. anyone can provide their own extern(C) blah and poke past 
the abstractions that Tango and Phobos are trying to provide.

Later,
Brad