Is C a good OS-Developing language?

[SDS]

You need a perspective on this. RDOS was designed at the time when 286-processors were common, and the 386 processor was brand new (at least on the market). It was 1988. There were no toolchains at all that supported the 386-processor, and no affordable compilers that produced code for 386. GCC was not invented. Bochs was not invented. Linux was not invented. There was an assembler (MASM) that produced 32-bit code. RDOS was designed based on these premises, and because there existed no open "reference" systems, rather only the Intel processor docs, the OS design-decisions were never burdened with toolchain peculiarities. The tools needed were instead developped, like a way to "link" device-drivers, a way to build an image file and a useful memory model for an assembly-only project.

I take no issue with the historical development of RDOS. Indeed, even the continuity of such a project over 23 years is quite an achievement!

That said, the state of compilers, emulators etc. in 1988 is somewhat irrelevant in the context of the suitability of the C programming language, compilers and associated toolchain to OS or device driver development today. Whether you intend to or not, most of your statements are written in the present rather than the past tense (although I accept that the word could in the sentence I quoted could be read as "could have been", rather than as a current conditional).

[rdos]

What I mostly argue for is that a ready-to-use toolchain might not be the most effective way to learn OS development. IMO, it is best to first learn assembly and low-level programing, and once this is mastered it would be a good idea learn how a C/C++ toolchain works, its requirements, and how it integrates with assembly. That way we will see fewer "Linux"-clones with the standard features of UNIX-systems, and more creative solutions. After all, the design ideas behind UNIX predates RDOS by a large margin.

Few people that use special options of GCC (like nostartup), or special options of compilers (like "interrupt" keyword), actually know what these do and why. For me, at least, answers to such questions are central. I don't want to know which options I can give to a compiler / linker in order for it to produce an OS, I want to know how the code works. I want to have it in the reverse direction. I want my compiler to produce code for a compact memory model. I also want the compiler to always assume that DS is loaded with DGROUP. Through the compiler manual I know I can use -ms and -zdp options for this, and that this would produce the desired behavior. When I setup-calls I know I need to load DS on entry, and save segment registers. Looking through the compiler's documentation I see there is no #pragma that achieves this, so I create it by modifying the compiler.

[Casm]

That way we will see fewer "Linux"-clones with the standard features of UNIX-systems, and more creative solutions. After all, the design ideas behind UNIX predates RDOS by a large margin.

One thing I would agree with is that there was one too many versions of Unix in 1969. There is not much point in writing Unix clones forever (even if that does mean there is a paucity of ready to run apps on your new OS).

[Chandra]

You need a perspective on this. RDOS was designed at the time when 286-processors were common, and the 386 processor was brand new (at least on the market). It was 1988.

You really have a great continuation to the project. I appreciate that. But the question is, how well have you been able to catch up with the modern hardware? Was rdos designed keeping the upcoming innovations in mind?