Certains correctifs attendent longtemps leur heure. Un premier support des objets Job a été fusionné dans le code de ReactOS le samedi 22 août 2026, via la demande de fusion 7500, alors que le travail d'origine sur cette fonctionnalité remonte à près de dix ans. Les objets Job sont la primitive du noyau Windows qui permet de gérer un groupe de processus comme une seule unité, ce sur quoi les navigateurs bâtissent leurs bacs à sable et les services appliquent leurs limites de ressources. L'implémentation vise le comportement antérieur à Windows 8 et laisse certaines fonctions non implémentées, mais le support de base fonctionne désormais.
The short answer
ReactOS a fusionné un premier support des objets Job, la primitive du noyau Windows qui gère des groupes de processus comme une seule unité pour les limites de ressources, la terminaison collective et les restrictions de sécurité. Les navigateurs en dépendent pour leur bac à sable, et divers services et démons l'utilisent pour leurs propres limites. L'implémentation vise les fonctions antérieures à Windows 8 et en laisse certaines de côté, mais le support de base fonctionne, à partir d'un code qui remonte à près de dix ans.
Réimplémenter un système d'exploitation est un travail essentiellement invisible, et les parties les plus longues sont rarement celles que l'on remarque. En voici un bon exemple : une primitive de noyau sans interface, sans comportement visible, et dont dépend directement à peu près toute application Windows sérieuse.
Ce que fait un objet Job
Le noyau Windows traite un job comme un conteneur de processus. Vous en créez un, vous y affectez des processus, et à partir de là c'est le job que vous manipulez.
Trois capacités en découlent. Les limites de ressources s'appliquent au groupe entier, si bien qu'un plafond mémoire couvre tout le contenu du job d'un bloc au lieu d'être appliqué séparément à chaque processus. La terminaison collective signifie que fermer le job met fin à tous ses processus d'un coup, ce qui supprime le problème classique du parent qui meurt en laissant des enfants orphelins en cours d'exécution. Les restrictions de sécurité peuvent viser l'ensemble plutôt qu'un processus à la fois.
Si vous venez de Linux, les cgroups sont le point de comparaison le plus proche, et la ressemblance est assez réelle pour servir d'intuition tout en étant fausse dans le détail. Les deux existent parce que gérer les processus un par un ne tient pas face à la façon dont les applications modernes sont réellement construites.
Pourquoi les applications refusent de démarrer sans
Si ce sujet relève de la compatibilité plutôt que du confort, c'est que les logiciels Windows modernes ne considèrent pas les objets Job comme facultatifs.
Les navigateurs web en sont le cas le plus clair. Un navigateur multi processus place ses processus de rendu dans des jobs pour que du contenu de page non fiable s'exécute dans quelque chose que le navigateur peut contraindre et démonter d'un bloc. Ce n'est pas une optimisation de performance, c'est le bac à sable lui même. Un navigateur incapable de créer un job est un navigateur dont le modèle d'isolation a silencieusement échoué, ce qui est pire qu'un navigateur qui refuse de se lancer.
Au delà des navigateurs, divers services et démons utilisent les jobs pour appliquer leurs propres limites de ressources. Le motif est assez répandu pour qu'un système dépourvu de cette primitive heurte le mur à répétition, dans des applications différentes, pour la même raison de fond.
Voilà pourquoi cette fusion mérite d'être rapportée alors que rien de visible ne change pour l'utilisateur. Ce type de travail de compatibilité n'améliore pas les logiciels qui fonctionnent déjà. Il raccourcit la liste de ceux qui ne peuvent pas fonctionner du tout.
Support initial, et ce que ce qualificatif signifie
Le cadrage honnête est celui qu'emploie le projet lui même. Il s'agit d'un support initial : le code vise les fonctions antérieures à Windows 8 et certaines fonctionnalités ne sont pas encore implémentées.
Ce qualificatif mérite qu'on s'y arrête plutôt que de le survoler. Les fonctions de job ajoutées à partir de Windows 8, dont les jobs imbriqués et des types de limites plus riches, sont précisément celles que les logiciels contemporains attendent, puisqu'une application est écrite contre ce que la plateforme du moment propose. Couvrir le niveau ancien établit la primitive et fait fonctionner les cas de base. Cela ne termine pas le travail.
L'attente correcte n'est donc pas qu'un navigateur moderne tourne désormais sous ReactOS. C'est qu'un manque structurel a été comblé et que le travail au dessus peut commencer.
La décennie
Le détail qui donne sa forme à cette histoire, c'est que le code d'origine des objets Job pour ReactOS remonte à près de dix ans avant sa fusion.
Il est tentant d'y lire un projet qui avance lentement, et cela vaut la peine d'y résister. Les objets Job se tiennent au croisement de la création de processus, de leur terminaison et de la sécurité, c'est à dire la région d'un noyau où les erreurs sont les moins visibles et les plus coûteuses. Une implémentation subtilement fausse n'échoue pas bruyamment : elle produit un comportement qui diverge de Windows d'une manière qui apparaît beaucoup plus tard, dans des logiciels sans rapport, sous forme de bogues que personne ne sait remonter.
Fusionner un tel code demande un relecteur qui maîtrise ces trois domaines et dispose du temps de parcourir toute la série. Dans un projet bénévole, ce relecteur est le goulet d'étranglement, pas le code. Dix ans dans la file, c'est à quoi ressemble la rareté de la relecture approfondie, et c'est la même contrainte qui façonne l'avancement de tout le projet.
Où cela se situe sur la route vers NT6
Les objets Job sont une pièce de l'effort plus large vers la compatibilité Windows NT6, la frontière entre exécuter des logiciels de l'ère Windows XP et exécuter quoi que ce soit de contemporain. Les jalons récents sur ce chemin comprennent l'arrivée du premier appel système NT6 et Half-Life 2 fonctionnant sous le système.
Ces deux là relèvent du progrès visible, celui qui produit une capture d'écran. Les objets Job relèvent de l'autre catégorie, et ils sont la raison pour laquelle les premiers finissent par devenir possibles.
Pour comparaison, l'autre grand projet libre de ce domaine prend l'approche inverse : Wine, qui a ajouté le décodage vidéo VA-API en version 11.16, réimplémente l'interface de programmation de Windows par dessus un noyau existant. ReactOS réimplémente le noyau lui même, ce qui explique qu'il hérite de problèmes comme celui ci et pas Wine.
Personne ne devrait basculer sur ReactOS au vu de cette seule fusion, et le projet reste une réimplémentation de long terme plutôt qu'un système d'usage quotidien. Mais la liste des raisons pour lesquelles un logiciel Windows moderne ne peut pas y démarrer compte un élément de moins que la semaine dernière, et cette liste est la seule mesure qui compte vraiment.
Sources et pour aller plus loin
- ReactOS Merges Support For Job Objects As Step To Running Modern Windows Apps, Phoronix, 23 août 2026
- ReactOS Adds First NT6 Syscall NtGetCurrentProcessorNumberEx, Windows Forum
- ReactOS Starts 2026 With Another Major Step Toward Windows NT6 Compatibility, LXer
Questions fréquentes
Qu'est ce qu'un objet Job dans le noyau Windows ?
C'est une primitive du noyau qui permet de gérer et de contrôler un groupe de processus comme une seule unité. Vous créez un job, vous y affectez des processus, puis vous agissez sur le job plutôt que de courir après des identifiants de processus individuels. Trois usages dominent. Les limites de ressources, où un plafond de mémoire ou de processeur s'applique à l'ensemble du job d'un bloc plutôt qu'à chaque processus séparément. La terminaison collective, où fermer le job tue d'un coup tous les processus qu'il contient sans laisser d'orphelins. Et les restrictions de sécurité, où un ensemble de processus est contraint en tant que groupe. Le concept le plus proche sous Linux est le cgroup, même si l'analogie est approximative et les mécanismes différents.
Pourquoi est ce important pour exécuter des applications Windows modernes ?
Parce que les applications modernes supposent que cela existe. Les navigateurs web sont le cas le plus net : un navigateur multi processus place ses processus de rendu dans des jobs pour qu'un onglet compromis ou planté soit confiné et puisse être démonté proprement, ce qui constitue l'ossature du modèle de bac à sable. Divers services et démons s'appuient aussi sur les jobs pour appliquer leurs propres limites. Sur un système d'exploitation dépourvu d'objets Job, une application qui s'attend à en créer un échoue franchement ou perd silencieusement son isolation, et aucune de ces deux issues n'est acceptable pour un logiciel que vous voulez réellement utiliser.
Est ce complet ? ReactOS peut il faire tourner un navigateur moderne ?
Non dans les deux cas. Le code fusionné vise les fonctions antérieures à Windows 8 et laisse certaines fonctionnalités non implémentées : il s'agit donc d'un support initial et non d'un sous système achevé. Cette distinction compte, car les fonctions de job plus récentes sont précisément celles que les versions ultérieures de Windows ont ajoutées pour les jobs imbriqués et des limites plus riches, ce que les logiciels modernes présupposent de plus en plus. Ce que la fusion apporte, c'est un support de base fonctionnel et l'existence même de la primitive, condition préalable au reste. Voyez y des fondations posées, pas un jalon de compatibilité atteint.
Pourquoi un code écrit il y a près de dix ans ne fusionne t il que maintenant ?
Cet écart est normal pour un travail bénévole de réimplémentation d'un noyau, et il en dit plus sur la capacité de relecture que sur le code. Les objets Job touchent à la création de processus, à leur terminaison et à la sécurité, trois des zones les plus sensibles d'un noyau, et une implémentation subtilement fausse produit des bogues qui surgissent loin de leur cause. Fusionner demande un relecteur profondément familier de l'ensemble et disposant du temps nécessaire pour parcourir la série, ce qui est la ressource la plus rare dans un projet de système d'exploitation libre. Que le code d'origine existe depuis des années relève moins de la négligence que de la file d'attente.
Comment cela s'inscrit il dans la feuille de route de ReactOS ?
C'est un élément d'un effort plus large vers la compatibilité Windows NT6, la ligne qui sépare l'exécution de logiciels de l'ère Windows XP et Server 2003 de celle de logiciels contemporains. Les avancées récentes sur ce chemin incluent l'arrivée du premier appel système NT6 et Half-Life 2 fonctionnant sous le système. Les objets Job relèvent du même effort, côté noyau plutôt que côté interface de programmation. Aucun de ces éléments ne fait à lui seul de ReactOS un système d'usage quotidien, et le projet reste une réimplémentation de long terme. Chacun supprime en revanche une raison précise pour laquelle une application refuse de démarrer.