AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

TDosCommand - Problem mit diversen Befehlen

Ein Thema von Culxxaw · begonnen am 20. Jun 2011 · letzter Beitrag vom 24. Jun 2011
Antwort Antwort
Seite 2 von 2     12   
Satty67

Registriert seit: 24. Feb 2007
Ort: Baden
1.566 Beiträge
 
Delphi 2007 Professional
 
#11

AW: TDosCommand - Problem mit diversen Befehlen

  Alt 21. Jun 2011, 09:07
Ok, es ist die Version ohne 2009 im Archivnamen, die dann angepasst und neuer ist (Hatte zuerst die von Jaenicke runtergeladen, die identisch zur Version auf der HP ist). Da steht dann allerdings einiges an Änderungen drin.

Gut, sorry nochmal für's halbe OT... aber wer das Problem des TS nachvollziehen will, sollte ja auch die gleiche Version benutzen.
  Mit Zitat antworten Zitat
Benutzerbild von sirius
sirius

Registriert seit: 3. Jan 2007
Ort: Dresden
3.443 Beiträge
 
Delphi 7 Enterprise
 
#12

AW: TDosCommand - Problem mit diversen Befehlen

  Alt 22. Jun 2011, 20:34
Hallo,

kann es sein, dass FTP einige Ausgaben auf der ErrorConsole als ErrorMessage ausgibt und diese vonTDosCommand nicht erfasst wird.

Grüße
Klaus
TDosCommand erfasst die Erroroutputs und behandelt sie so als würden sie ganz normal auf der Console erscheinen.



Vielleicht sollte man die Frage anders stellen. Ist es überhaupt möglich mit TDosCommand interaktive Befehle (Programme) auszuführen und deren Ausgabe auszuwerten?
Die Frage ist nicht, was kann TDosCommand für dich tun, sondern was kannst du für TDosCommand tun ?
Na zumindest so ähnlich, siehe hier:
Zitat:
Hinweis: Untergeordnete Prozesse, die C-Laufzeitfunktionen wie "printf()" und "fprintf()" verwenden, funktionieren möglicherweise nicht richtig, wenn sie umgeleitet werden [wie in TDosCommand]. Die C-Laufzeitfunktionen haben separate E/A-Puffer. Bei der Umleitung werden diese Puffer möglicherweise nicht unmittelbar nach jedem E/A-Aufruf geleert. Folglich wird die Ausgabe zur Umleitungspipe eines printf()-Aufrufs oder die Eingabe eines getch()-Aufrufs nicht unmittelbar geleert und verzögert sich somit, manchmal ins Unendliche. Dieses Problem kann vermieden werden, wenn der untergeordnete Prozess die E/A-Puffer nach jedem Aufruf einer C-Laufzeit-E/A-Funktion leert. Nur der untergeordnete Prozess kann seine C-Laufzeit-E/A-Puffer löschen. Ein Prozess kann seine C-Laufzeit-E/A-Puffer durch Aufruf der Funktion "fflush()" löschen.
Also versuche mal den Puffer zu flashen in deinem kleinen Consolenprogramm (ändert natürlich nix am Verhalten von ftp).
Ich habe schon damals einiges versucht um diese Sachen zu bekommen. Die Pipes sagen einfach nix und tun so als würde auch nix passieren. Auch andere Sachen (MSDN-Library durchsuchenSetConsoleMode) in diese Richtung funktionieren nicht. Wenn jemand eine Lösung parat hat oder weiß, dass es bei anderen Programmen geht (und mir Quellcode, egal in welcher Sprache liefert), baue ich das sofort ein.

Ich habe sowieso letztens noch ein paar Erweiterungen in TDosCommand geschrieben, die ich brauchte (Umgebungsvariablen und CurrentDirectory setzen; ein kleines MemLeak ausmertzen und dann dachte ich noch so an dies und das, achja und Unicode - wobei ich letzteres nicht selber brauche und auch nicht testen kann und nur hoffe, dass es wie widestring/char reagiert).

Achso, und wenn du willst, dass dein Consolenprogramm den output gleich an den Elternprozess ()Also TDosCommand) weitergibt musst du die Funktion "flush(output)" nach jeder Textausgabe aufrufen. Delphi speichert die Ausgabe intern in einem Buffer. WriteFile ruft Delphi ersta uf, wenn die Funktion flush aufgerufen wird, oder wenn mehr als (bei mir:siehe system.TTextRec.Buffer) 128 Bytes ausgegeben wurden. Ist also etwas Delphieigenes (wie von microsoft oben beschrieben).
Dieser Beitrag ist für Jugendliche unter 18 Jahren nicht geeignet.

Geändert von sirius (23. Jun 2011 um 12:31 Uhr)
  Mit Zitat antworten Zitat
Culxxaw

Registriert seit: 21. Okt 2008
40 Beiträge
 
#13

AW: TDosCommand - Problem mit diversen Befehlen

  Alt 24. Jun 2011, 13:54
Hallo sirius,

erstmal vielen Dank für deine ausführliche Antwort. Das hilft mir schonmal ein Stückchen weiter.

Ich habe schon damals einiges versucht um diese Sachen zu bekommen. Die Pipes sagen einfach nix und tun so als würde auch nix passieren. Auch andere Sachen (MSDN-Library durchsuchenSetConsoleMode) in diese Richtung funktionieren nicht. Wenn jemand eine Lösung parat hat oder weiß, dass es bei anderen Programmen geht (und mir Quellcode, egal in welcher Sprache liefert), baue ich das sofort ein.
Also perfekt klappten tut es bei dem "Console"-Projekt (wahrscheinlich kennst du das ja auch). Das nutzt allerdings soweit ich weiß Hooks und ist in C++ geschrieben. Habe mir den Quelltext mal angeschaut, blicke jedoch überhaupt nicht durch bzw. finde die Stelle(n) nicht wo es ans Eingemachte geht. Bei der neuesten Version ist auch eine Dll namens "ConsoleHook" im Ordner enthalten. Wenn es dafür jetzt noch eine Doku gäbe wäre das natürlich super

[ADD]
Im Projektordner der Version 2 Beta ist ein Ordner namens ConsoleHook, in dem sich vermutlich alles notwendige befindet. Nun ist nur noch die Frage, ob und wie sich das nach Delphi übersetzen lässt.

Geändert von Culxxaw (24. Jun 2011 um 14:03 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von sirius
sirius

Registriert seit: 3. Jan 2007
Ort: Dresden
3.443 Beiträge
 
Delphi 7 Enterprise
 
#14

AW: TDosCommand - Problem mit diversen Befehlen

  Alt 24. Jun 2011, 17:38
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:
  1. 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
  2. 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)
  3. starte mit CreateRemoteThread einen Thread in dem anderen Prozess mit deinem eingeschleusten Code.
  4. 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.
Dieser Beitrag ist für Jugendliche unter 18 Jahren nicht geeignet.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:19 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz