kernel VS carbon-lang

You might find the source code for FreeDOS of interest for learning more about how the low-level access to the interrupt services worked. Specifically, console.asm installs a character write routine (which calls BIOS INT 10h under the hood).

Looking at https://github.com/FDOS/kernel/blob/master/boot/boot.asm, I see %define statements for this type of information, but I'm not sure how these memory locations are normally populated with proper values. Is this something that Sys does when preparing the CF card? Or should the BIOS populate this information when loading the boot loader?

That's where I'm coming from. FreeDOS still gets occasional commits once per few months but is not really developed anymore. Watcom C still seems like it's actively developed, but it's not clear what they are trying to achieve if they are not even interested in what's happening in C/C++ world!

Here's the code for the kernel https://github.com/FDOS/kernel/ You will have to entirely rewrite the Assembly code since it is x86 assembly (Netwide Assembler is great, but not for ARM). Namely boot code is assembly. The kernel does compile under multiple compilers. I'm not too sure if ARM platforms handle this, but I would look at the Linux kernel for boot code on ARM.

"DOS" is a little bit of a general term. Microsoft's product, MS-DOS, is not Free Software. But there are other implementations, including FreeDOS, which is compatible with MS-DOS.

Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that

>A key subset of safety categories Carbon should address are:

>[...]

>Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing

But then later in the doc it says

>It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers:

>Don't offer safety guarantees for data races, eliminating RefCell.

>[...]

>Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...]

One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but still we still currently aim for a model that will prevent them."

[0] https://github.com/carbon-language/carbon-lang/blob/trunk/do...

It's even a core point for Carbon, their hopeful C++ replacement

Under language goals on their readme,

> We also have explicit non-goals for Carbon, notably including:

> * A stable application binary interface (ABI) for the entire language and library

> * Perfect backwards or forwards compatibility

There's also this blurb

> Our goals are focused on migration from one version of Carbon to the next rather than compatibility between them. This is rooted in our experience with evolving software over time more generally and a live-at-head model. Any transition, whether based on backward compatibility or a migration plan, will require some manual intervention despite our best efforts, due to Hyrum's Law, and so we should acknowledge that upgrades require active migrations.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027.

I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options.

[0] - https://github.com/carbon-language/carbon-lang/blob/trunk/do...

Carbon was started by Chandler Carruth, at Google, but they wanted to move it to broader governance quickly. It's not under the Google GitHub today, but its own org.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

What do you think about Carbon[1]? I am hopeful.

[1] https://github.com/carbon-language/carbon-lang

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

next year 0.1 will be usable, 1.0 is about 3 years away, sigh, back to my rust fight