Ich bin eben auch gerade über etwas im Bereich
Windows PowerShell gestolpert, auf den ersten Blick schien da auch etwas Job genannt zu werden, was eventuell jetzt nicht das ist, was in der Windows-
API eigentlich als Job bezeichnet wird. Ich habe allerdings nicht genau hingesehen und finde die Seite auf die Schnelle nicht mehr ...
MSDN erklärt es letztendlich doch sehr gut:
Auf
About Processes and Threads steht:
A job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on the job object affect all processes associated with the job object.
Auf der Seite
Job Objects steht eine gute Zusammenfassung, was man damit typischerweise anstellen kann.
Mein ursprüngliches Problem war exakt das, wie es bei StackOverflow schon einmal aufgetaucht ist: Starte ich meine Delphi-Anwendung von der
cmd.exe aus (oder z.B.
start.exe), steckt die Anwendung in keinem Job.
So kann ich einen neuen Job mit den wildesten Eigenschaften erstellen und mich selbst dann dort hineinpacken!
Starte ich mein Programm normal im Explorer per Doppelklick auf die Exe oder Verknüpfung, stecke ich bereits in einem Job. Das kann man einfach direkt mittels
IsProcessInJob herausfinden. Lustigerweise kann man mittels
QueryInformationJobObject zwar Informationen über den Job, in welchem man auf alle Zeit gefangen ist auslesen, sie aber nicht modifizieren: Man kennt weder den Namen noch das
Handle des Jobs. Das ist so gewollt und wahrscheinlich auch gut so.
Trotzdem hindert mich jetzt immer noch keiner daran, einen neuen Job zu erstellen und mittels dem
dwCreationFlags
-Parameter bei
CreateProcess
noch ein
CREATE_BREAKAWAY_FROM_JOB
(0x1000000) anzugeben, denn ein mit CreateProcess erstellter Job landet sonst normalerweise im selben Job wie sein Parent-Prozess.
PS: Den Großteil der nötigen Funktions-Deklarationen und Konstanten für Delphi liefert schwa226 netterweise schon
hier