C# für Systemprogrammierung: Tief einsteigen ohne Schmerz

C# für Systemprogrammierung: Wenn hohe Ebene auf niedrige Hardware trifft

Wenn man den Begriff „Systemprogrammierung“ hört, tauchen im Kopf meist Bilder von bärtigen Gurus auf, die in C oder Assembler programmieren, mit Terminals voller grünem Text. Und C# – das ist doch „für Geschäftsanwendungen“, „für Windows Forms“ und „für die, die sich nicht mit Zeigern herumschlagen wollen“. Spoiler: Das ist ein Mythos.

Tatsächlich ist C# ein Schweizer Taschenmesser für den Systemprogrammierer, der schnell und sicher schreiben möchte, aber bei Bedarf auch ins heiße Herz des nicht verwalteten Speichers vordringen kann. In diesem Artikel schauen wir uns an, wie C# bei der Lösung realer Systemaufgaben hilft: von der Arbeit mit Prozessen bis zum direkten Speicherzugriff über WinAPI. Und ja, Codebeispiele wird es geben – ohne geht es nicht.

Warum C# nicht nur ein „Business-Spielzeug“ ist?

Systemprogrammierung mit C# ist kein Oxymoron. Die .NET-Plattform (insbesondere .NET 5+) bietet dem Entwickler eine einzigartige Kombination: Leistung nahe an nativem Code und den Komfort einer Hochsprache. Sie können Treiber schreiben, mit Prozessen arbeiten, Speicher manuell zuweisen und dabei nicht den Verstand durch Ressourcenverwaltung verlieren.

Die wichtigsten Funktionen, die C# für die Systemprogrammierung geeignet machen:

\n
• Unsafe-Code und Zeiger – ja, in C# kann man direkt mit Adressen arbeiten, wie in C++.
\n
• P/Invoke – Aufruf beliebiger Funktionen aus nativen Bibliotheken (WinAPI, libc, Treiber).
\n
• Span und Memory – sichere Arbeit mit zusammenhängenden Speicherblöcken ohne unnötige Allokationen.
\n
• Native AOT – Kompilierung in nativen Code ohne JIT und CLR.
\n
• Interop mit C/C++ – Einbettung von C# in bestehende Systemprojekte.
\n

Wenn Sie dachten, C# sei nur für Web und Datenbanken, machen Sie sich auf Überraschungen gefasst.

Unsafe-Code: Spiel mit dem Feuer, aber unter Kontrolle

Das Schlüsselwort unsafe in C# ist wie der rote Knopf einer Atomrakete. Gedrückt – und Sie können alles tun: Zeiger dereferenzieren, mit fixierten Objekten arbeiten, Stack-Speicher zuweisen. Aber die Verantwortung ist absolut.

Angenommen, wir müssen ein Byte-Array schnell kopieren und dabei die Grenzprüfungen umgehen. In sicherem Code würden wir Array.Copy verwenden, aber wenn wir ein Systemtool für die Arbeit mit einem Treiber schreiben, zählt jede Mikrosekunde.

using System;\n\nunsafe class MemoryCopy\n{\n    public static void FastCopy(byte[] source, byte[] dest, int length)\n    {\n        fixed (byte* pSrc = source, pDst = dest)\n        {\n            byte* ps = pSrc;\n            byte* pd = pDst;\n            for (int i = 0; i < length; i++)\n                *pd++ = *ps++;\n        }\n    }\n}

Hier verwenden wir fixed, um die verwalteten Arrays im Speicher zu „fixieren“, damit der Garbage Collector sie während des Kopiervorgangs nicht verschiebt. Das Ergebnis ist eine Kopiergeschwindigkeit nahe der von memcpy in C. Für alltägliche Aufgaben ist das natürlich übertrieben, aber für die Systemprogrammierung mit C# ist es ein Must-have.

Wann ist unsafe gerechtfertigt?

\n
• Arbeit mit Netzwerkpaketen auf Rohbyte-Ebene.
\n
• Interaktion mit Hardware über DMA.
\n
• Implementierung eigener Speicherallokatoren.
\n
• Optimierung kritischer Codeabschnitte (z. B. Videoverarbeitung von Kameras).
\n

P/Invoke und WinAPI: C# klopft an den Kernel

Echte Systemprogrammierung ist ohne den Aufruf nativer Funktionen nicht möglich. C# bietet dafür den Mechanismus P/Invoke (Platform Invocation Services). Möchten Sie eine Liste der Prozesse abrufen, Fenster verwalten oder den Speicher eines anderen Prozesses lesen? Bitte sehr.

Betrachten wir ein klassisches Beispiel – das Abrufen der Liste laufender Prozesse über die WinAPI-Funktion CreateToolhelp32Snapshot.

using System;\nu