Announcement

**Andreas Kosch** · 10.10.2000, 07:34

Hallo,

zuerst einmal sollte der Begriff "DOS-Anwendung" n�her definiert werden. Ist damit eine Konsolenanwendung gemeint, die als 32-Bit-Programm im Fenster der Eingabeaufforderung l�uft oder soll ein altes 16-Bit-Programm gestartet werden?

Falls eine Konsolenanwendung gestartet werden soll, sollte der folgende Aufruf (Auszug aus einem Beispielprojekt aus meinem Buch Delphi Win32-L�sungen) funktionieren:
<pre>
function ExecConsoleAppAndWait(const sApp, sParams, sTitle: String;
wShow: Word): DWord;
var
aSI : TStartupInfo;
aPI : TProcessInformation;
aProc : THandle;
dwError : DWord;
begin
FillChar(aSI, SizeOf(aSI), 0);
aSI.cb := SizeOf(aSI);
// Text f�r die Fensterzeile zuweisen
aSI.lpTitle := PChar(sTitle);
aSI.wShowWindow := wShow;
if not CreateProcess(PChar(sApp), PChar(sParams), nil, nil, False,
CREATE_NEW_CONSOLE OR NORMAL_PRIORITY_CLASS,
nil, nil, aSI, aPI) then
begin
dwError := GetLastError;
raise Exception.CreateFmt('Programm kann nicht gestartet werden.' +
#10#13 + 'Fehler-Code %d',[dwError]);
end;
aProc := aPI.hProcess;
CloseHandle(aPI.hThread);
if WaitForSingleObject(aProc, Infinite) <> Wait_Failed then
GetExitCodeProcess(aProc, Result);
CloseHandle(aProc);
end;
</pre>
Auf das Ende einer normalen Win32-Anwendung kann �ber den folgenden Weg gewartet werden (auch dieses Beispiel stammt aus dem o.g. Buch), wobei dieser Weg auch unter Windows NT funktioniert:
<pre>
procedure TFormMain.Button1Click(Sender: TObject);
begin
WaitExecute('calc.exe');
end;

{
Das Programm startet eine andere Win32-Anwendung und wartet auf deren
Ende. Allerdings soll die eigene Anwendung w�hrend dieser Zeit immer
noch auf Benutzeraktionen und Windows-Botschaften reagieren. Der
Benutzer kann das Fenster verschieben, als Icon ablegen und wieder
von der Taskleiste herstellen. Dazu ist es notwendig, das die Win32-
API-Funktion MsgWaitForMultipleObjects nicht nur beim Ende des gestarteten
Prozesses zur�ckkehrt, sondern immer dann, wenn eine neue Botschaft von
Windows zugestellt wurde. Aus diesem Grund verwendet die API-Funktion
MsgWaitForMultipleObjects die Konstante QS_ALLINPUT, somit kehrt die
Funktion bei jeder neuen Botschaft zur�ck. �ber den anschliessenden
Aufruf von ProcessMessages werden die neuen Botschaften als bearbeitet
markiert, so dass sich MsgWaitForMultipleObjects wieder f�r neue
Botschaften auf Lauer legt, solange der gestartet Prozess noch l�uft.
}

procedure TFormMain.WaitExecute(sEXE: String);
var
aTSI : TStartupInfo;
aTPI : TProcessInformation;
iRet : Integer;
begin
FillChar(aTSI, SizeOf(aTSI), #0);
FillChar(aTPI, SizeOf(aTPI), #0);
aTSI.CB := SizeOf(aTSI);
if not CreateProcess(nil, PChar(sEXE), nil, nil, False,
NORMAL_PRIORITY_CLASS,
nil, nil, aTSI, aTPI) then
RaiseLastWin32Error;
StatusBar1.SimpleText := 'Externer Prozess ist aktiv.';
repeat
iRet := MsgWaitForMultipleObjects(1, aTPI.hProcess, False, INFINITE, (QS_ALLINPUT));
if iRet <> (WAIT_OBJECT_0) then
begin
// aktustische R�ckmeldung zur Demonstration
MessageBeep($FFFFFFFF);
Application.ProcessMessages;
end;
until iRet = (WAIT_OBJECT_0);
CloseHandle(aTPI.hProcess);
StatusBar1.SimpleText := 'Externer Prozess wurde beendet.';
end;
</pre>

**Michael Knauer** · 10.10.2000, 09:22

Vielen Danke erstmal f�r die schnelle Antwort. 
 
Ich habe die Antwort noch nicht probiert, werde es aber gleich tun. 
 
Prinzipiell ben�tige ich den 3 Aufrufe externer Programme um �ltere index-sequentielle Daten einer Dos-Application so umzustellen, das sie in eine neue index-sequentielle Struktur umgewandelt werden k�nnen, die dann unter den neuen Windows-Programmen verwendet werden k�nnen. 
 
Dabei werden folgende Prozesse ben�tigt: 
1. Aufruf eines 16-Bit-Programmes zum Neuaufbau der Satz-Indexe 
2. Aufruf einer 32-Bit-Konsolenanwendung die die Daten konvertiert und eine Batch-Datei erzeugt die den parameterisierten Programmaufruf enth�lt um die Satz-Indexe der Windows-Datei aufzubauen. 
3. Aufruf der erzeugten Batch-Prozedur zum Aufbau der Satz-Indexe (Diese Batchroutine enth�lt auch wieder den Aufruf einer 32-Bit-Konsolenanwendung mit Parameter-Angaben) 
 
Da jeder Prozess neue Dateien erzeugt, muss bei jedem Process das Ende abgewartet werden, bevor der n�chste gestartet wird! 
 
Prinzipiell stellt sich mir noch die Frage, ob das 2. Beispiel (WaitExecute) auch f�r den Aufruf des Kommando-Prozessors verwendet werden kann (Command.Com unter Win95/98 bzw. CMD.EXE unter WinNT) da
ich diesen mit Parameter "/C" f�r die Ausf�hrung des CreateProcess verwende. 
Das 2. Beispiel w�rde mir prinzipiell mehr zusagen, da es auch die Botschaftsbehandlung der Application nicht unterbricht (Fenster verschieben, als Icon ablegen, etc.) 
 
Ein weiteres Problem, das mir gestern bei Tests unter Windows98 auffiel war das bei Ausf�hrung des 3. Schritts unter Umst�nden der Neuaufbau der Indexe fehlschlug, was zu einer Meldung auf der DOS-Eingabeaufforderung f�hrte und der Tatsache das sich das Fenster nicht automatisch beendete. 
Die Meldung kam aber nicht aus der Dos-Anwendung sondern mu� von Command.Com ausgel�st worden sein. 
Eventuell da der Fehler innerhalb einer Batch-Routine erzeugt wurde ?<br&gt

**Michael Knauer** · 10.10.2000, 16:50

Hallo Hr. Kosch, 
 
Der von ihnen vorgegebene L�sungsvorschlag funktioniert unter Windows NT leider nicht. 
W�hrend unter Win95/98 die Ausf�hrung mit WaitforSingleObject bzw. WaitforMultipleObjects ohne weiteres m�glich ist, reagiert das Programm unter Windows NT 4.0 nicht darauf. 
Die Konkrete Schwerpunkt des Problems scheint zu sein, den Prozess-Handle der von CreateProcess erzeugt wird mit dem Wert SYNCHRONIZE (0x100000L) zu initialisieren, was mir bisher weder �ber die TStartupInfo-Variable noch �ber die TProcessInformation-Variable gelungen ist. 
Dadurch wird jeder Prozess beinahe gleichzeitig angestartet, was aber zu Problemen f�hrt, da die f�r das Folgeprogramm erforderlichen Dateien erst von dem vorhergehenden Programm erzeugt werden m�ssen. 
 
Eine genaue Beschreibung der Situation und den verwendeten Quellcode habe ich ihnen per Mail zugeschickt

**Hagen Reddmann** · 11.10.2000, 02:12

Hi

CreateProcess(...,...,nil,nil,False,SYNCHRONIZE,ni l,....); 
�ndere also die dwCreationFlags. Falls das nicht hilft, gehst Du nach dem Aufruf von Createprocess() folgenderma�en vor:

<pre>

Process2 := OpenProcess(PROCESS_ALL_ACCESS or SYNCHRONIZE, False, ProcessID);
WaitForSingleObject(Process2, INFINITE);
CloseHandle(Process2);

oder versuchst:

WaitForSingleObject(ProcessInfo.hThread, INFINITE);

</pre>

Gru� Hage

**Michael Knauer** · 11.10.2000, 11:09

Hallo Hagen, 
danke f�r deine Antwort. 
Ich hatte damit aber ebenfalls leider nicht den gew�nschten Erfolg. 
 
Die Varianten (1 und 3) 
CreateProcess(...,...,nil,nil,False,SYNCHRONIZE, nil, ....); 
und 
WaitForSingleObject(ProcessInfo.hThread, INFINITE); 
lieferten beide das selbe Ergebnis, das bereits bisher auftrat, 
d.h. die Processe wurden gestartet und der Programmablauf 
sofort fortgesetzt. SYNCHRONIZE zeigte also keine Wirkung ! 
 
Die 2. Variante 
PROCESS2 := OpenProcess(PROCESS_ALL_ACCESS or SYNCHRONIZE, 
False, ProcessInfo.hProcess); 
WaitForSingleObject(Process2, INFINITE); 
CloseHandle(Process2); 
bewirkte das der Process gar nicht mehr beendet wurde und 
dadurch das Programm an dieser Stelle stehenblieb 
bzw. in eine Endlos-Schleife geriet. 
Ist es m�glich, das hierbei der Bezug zum Programm das mit 
ProcessInfo.hProcess angelegt wurde, nicht funktioniert ? 
 
Anmerken m�chte ich noch das ich die Prozedur dahingehend 
abgewandelt hatte, das ich nicht WaitForSingleObjects sondern WaitForMultipleObjects verwende, da der Aufruf in einem Formular 
stattfand und ich so Application.Messages ber�cksichtigen kann (Programmabbruch, Formularaktualisierung etc.). 
 
 
Der folgende Quelltext wurde von mir verwendet und 
hat eine Endlosschleife produziert: 
 
function DOSCreateProcess(cApplName, cApplParam, cPfad, cShellTitel: String; var iErr_Code : LongWord): Boolean; 
var 
aTSI : TStartupInfo; 
aTPI : TProcessInformation; 
hProcess2 : THandle; 
iRet : Integer; 
cDosAufruf : String; 
begin 
cDosAufruf := Trim(cSysCommandPfad + cSysCommandName + ' ' + cSysCommandParam + ' ' + cApplName +' '+cApplParam); 
FillChar(aTSI, SizeOf(aTSI), 0); 
aTSI.cb := Sizeof(aTSI); 
aTSI.lpTitle := PChar(cShellTitel); 
aTSI.wShowWindow := SW_SHOWMINNOACTIVE; // Ohne Wirkung !!! 
// (Trotz SW_SHOWMINNOACTIVE Fensteranzeige, seit ich CREATE_SEPARATE_WOW_VDM verwende !) 
if not CreateProcess(nil, 
PChar(cDosAufruf), // Befehlszeile 
nil, // Security 
nil, // Security 
False, 
CREATE_SEPARATE_WOW_VDM or 
NORMAL_PRIORITY_CLASS, // Priorit�t 
nil, // Environment 
PChar(cPfad), // Verzeichnis 
aTSI, 
aTPI) then 
begin // Process-Erzeugung nicht m�glich 
iErr_Code := GetLastError; 
result := False; 
exit; 
end else // Process-Erzeugung erfolgreich 
result := True; 
 
hProcess2 := OpenProcess(PROCESS_ALL_ACCESS OR SYNCHRONIZE, False, aTPI.hProcess); 
try 
SetConsoleTitle(PChar(cShellTitel)); 
repeat // Beginn der Endlos-Schleife 
iRet := MsgWaitForMultipleObjects(1, hProcess2, False, INFINITE,(QS_ALLINPUT)); 
if iRet <> (WAIT_OBJECT_0) then begin 
// Abbruch-Button ber�cksichtigen 
Application.ProcessMessages; 
// Abbruch durch Escape-Taste ber�cksichtigen 
if GetAsyncKeyState(VK_ESCAPE) <> 0 then bAbbruch := True; 
end; 
until iRet = (WAIT_OBJECT_0) // Ende der Endlos-Schleife 
or bAbbruch = True; 
finally 
CloseHandle(aTPI.hProcess); 
CloseHandle(hProcess2); 
end; 
end; 
&#10

**Andreas Kosch** · 11.10.2000, 13:50

Hallo,

normalerweise sollte das Flag SYNCHRONIZE zumindestens bei einer normalen GUI-Anwendung nicht angegeben werden m�ssen, da es bereits in den standard access rights (Combines DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER, and SYNCHRONIZE access) enthalten ist. Mein Beispiel mit MsgWaitForMultipleObjects wartet auch unter NT 4 auf das Ende des gestarteten Prozesses (CALC.EXE). Es muss also bei den 16-Bit-Anwendungen einen Sonderfall geben, der zumindestens in der Platform SDK-Hilfe auch als solcher gekennzeichnet wird (siehe Beschreibung zu lpApplicationName ).

Ich w�rde daher folgendes probieren: 
1. Unmittelbar nach dem Aufruf von hProcess2 := OpenProcess(PROCESS_ALL_ACCESS OR SYNCHRONIZE, False, aTPI.hProcess) zuerst den R�ckgabewert in hProcess2 pr�fen, und wenn dort 0 vorgefunden wird, den Grund daf�r mit RaiseLastWin32Error erfragen. 
2. Beim Aufruf von CreateProzess in pProcessAttributes das Flag bInheritHandle aktivieren, um die Zugriffsrechte zu vererben. 
3. Wenn das nichts hilft, muss wohl jemand von uns die Details im SDK genauer durchlesen, die sich aus CREATE_SEPARATE_WOW_VDM ergeben ;-)
&#10

**Hagen Reddmann** · 11.10.2000, 17:19

Hi

<pre>

hProcess2 := OpenProcess(PROCESS_ALL_ACCESS OR SYNCHRONIZE, False, aTPI.hProcess);

</pre>

IST falsch, aTPI.hProcess ist ein Process-Handle, OpenProcess erwartet da eine ProcessID, aTPI.dwProcessID mu� dahin. 

Also n�chstes w�rde CREATE_SEPARATE_WOW_VDM nicht verwenden sondern CREATE_SHARED_WOW_VDM, damit k�nnte es sein das NT bei 16Bit Anwendung diese auch zugreifbar sind. Sollte eine separate Virtuelle Machine gestartet werden (bei CREATE_SHARED_WOW_VDM) gibt es eine abgeshottete VDM auf deren Processe externe 32bit Processe KEINE Zugriff haben. 

Also drittes erstelle den Process (CreateProcess()) im CREATE_SUSPENDED Mode, und ruf danach ResumeThread(aTPI.hThread) auf.
SOLLTE die Anwendung STOPPEN und nach ResumeThread() LOSLEGEN, MUSST Du auch auf die Handles hThread/hProcess warten k�nnen. D.h. WaitFor..() sollte dann auf alle F�lle funktioniern.

Gru� Hage

**Hagen Reddmann** · 11.10.2000, 17:23

Hi

Vielleicht solltest Du Dir �berlegen zu der 16Bit DOS-EXE eine PIF-Datei anzulegen und diese mit CreateProcess() zu starten. 
Vorstellbar w�re dann folgendes: Createprocess() startet einen 32Bit PIF-Datei Process und dieser die 16Bit DOS-Zielanwendung. Der PIF process MUSS warten, also sollte Dein process auf PIF-Process warten.
Alternativ mal mit eine BAT-Datei probieren.

Gru� Hage

Announcement

DOS-Anwendung mit CreateProcess und WaitForSingleObject

DOS-Anwendung mit CreateProcess und WaitForSingleObject

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment