C# pour la programmation système : un démarrage en douceur sans douleur

C# pour la programmation système : quand le haut niveau rencontre le bas niveau matériel

Quand on entend l'expression « programmation système », on imagine généralement des gourous barbus écrivant en C ou en assembleur, avec des terminaux remplis de texte vert. Et C# — c'est plutôt « pour les applications métier », « sous Windows Forms » et « pour ceux qui ne veulent pas se prendre la tête avec les pointeurs ». Spoiler : c'est un mythe.

En réalité, C# est un couteau suisse pour le programmeur système qui veut écrire rapidement, en toute sécurité, mais qui, si nécessaire, peut plonger en plein cœur de la mémoire non managée. Dans cet article, nous allons voir comment C# aide à résoudre de véritables tâches système : de la gestion des processus à l'accès direct à la mémoire via WinAPI. Et oui, des exemples de code seront fournis — on ne peut pas s'en passer.

Pourquoi C# n'est pas qu'un « jouet pour les affaires » ?

La programmation système en C# n'est pas un oxymore. La plateforme .NET (en particulier .NET 5+) offre au développeur une combinaison unique : des performances proches du code natif et la commodité d'un langage de haut niveau. Vous pouvez écrire des pilotes, travailler avec des processus, allouer de la mémoire manuellement sans perdre la tête avec la gestion des ressources.

Les fonctionnalités clés qui rendent C# adapté à la programmation système :

\n
• Code unsafe et pointeurs — oui, en C# on peut travailler directement avec les adresses, comme en C++.
\n
• P/Invoke — appel de n'importe quelle fonction depuis des bibliothèques natives (WinAPI, libc, pilotes).
\n
• Span et Memory — travail sécurisé avec des blocs de mémoire contigus sans allocations inutiles.
\n
• Native AOT — compilation en code natif sans JIT ni CLR.
\n
• Interop avec C/C++ — intégration de C# dans des projets système existants.
\n

Si vous pensiez que C# était réservé au web et aux bases de données, préparez-vous à être surpris.

Code unsafe : jouer avec le feu, mais sous contrôle

Le mot-clé unsafe en C# est comme un bouton rouge sur une ogive nucléaire. Vous appuyez, et vous pouvez tout faire : déréférencer des pointeurs, travailler avec des objets fixes, allouer de la mémoire sur la pile. Mais la responsabilité est absolue.

Supposons que nous devions copier rapidement un tableau d'octets, en contournant les vérifications de limites. En code sécurisé, nous utiliserions Array.Copy, mais si nous écrivons un utilitaire système pour interagir avec un pilote, chaque microseconde compte.

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}

Ici, nous utilisons fixed pour « épingler » les tableaux managés en mémoire, afin que le ramasse-miettes ne les déplace pas pendant la copie. Le résultat est une copie à une vitesse proche de memcpy en C. Bien sûr, pour les tâches quotidiennes, c'est excessif, mais pour la programmation système en C#, c'est un must-have.

Quand unsafe est-il justifié ?

\n
• Travail avec des paquets réseau au niveau des octets bruts.
\n
• Interaction avec le matériel via DMA.
\n
• Implémentation d'allocateurs mémoire personnalisés.
\n
• Optimisation de sections critiques de code (par exemple, traitement vidéo depuis une caméra).
\n

P/Invoke et WinAPI : C# frappe à la porte du noyau

La véritable programmation système est impossible sans appeler des fonctions natives. C# fournit pour cela le mécanisme P/Invoke (Platform Invocation Services). Vous voulez obtenir la liste des processus, gérer les fenêtres ou lire la mémoire d'un autre processus ? Pas de problème.

Prenons un exemple classique — l'obtention de la liste des processus en cours via la fonction WinAPI CreateToolhelp32Snapshot.

using System;\nu