ReactOS a fusionné la PR 7500 le 22 août pour ajouter la gestion de base des Job Objects au noyau. Ces objets permettent d’agir sur des processus associés. L’implémentation vise les fonctions antérieures à Windows 8 et laisse explicitement des travaux à venir.

Ce qui a été fusionné
La pull request ReactOS couvre notamment création des jobs, association des processus, interrogation d’informations et terminaison des processus du groupe. Sa description présente ce support comme initial et incomplet. Une fusion du code ne prouve pas non plus sa présence dans chaque image téléchargeable.
La documentation Microsoft des Job Objects explique le comportement Windows réimplémenté. Un job est un objet du système associé à des processus, pas simplement un processus parent ni un répertoire d’exécutables.
Fermer un handle ne signifie pas toujours terminer
L’ancien article indiquait que fermer le job terminait tous ses processus. C’était trop général. Sous Windows, terminer explicitement le groupe et fermer un handle sont deux opérations. Le comportement kill-on-close exige JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE et la fermeture du dernier handle du job.
Dans un exemple original, le contrôleur A et le moniteur B détiennent chacun un handle sur le même job. A peut fermer le sien sans fermer celui de B. Même avec kill-on-close configuré, la référence conservée par B empêche d’atteindre cette condition du dernier handle. L’exemple illustre la sémantique Windows ; il ne prétend pas que ce scénario exact a été testé sur ReactOS.
La propriété des handles fait donc partie de la conception d’un superviseur de processus. Une référence oubliée peut modifier le nettoyage ; tuer le parent n’équivaut pas à déclencher l’opération de groupe prévue.
Appartenance et isolation demandent leurs preuves
Windows documente des règles d’association des enfants, de sortie du groupe et de jobs imbriqués. La cible antérieure à Windows 8 de la PR ne vaut pas prise en charge complète des imbrications ultérieures. Un job ne fournit pas non plus automatiquement toutes les frontières de sécurité d’un navigateur.
Un test de compatibilité utile nomme le build exact et la séquence d’API, relève les codes de retour, contrôle l’appartenance effective et observe la terminaison des processus. Lancement du navigateur, gestion des processus et isolation d’un contenu hostile sont des questions séparées. Une primitive fonctionnelle ne les résout pas toutes.
ReactOS comble une partie d’un manque de compatibilité important. Les éléments disponibles prouvent ce progrès concret du noyau, pas que les navigateurs modernes y sont désormais sûrs ou pleinement fonctionnels. PeopleAreGeek a examiné le rapport d’implémentation et la sémantique de référence, sans revendiquer un test de sandbox ReactOS.
Revue du 8 septembre : sources primaires et évolutions vérifiées, explications et illustrations reprises.