OSDev.org

Hi!
What do you think about writing OS in D language ? Please comment what do you think about it, what are advantages and disadvantages.

Regards,
Mark

One obvious disadvantage is that it is unusual.

You need to be very familiar with the language and toolchain and need to be proficient enough to read design documents and examples, and convert those to D. You will also find a smaller base of people able to help you if you get stuck.

Other than that, I'm afraid I don't know enough about D to give you any more advice

Cheers,
Adam

D is a pretty good language for OSDeving as it's both pretty high level and produces native bytecode. It actually was intended for system programming. I don't know much about it either but you will find everything you need on its official webpage (clicky).

Hmm... I thought there is very small number people which can help I don't know D very well too. So I will stay with C++ in osdev. Thanks guys

Regards,
Mark

I was able to get an operating system in D to boot and display a hello world.

If i remember correctly, I used the dmd compiler (the flags were just general ones to make sure no stdlib) to compile each .d file to a .o and followed the same build process as any old c/c++ operating system.

However, I got stuck once I tried to use any structures. It appeared the dmd depends on a runtime for structures, but I couldn't find the dependencies. ( I got lazy )

Here is a microkernel in d. The source code can be an useful tool.

EDIT:
BTW, if anyone was able to figure out how to get structures/arrays to work, I'd like to hear how to do it, since D is my language of choice.

I have been contemplating using D in the past, but decided against is due to unfamiliarity and the D garbage collection, which can be turned off, but that's a hassle. It does have some nice features though.


JAL

neonek,

D is a systems language, so it works very well as a language for a kernel. Well, obviously the static subset of the language. I am one of the lead developers of an exokernel written in D. We use Linux as a development environment, and therefore gdc. Have a look at our repository. I think in src/kernel/core/dstubs.d you will find the stubbed out runtime.

• Pros:
• It is a modern systems language that your kernel will be able to then support natively
• Powerful code generation with "mixins" (see /src/kernel/arch/x86_64/idt.d)
• Strong, yet simple, meta-programming over C++ (It is similar to a functional language) (see /src/kernel/core/util.d)
• Supports inline assembly and naked keyword (portability is a concern, however)
• Allows usage of the C ABI for functions through 'extern(C)'
• The above also means you can link to C functions and assembly routines
• Guaranteed type lengths for integers. (ubyte = 1 byte .. ulong = 8 bytes)
• C-like (easy to learn)
• No *.h files!

• Cons:
• Not likely to find much D code available.
• Not likely to find many people with knowledge of the language.
• The compiler has a couple of annoying cosmetic bugs.
• Building a cross compiler has some difficulty (especially for 64-bit builds)
• Two competing runtimes to port: tango and phobos
• D 2.0 is not backwards compatible with version 1.0 of the language

If you choose to work with D, our team and myself will be fairly happy to help you.

NReed wrote: BTW, if anyone was able to figure out how to get structures/arrays to work, I'd like to hear how to do it, since D is my language of choice.

Hmm, they work fairly well for us. You are correct, it is probably a runtime thing and how you stubbed. We don't use the dmd compiler, but gdc uses the same codebase (unfortunately). I'm at a loss. Have a look at our repo, specifically the runtime in dstubs.d. Dust off your code and get that OS up and running! No excuses!

--
Wilkie

Wilkie wrote:No excuses!

What the...

Great Wilkie. Thanks for link. I see I must learn more D lang before i'll start os development in this language. And what are that bugs in compiler ? Anyway thanks.

PS What is bad with header files ?

EDIT: Maybe, Wilkie you'll add some info about basic setup in D to wiki ?

neonek wrote:PS What is bad with header files?

You have to keep them in-sync with your implementation files, and a change in a single header can result in having to recompile basically the whole project. Those are the disadvantages I can think of right away.

I always felt the biggest advantage of them being that they nicely define the "public interface" of your code, without the actual implementation getting in the way. With Java, for example, you need Javadoc or a good IDE to do for you what a C/C++ header can tell you in the same lame text editor you use for coding.

Solar wrote:I always felt the biggest advantage of them being that they nicely define the "public interface" of your code, without the actual implementation getting in the way.

Luckily, the language developer agrees, so you can have both if you need it. Here is the description. Basically, you have have these D Interface files that act much like header files would. Yet, they are generated by the compiler from the source, so you don't need to maintain them separately. It is a compiler feature, so it may not be in all compiler implementations.

neonek wrote:And what are that bugs in compiler ?

There are some issues with the templating, but they aren't a big deal. I forget exactly, but it doesn't like to iterate through a list of strings at compile time or something. You can make it a tuple instead, and its just an extra operation. (ran into this in /src/user/syscall.d)

D has an import syntax for including code modules. It breaks when you have circular imports with a depth of 2 or more. There is an annoying workaround. (ran into this EVERYWHERE)

And the errors that it reports are complete nonsense at times. (it's all in good fun)

neonek wrote:Maybe, Wilkie you'll add some info about basic setup in D to wiki ?

Certainly seems possible. I did not have much involvement with that aspect, but I'll ask around. We have been pushing documentation as of lately, and one of the visions of the project is to provide an academic outlet, and thus provide as much information about the particulars of implementation. This is definitely one facet of the development we had forgot to document. I'll throw it on the task queue

Wilkie wrote:Luckily, the language developer agrees, so you can have both if you need it. Here is the description. Basically, you have have these D Interface files that act much like header files would. Yet, they are generated by the compiler from the source, so you don't need to maintain them separately. It is a compiler feature, so it may not be in all compiler implementations.

Is this something akin to Pascal?

I've seen something like that (automatic header generation from source) done for C++, too: A nice little Perl script that was actually quite fun to use, because it also took care that your headers didn't include anything they didn't really require. (Many C++ coders never got the idea of forward declarations.) Too bad it was company property...

Wilkie, mind if I wikify some of the stuff you said? We don't have anything about the D language on our wiki...

The linker script is some kind of troubles too.