Thread overview
uefi-d: Booting to D
Feb 09, 2016
Jakub Szewczyk
Feb 10, 2016
ZombineDev
Feb 10, 2016
Satoshi
February 09, 2016
I have started developing a hobbyist OS, I decided I want it to be written in D, but the only possibility to write code that can be ran by the UEFI chips that replaced BIOS in modern computers was to use either assembler or C. (For example: http://wiki.osdev.org/UEFI or http://wiki.osdev.org/UEFI_Bare_Bones) That's why I'm working on creating a D binding for the UEFI specifications (official SDK is at http://www.tianocore.org/), right now the project is in the stage, where it can be used for real applications, but only the most important headers have corresponding modules, I'm gradually porting more and more parts of the SDK to D.
I have included a sample, working, hello world application with a build script that works on x86-64-bit linux in the project. I don't have the time and resources to extensively test the correctness of these bindings, so if anyone else is interested in UEFI programming, I'm willing to cooperate :-).

Github link: https://github.com/kubasz/uefi-d

Code.dlang.org project: http://code.dlang.org/packages/uefi-d

Proof of this working on real hardware: https://raw.githubusercontent.com/kubasz/uefi-d/ded021fe036eccdf2ae377bc75df057e76c90198/sample/photo.jpg

Useful wiki with a good documentation of the API: http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.0
February 10, 2016
On Tuesday, 9 February 2016 at 20:15:03 UTC, Jakub Szewczyk wrote:
> I have started developing a hobbyist OS, I decided I want it to be written in D, but the only possibility to write code that can be ran by the UEFI chips that replaced BIOS in modern computers was to use either assembler or C. (For example: http://wiki.osdev.org/UEFI or http://wiki.osdev.org/UEFI_Bare_Bones) That's why I'm working on creating a D binding for the UEFI specifications (official SDK is at http://www.tianocore.org/), right now the project is in the stage, where it can be used for real applications, but only the most important headers have corresponding modules, I'm gradually porting more and more parts of the SDK to D.
> I have included a sample, working, hello world application with a build script that works on x86-64-bit linux in the project. I don't have the time and resources to extensively test the correctness of these bindings, so if anyone else is interested in UEFI programming, I'm willing to cooperate :-).
>
> Github link: https://github.com/kubasz/uefi-d
>
> Code.dlang.org project: http://code.dlang.org/packages/uefi-d
>
> Proof of this working on real hardware: https://raw.githubusercontent.com/kubasz/uefi-d/ded021fe036eccdf2ae377bc75df057e76c90198/sample/photo.jpg
>
> Useful wiki with a good documentation of the API: http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.0

Nice work!
February 10, 2016
On Tuesday, 9 February 2016 at 20:15:03 UTC, Jakub Szewczyk wrote:
> I have started developing a hobbyist OS, I decided I want it to be written in D, but the only possibility to write code that can be ran by the UEFI chips that replaced BIOS in modern computers was to use either assembler or C. (For example: http://wiki.osdev.org/UEFI or http://wiki.osdev.org/UEFI_Bare_Bones) That's why I'm working on creating a D binding for the UEFI specifications (official SDK is at http://www.tianocore.org/), right now the project is in the stage, where it can be used for real applications, but only the most important headers have corresponding modules, I'm gradually porting more and more parts of the SDK to D.
> I have included a sample, working, hello world application with a build script that works on x86-64-bit linux in the project. I don't have the time and resources to extensively test the correctness of these bindings, so if anyone else is interested in UEFI programming, I'm willing to cooperate :-).
>
> [...]


Nice! I think I'll use it in my OS.

BTW: Using D for OS development is a little tricky without GC. I wish there should be implemented ARC as a replacement for GC in situations where cannot be used GC, like OSdev or SWdev for low level hardware.