Das Projekt kannte ich jetzt nicht (oder vielleicht doch, ...weis nicht).
Dieses schleust Code in den anderen Prozess rein. Ich würde es als hacken bezeichnen. Sowas ist zwar schön, wenn man es privat macht, aber ich würde ein Programm, welches auf derartige Tricks zurückgreift, nicht verkaufen wollen.
Deswegen hat sowas im ursprünglichen TDosCommand nichts zu suchen.
Aber ich kann mal sehen, ob ich eine Art TDosCommandEx baue. Das Prinzip in dem Projekt ist mir durchaus bewusst, und ich könnte es auch schreiben (am besten sogar ohne zusätzliche
DLL).
Nur einwas ist merkwürdig....siehe weiter unten
Das ganze geht etwa folgendermaßen:
- Du baust dir ein paar Routinen zusammen, die die Console mit WriteConsoleBuffer und ReadConsoleBuffer beeinflussen, mit Waitforsingleobject kannst du auf den output einer Console warten.
Das Problem an der Sache ist, dass diese Funktionen nur in dem Prozess funktionieren, in dem sie sich befinden. Deswegen nächster Punkt
- Du bringst diese Routinen entweder direkt als Kopie (Writeprocessmemory etc.) oder mittels DLL-Injecttion (stecke die funktionen in eine DLL und lade diese in den Zielprozess --> gibt es in der DP ein paar threads zu)
- starte mit CreateRemoteThread einen Thread in dem anderen Prozess mit deinem eingeschleusten Code.
- Soweit fertig. Jetzt musst du dir nur noch ein Benachrichtigungssystem einfallen lassen bspw. über memory mapped files und messages, oder du nimmst sockets.....
Ja, das wars dann auch. Ob das wirklich funktioniert habe ich noch nicht getestet. Auf jeden Fall könnte man auch das Problem mit der Codepage angehen.
Was mich allerdings noch wundert ist folgendes:
Wenn ich in Delphi ein ConsolenProgramm schreibe, dann hält Delphi unter bestimmten Umständen den Text zurück und schreibt ihn nicht gleich raus. Wenn die Console sichtbar ist, macht er es, wenn nicht, dann anscheinend nicht. Und das umgeht dieses Projekt irgendwie.