Why the overhead of keep opening the (a) thread and closing its
handle ?!!
Weil WaitForDebugEventEx an diesen Stellen bloß die ThreadID liefert.
Ich finde es auch nicht wirklich schön, aber erstmal ist dieser Teil dort bloß zum Test drin
und dann abeitet hier alles noch sehr linear, ohne dass vieles zwischengespeichert wird.
* SuperMiniDebugger.dproj zum Test der Grundfunktionen
* und später im MiniDebugger.dproj dann inkl. erweitertem Handling
Ja, im Prinzip könnte man sich hier z.B. im CREATE_THREAD_DEBUG_EVENT das
Handle klonen (DebugEvent.CreateThread.hThread) und bis zum EXIT_THREAD_DEBUG_EVENT aufheben.
Bzw. hier ist erstmal absichtlich noch nicht viel drin, um Dinge über längere Zeit zu behalten.
Primär wirklich erstmal nur die jeweiligen Events/Behandlungen für sich.
Daher kennen und logen die END-Events von
DLL, Thread und Prozess auch keine Namen. (sie bekommen nur die ID, bzw. Adresse aus dem END-EventRecord)