Can i use D for OS develop.

[kris]

Brad Roberts wrote:
> 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

Perhaps not a question of moving "off" libc? An option to link with 
something simpler, or written in D, or whatever?

As for malloc(), many libs appear to use a derivative of Doug Lea's 
venerable incarnation :)