Member Avatar for Mushy-pea

Hello again. Allow me to describe my opinion on software design:

C and C++ should be abandoned (or substancially modified) as the default languages used for the writing of native executables and operating systems. The reason? Giving the programmer arbitrary control over pointers is un-necessary and leads to many bugs. What should be written in C/C++ is native compilers (or interpreters) for other languages that don't allow arbitrary pointer control (i.e. Python, Perl etc.).

Don't get me wrong, C/C++ has many good points. But I think that in most cases pointer control should be left to the compiler to deal with, leaving the programmer free to deal with what the program actually does (i.e. manipulate variables). I think future operating systems should use a no kernel approach where all processes run in the same memory space. This has already been done to an early development stage with Unununium (http://unununium.org). If arbitrary pointer control is not possible in the default language, protected mode addressing is not necessary and will come to be seen as inefficient and cumbersome.

What are your thoughts on this issue?

Steven.

  • 3 Contributors
  • 3 Replies
  • 90 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by Rashakil Fol

Dani AI

Generated

A concise, practical synthesis of the discussion: , and touch on two separate engineering goals that pull in opposite directions—reducing memory-safety bugs, and keeping reliable, performant hardware access and isolation. Modern systems engineering tries to reconcile both, rather than simply discarding low-level control.

Memory-safe systems languages (notably Rust) give compile-time guarantees that eliminate whole classes of memory errors while still allowing low-level, zero-cost abstractions; this makes it realistic to move large amounts of OS code out of unsafe languages without losing performance. See Rust language for design and tooling. At the same time, hardware-enforced isolation and careful privilege separation remain necessary for security and resource control; formally verified small kernels show how to keep the trusted base tiny and auditable—see the seL4 microkernel.

If the goal is a safer native OS without large runtime overheads, a pragmatic architecture is recommended: keep a minimal, well-audited kernel (or reuse a verified microkernel), implement drivers and services in memory-safe languages, and use ahead-of-time/native compilation so programs start quickly. Real projects to study include Redox OS and Theseus OS, and platform experiments like Fuchsia demonstrate hybrid approaches. For managed-language stacks where startup is a concern, AOT/native-image tooling (for example, GraalVM) can mitigate runtime costs.

Takeaway: pointer-safety is a huge win but not a complete substitute for isolation, correct device handling, and a small trusted kernel. Combining memory-safe languages, minimal/verified kernel design, and native/AOT compilation addresses the main trade-offs raised in the thread and is the most practical route for anyone wanting to build a modern, safer OS.

Recommended Answers

All 3 Replies

Member Avatar for Ancient Dragon

>>C and C++ should be abandoned
you don't have to use C/C++ if you don't want to, but don't expect everybody else to do so. Writing windows GUI programs is just a small part of the software design/programming efforts. And in some operating systems C and assembly language are the only two available programming languages. We can't just toss out a computer language just because some one doesn't like it.

>>I think future operating systems should use a no kernel approach where all processes run in the same memory space

That has already been tried -- see MS-DOS. A kernel is an absolutely essential part of any operating system, if there is no kernel then nothing will run and the kernel needs to be protected from corruption by other programs.

>>If arbitrary pointer control is not possible in the default language, protected mode addressing is not necessary

That is not true. There are a lot of other things that can cause a system to crash; pointers is only one of them.

Member Avatar for Mushy-pea

>>If arbitrary pointer control is not possible in the default language, protected mode addressing is not necessary

That is not true. There are a lot of other things that can cause a system to crash; pointers is only one of them.

Well, it seems I need to get my facts straight.

A kernel is an absolutely essential part of any operating system, if there is no kernel then nothing will run and the kernel needs to be protected from corruption by other programs.

I will gather my countering evidence and return :) .

Steven.

Member Avatar for Rashakil Fol

C and C++ should be abandoned (or substancially modified) as the default languages used for the writing of native executables and operating systems.

The Linspire team has already abandoned C and C++ and use Haskell as their preferred language for core OS development. That doesn't mean the kernel shouldn't be in C, though -- it's small enough (assuming it is) and important enough that it can be paid close attention to.

The reason? Giving the programmer arbitrary control over pointers is un-necessary and leads to many bugs. What should be written in C/C++ is native compilers (or interpreters) for other languages that don't allow arbitrary pointer control (i.e. Python, Perl etc.). Don't get me wrong, C/C++ has many good points. But I think that in most cases pointer control should be left to the compiler to deal with, leaving the programmer free to deal with what the program actually does (i.e. manipulate variables).

Programs don't manipulate variables; they interact with the kernel and with hardware. Some programming languages don't let you modify variables.

And C and C++ are terrible languages for writing native compilers (or for anything).

I think future operating systems should use a no kernel approach where all processes run in the same memory space. This has already been done to an early development stage with Unununium (http://unununium.org). If arbitrary pointer control is not possible in the default language, protected mode addressing is not necessary and will come to be seen as inefficient and cumbersome.

You'd have to compile every program before you run it. And what's going to do that? Programs would start up (insanely) slowly.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.