Badanie kończenia pracy programu DOS'owego

Witam,

Sprawa wygląda tak: na komputrze jest system win98 i uruchomiony program dos'owy, który robi swoje. Program pracuje w trybie graficznym. Po wykonaniu porcji zadań, a zajmuje mu to sporo czasu, czeka na następne. No, i teraz, w sumie, z mojej strony wypadałoby zamknąć program, system i pójść spać.

Tu pojawia się problem: Myślę o tym, żeby najpierw pójść spać, a te, po skończeniu roboty, niech się same pozamykają. :)
No, i teraz myślę nad programem działającym w tle, który "badałby" ten program, czyli sprawdzał moment zakończenia jego pracy i po tym zamykał go i system.

Nie miałbym problemu z programem okienkowym. Po uchwytach poskakałoby się i po sprawie, ale... tu jest dos'owiec.

No, i tu nie mam pomysła na nasłuch co w programie dos'owym piszczy.

Mógłby mi ktoś z Was podsunąć pomysł, jakąś metodę na taki programos dos'owy?

Jeżeli program skończy działanie i nie zamyka się jego proces pod postacią pliku exe, to chyba ciężko będzie wyłapać ten moment, w
ktorym już nie pracuje. Jeżeli pokazywał by jakieś charakterystyczne dane w konsoli to można by komponentem TDosCommand albo
podobnym UnitedCmd (chociaż z tego drugiego nigdy nie korzystałem, a z pierwszego tylko raz do przechywcenia postepu pakowania
ktory mi w oknie konsolowym pokazywał rar.exe) przeanalizowac, co program aktualnie pokazuje i już odpowiednio na to reagować.
Jednak nie wiem jak takie komponenty zachowają się w aplikacji dosowej i graficznym oknie. Może ktoś inny, coś jeszcze Ci doradzi.

Dzięki Olesio za wypowiedź.

Z charakterystycznych rzeczy, to:

1. przy prawidłowym kończeniu działań na ekranie pojawia się przez chwilę czerwona ramka, a w niej literki "OK" oraz w głośniczku dwa tony na przemian można usłyszeć;
2. przy nieprawidłowym kończeniu działań powyższe się nie pojawiają.

Jak na razie tyle mi się kojarzy z tych zauważonych prawidłowości.

Niestety TDosCommand sprawdza się w aplikacjach konsolwych, bo poniższy kod:

//...
uses
  doscommand;

procedure TForm1.Button1Click(Sender: TObject);
var
  DOS : TDosCommand;
begin
  DOS := TDosCommand.Create(Self);
  DOS.CommandLine := 'cmd /C C:\NC\nc.exe';
  DOS.OutputLines := Memo1.Lines;
  DOS.Execute;
end;

Zwróci w Memo tylko taki tekst, na końcu po kilku pustych liniach wstawiając jakiś znak ASCII:

Norton Commander, wersja 5.0,
Copyright (C) 1986 - 1995 Symantec Inc.

Poza tym uruchomienie starego NC, skutkuje później "zamuleniem" mojego Windows XP Home.
Także nie wiem co jeszcze mógłbyś wykombinować. Jedyne co jeszcze można sprawdzić to czy,
jeżeli to możliwe, program uruchomi się pod DosBoxem, a później proces DosBoxa sprawdzić w
poszukiwaniu zwiększającej się wartości postępu narzędziami typu GameHacker albo lepiej pod
nowszym tego typu narzędziem Cheat Engine. Następnie, jeżeli okazało by się że wartośc jest
pod stałym adresem (raczej wątpliwe, a na pewno w przypadku dosowych aplikacji), to zrobić w
Delphi program który w wątku lub timerze sprawdzal by tę wartość przez ReadProcessMemory
w procesie DosBoxa i po osiągnięciu jakiejś wartości, ubijał proces DosBoxa oraz zamykał cały
system, ale nie wiem, jak to się sprawdzi na Windows 98 i DosBoxie. Ale możesz sprobować.
A i polecam DosBoxa dlatego, bo pamięć jego, jako procesu Windowsowego łatwo analizować.

Właśnie sprawdziłem. Również UnitedCMD, zwraca do TMemo.

Popróbuje z DosBox'em coś wymyślić.

mnie ten speaker zainteresowal...
poprawcie mnie jesli sie myle, ale obstawiam ze na win98 da sie bez wiekszych problemow odczytac jego stan, nawet pod TP.
mozna sprawdzc w petli czy zostal wlaczony, jesli tak to shutdown. prowizoryczne ale moze zadzialac a w tym przypadku to chyba najwazniejsze ;]

Sprawdzaj listę procesów. DOS-owy program na pewno w jakiejś postaci się tam pojawia. Pod 9x kojarzy mi się winoldap.exe, w nowszych windowsach widać jako ntvdm.exe.
To pod warunkiem, że w danej chwili jest tylko jeden program DOS-owy uruchomiony. Jeżeli nie, musisz rozgryźć jak je rozróżnić.

@olesio:

DosBox jako pośrednik odpada. Program uruchamia się, nie wykrywa dostępu do urządzeń zewnętrznych i kończy działanie z odpowiednim komunikatem.

@komentarz Cimak do Azarien_:

Zgadza się.

@cimak:

Tak, tak, można sterować speaker'em przez tablicę PORT'ów. Teraz mi się przypomniało, że takim czymś bawiłem się na 386-tce i TP7.0 .
Poszukałem i widzę, że via D7 to się robi troszkę dookoła (http://delphi.about.com/cs/adptips2003/a/bltip0303_3.htm).
Spróbuje tego, czy daje znośny odzew.

Podobnie przymierzę się do bezpośredniego wglądu na obraz w trybie graficznym. Bodajże, jeśli dobrze pamiętam, to adres w pamięci był taki: $A000:$0000.

Jeżeli ma ktoś jeszcze jakieś pomysły, to proszę sypać. Niech żyje brainstorming. :)

A co się dzieje z wynikami obliczeń? Idą do pliku jakiegoś? Może sprawdzać okresowo zawartość tego pliku.

Poniżej przykład kodu uruchamiającego JAKIŚ program i czekający na jego zakonczenie..

 
uses ShellAPI


procedure TfmMain.prExecWOw();
var
  SEInfo: TShellExecuteInfo;
  ExitCode: DWORD;
begin
  FillChar(SEInfo, SizeOf(SEInfo), 0) ;
  SEInfo.cbSize := SizeOf(TShellExecuteInfo) ;
  with SEInfo do begin
    fMask := SEE_MASK_NOCLOSEPROCESS;
    Wnd := Application.Handle;
    lpFile := PChar("C:\jakis\program\plik.exe") ;
    nShow := SW_SHOWNORMAL;
  end;

  if ShellExecuteEx(@SEInfo) then begin
    repeat
      Application.ProcessMessages;
      GetExitCodeProcess(SEInfo.hProcess, ExitCode);
    until
      (ExitCode <> STILL_ACTIVE) or Application.Terminated;
  end;
  ShowMessage("Skonczylem");
end;

Co to za "obliczenia"..? A moze przepisac pod winde bedzie latwiej i szybciej?

Azarien_ napisał(a)

A co się dzieje z wynikami obliczeń? Idą do pliku jakiegoś? Może sprawdzać okresowo zawartość tego pliku.

Wyników obliczeń nie ma. Program nic takiego nie generuje, nie jest to jego głównym zadaniem, więc nie musi nic zapisywać do pliku. Już wspominałem o peryferiach...

Chociaż to też jest pomysł, żeby pójść w kierunku sprawdzenia czy jednak coś przypadkiem nie zapisuje/zmienia w swoich plikach. Sprawdzę to na pewno.

zajcev napisał(a)

Co to za "obliczenia"..? A moze przepisac pod winde bedzie latwiej i szybciej?

Program steruje peryferiami.