Delphi and Kylix

Moderators: pritaeas
Number of threads: 7244
Number of posts: 19051

This Forum Only
Post New Thread
Single Post View       Linear View       Threaded View      f

Report
Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 8:10 AM
Hi everyone.

I have TWO questions, if I may ask them here.

1st Question:
How do I write a simple little DOS program with Delphi 6
that will write some text on the screen, and then capture it
inside a separate Delphi app, say in a TMEMO box ?
(I'm excerising my capturing DOS contents experience)

For example,
for n := 1 to 10 do
writely(n);

And, while the DOS app is outputing the contents to IT'S
screen, MY app will also be capturing THAT screens contents
in a TMEMO box. To be exact, how do I capture the variable
'n' in my TMEMO box ?


2nd Question:
How do I "capture" the data that is being generated (outputed)
in a DOS screen (or session) into my app, in a TMEMO box ?

Please, I would love some source code samples, if I'm not being
to pesky about it.

I'm asking these quesiton, because there are a number of DOS
programs that have command-line parameters, and depending on
these parameters, the DOS session will output various types of
data to it's screen. And, they will be different at times.
I'm trying to learn how to capture this data. That is why
I'm asking the above TWO questions. With Programmers Heavin's
help, I hope to succeed.

- Delphi 6
- Windows 98

Thank you for your help.
-mydelphi
Report
Re: Writing a DOS app and Capturing DOS data Posted by zibadian on 19 Jul 2003 at 10:37 AM
: Hi everyone.
:
: I have TWO questions, if I may ask them here.
:
: 1st Question:
: How do I write a simple little DOS program with Delphi 6
: that will write some text on the screen, and then capture it
: inside a separate Delphi app, say in a TMEMO box ?
: (I'm excerising my capturing DOS contents experience)
:
: For example,
: for n := 1 to 10 do
: writely(n);
:
: And, while the DOS app is outputing the contents to IT'S
: screen, MY app will also be capturing THAT screens contents
: in a TMEMO box. To be exact, how do I capture the variable
: 'n' in my TMEMO box ?
:
:
: 2nd Question:
: How do I "capture" the data that is being generated (outputed)
: in a DOS screen (or session) into my app, in a TMEMO box ?
:
: Please, I would love some source code samples, if I'm not being
: to pesky about it.
:
: I'm asking these quesiton, because there are a number of DOS
: programs that have command-line parameters, and depending on
: these parameters, the DOS session will output various types of
: data to it's screen. And, they will be different at times.
: I'm trying to learn how to capture this data. That is why
: I'm asking the above TWO questions. With Programmers Heavin's
: help, I hope to succeed.
:
: - Delphi 6
: - Windows 98
:
: Thank you for your help.
: -mydelphi
:
First of all, you cannot write a true DOS application with D6, since it's a windows compiler. You can however write windows console applications, which are basically windows applications running in a DOS-like mode (see {$APPTYPE} directive for more info).
I don't know how to capture screen output, but if you can control the output of the program, I would suggest that you write it to a file. Then you can read that file in your windows application.
Report
Re: Writing a DOS app and Capturing DOS data Posted by Perran on 19 Jul 2003 at 11:20 AM
: Hi everyone.
:
: I have TWO questions, if I may ask them here.
:
: 1st Question:
: How do I write a simple little DOS program with Delphi 6
: that will write some text on the screen, and then capture it
: inside a separate Delphi app, say in a TMEMO box ?
: (I'm excerising my capturing DOS contents experience)
:
: For example,
: for n := 1 to 10 do
: writely(n);
:
: And, while the DOS app is outputing the contents to IT'S
: screen, MY app will also be capturing THAT screens contents
: in a TMEMO box. To be exact, how do I capture the variable
: 'n' in my TMEMO box ?
:
:
: 2nd Question:
: How do I "capture" the data that is being generated (outputed)
: in a DOS screen (or session) into my app, in a TMEMO box ?
:
: Please, I would love some source code samples, if I'm not being
: to pesky about it.
:
: I'm asking these quesiton, because there are a number of DOS
: programs that have command-line parameters, and depending on
: these parameters, the DOS session will output various types of
: data to it's screen. And, they will be different at times.
: I'm trying to learn how to capture this data. That is why
: I'm asking the above TWO questions. With Programmers Heavin's
: help, I hope to succeed.
:
: - Delphi 6
: - Windows 98
:
: Thank you for your help.
: -mydelphi
:
There might be a better way, but I wonder if you could pull it out of textmode video buffer?
Report
Re: Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 11:52 AM
@ Perran,

:: There might be a better way, but I wonder if you could pull it out of textmode video buffer?

Good one Perran !

I've ben thinking about this for months, but didn't act upon it
cause I had a bunch of other things going on and still do. But...

I remember my good old DOS days, $b800 rings a bell ??????

I use to write all kinds of screen capture (for text) and I remember
reading the screen's buffer, and doing all sorts of things with it.

I think it only boils down to a few short things:

1 - know the DOS application's window name (I don't think that's
possible when I call a DOS app from my app, even w/ parameters,
but I could be wrong)

2 - but, IF its possible to read DOS window during DOS call to app,
then, my guess is that we would simply need to activate it, or bring
this window to front/focus, and THEN read the contents via the video's
buffre ie, $b800 (I may be off with this screen address) And, if I
remember correctly, it was every 2nd char that had to be read in, be
cause one char is the COLOR char.

So, if the above IS true, then all we need are:
A - the routine to know the DOS window, and
B - to know when and where to PULL/CAPTURE/READ the DOS screen's
corrdinate.

And, in reality, is all too simple !
But, it seems that know one knows how to do this just yet, even though
this is starying them right in the face !

My memory isn't as good as it used to be, but I done this hundreds
of times, but can't remember it today, although I may have some code
laying around on a bunch of 3 1/2" diskettes from my Turbo Pascal 3.0
days.

So, if anyone has any suggestions in my next steps, I'm all ears.
Thank you.
-mydelphi



: : Hi everyone.
: :
: : I have TWO questions, if I may ask them here.
: :
: : 1st Question:
: : How do I write a simple little DOS program with Delphi 6
: : that will write some text on the screen, and then capture it
: : inside a separate Delphi app, say in a TMEMO box ?
: : (I'm excerising my capturing DOS contents experience)
: :
: : For example,
: : for n := 1 to 10 do
: : writely(n);
: :
: : And, while the DOS app is outputing the contents to IT'S
: : screen, MY app will also be capturing THAT screens contents
: : in a TMEMO box. To be exact, how do I capture the variable
: : 'n' in my TMEMO box ?
: :
: :
: : 2nd Question:
: : How do I "capture" the data that is being generated (outputed)
: : in a DOS screen (or session) into my app, in a TMEMO box ?
: :
: : Please, I would love some source code samples, if I'm not being
: : to pesky about it.
: :
: : I'm asking these quesiton, because there are a number of DOS
: : programs that have command-line parameters, and depending on
: : these parameters, the DOS session will output various types of
: : data to it's screen. And, they will be different at times.
: : I'm trying to learn how to capture this data. That is why
: : I'm asking the above TWO questions. With Programmers Heavin's
: : help, I hope to succeed.
: :
: : - Delphi 6
: : - Windows 98
: :
: : Thank you for your help.
: : -mydelphi
: :
: There might be a better way, but I wonder if you could pull it out of textmode video buffer?
:

Report
Re: Writing a DOS app and Capturing DOS data Posted by Manning on 19 Jul 2003 at 4:28 PM
: @ Perran,
:
: :: There might be a better way, but I wonder if you could pull it out of textmode video buffer?
:
: Good one Perran !
:
: I've ben thinking about this for months, but didn't act upon it
: cause I had a bunch of other things going on and still do. But...
:
: I remember my good old DOS days, $b800 rings a bell ??????

Sorry to burst the bubble, but it's not that simple

Your GUI program with the TMemo (or whatever) is going to need to create a named pipe, and then using CreateProcess() execute the DOS (or Win32 console) program redirecting its output (stdout) to the pipe. That way the text being written to stdout by the program will not go to the screen like normal, and instead will go to the pipe that your GUI program can read from.

I experimented with this about a year ago, but after learning of certain limitations I gave up and deleted my code, so I dont have any samples to give to you. But I learned how to do it through searching on Google, and through Experts Exchange (www.experts-exchange.com) so you might want to try that.

Incidentally, the limitation I found was that any program written in Pascal using the CRT unit cannot have it's output captured. Since the programs I wanted to capture the output of all fell into this category, that's why I abandoned my efforts.
Report
Re: Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 5:12 PM
@ everyone,

Thanks for all your responses. It's much appreciated.

As to the non-windows apps I'm talking about, and trying to capture
its' data, I'm refering to those apps that were actually created with
C++ but with command-line in mind.

I'm still not going to give up hope. As far as google, I've ben there
and done it, and am STILL LOL doing it. I also found a link, at
the exchange LINK you provided. I didn't quite understand the concept
that was given. I too, abandoned that one. However, I'm still looking.

Keep up with the suggestions though.
-mydelphi



: : @ Perran,
: :
: : :: There might be a better way, but I wonder if you could pull it out of textmode video buffer?
: :
: : Good one Perran !
: :
: : I've ben thinking about this for months, but didn't act upon it
: : cause I had a bunch of other things going on and still do. But...
: :
: : I remember my good old DOS days, $b800 rings a bell ??????
:
: Sorry to burst the bubble, but it's not that simple
:
: Your GUI program with the TMemo (or whatever) is going to need to create a named pipe, and then using CreateProcess() execute the DOS (or Win32 console) program redirecting its output (stdout) to the pipe. That way the text being written to stdout by the program will not go to the screen like normal, and instead will go to the pipe that your GUI program can read from.
:
: I experimented with this about a year ago, but after learning of certain limitations I gave up and deleted my code, so I dont have any samples to give to you. But I learned how to do it through searching on Google, and through Experts Exchange (www.experts-exchange.com) so you might want to try that.
:
: Incidentally, the limitation I found was that any program written in Pascal using the CRT unit cannot have it's output captured. Since the programs I wanted to capture the output of all fell into this category, that's why I abandoned my efforts.
:

Report
Re: Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 5:16 PM
Hello again.

I responded too quickly. I wasn't finished.

A good example of a command-line is Borland's BRCC32.exe app.

When you run this baby in DOS, you get all those nice param strings.
Using that as our example, if I wanted to capture that output as it
displays all those strings i.e., brcc32 -h, just how easy is it for
me to capture that output ?

To be quite honest, I'm not looking to create Delphi DOS apps. But,
I was thinking that if I were able to create them anyways, I would
create a simple DOS app like the b4cc32 example.

Thanks again.
-mydelphi



: : @ Perran,
: :
: : :: There might be a better way, but I wonder if you could pull it out of textmode video buffer?
: :
: : Good one Perran !
: :
: : I've ben thinking about this for months, but didn't act upon it
: : cause I had a bunch of other things going on and still do. But...
: :
: : I remember my good old DOS days, $b800 rings a bell ??????
:
: Sorry to burst the bubble, but it's not that simple
:
: Your GUI program with the TMemo (or whatever) is going to need to create a named pipe, and then using CreateProcess() execute the DOS (or Win32 console) program redirecting its output (stdout) to the pipe. That way the text being written to stdout by the program will not go to the screen like normal, and instead will go to the pipe that your GUI program can read from.
:
: I experimented with this about a year ago, but after learning of certain limitations I gave up and deleted my code, so I dont have any samples to give to you. But I learned how to do it through searching on Google, and through Experts Exchange (www.experts-exchange.com) so you might want to try that.
:
: Incidentally, the limitation I found was that any program written in Pascal using the CRT unit cannot have it's output captured. Since the programs I wanted to capture the output of all fell into this category, that's why I abandoned my efforts.
:

Report
Re: Writing a DOS app and Capturing DOS data Posted by biki on 19 Jul 2003 at 6:29 PM

What OS do you intend to use?
If Win2000, things are much easier.
See the STARTUPINFO struct's dwFlags params.

You can capture console data using:
1. Pipes
2. CreateFile (filename = "CONOUT$")
3. CreateProcess (calling it from your own console app)

These are the only techniques I know of.



~Bikram

Report
Re: Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 6:42 PM
hi bikram,

Sorry, I'm not familiar w/ the items you listed below. Can you elaborate
on their uses please ?

Delphi 6
Windows 98.

Thank you.
-mydelphi



:
: What OS do you intend to use?
: If Win2000, things are much easier.
: See the STARTUPINFO struct's dwFlags params.
:
: You can capture console data using:
: 1. Pipes
: 2. CreateFile (filename = "CONOUT$")
: 3. CreateProcess (calling it from your own console app)
:
: These are the only techniques I know of.
:
:

:
~Bikram
:
:

Report
Re: Writing a DOS app and Capturing DOS data Posted by Jeff P. on 19 Jul 2003 at 8:06 PM
: 2nd Question:
: How do I "capture" the data that is being generated (outputed)
: in a DOS screen (or session) into my app, in a TMEMO box ?


This should capture the output of the Command in Edit1.Text and send it to Memo1.Lines....

procedure TForm1.Button1Click(Sender: TObject);
var
 StartupInfo: TStartupinfo;
 ProcessInfo: TProcessInformation;
 DumpHandle:THandle;
 DumpFileName:string;
 CmdInt:string;
 SecyAttr:TSecurityAttributes;
begin
   if (SysUtils.Win32Platform = VER_PLATFORM_WIN32_NT)
   then CmdInt:='c:\cmd.exe /c '
   else CmdInt:='c:\command.com /c ';
   with SecyAttr do begin
     nLength:=SizeOf(SecyAttr);
     lpSecurityDescriptor:=nil;
     bInheritHandle:=True;
   end;
   Memo1.Clear;
   Memo1.Update;
   DumpFileName:=ExtractFilePath(ParamStr(0))+'DEBUG.TXT';
   Windows.DeleteFile(pChar(DumpFileName));
   FillChar(Startupinfo,Sizeof(TStartupinfo),0);
   Startupinfo.cb:=Sizeof(TStartupInfo);
   Startupinfo.dwFlags:= STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES ;
   Startupinfo.wShowWindow:=SW_HIDE;
   DumpHandle:=CreateFile(pChar(DumpFileName),
       GENERIC_WRITE, FILE_SHARE_WRITE,
       @SecyAttr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0) ;
   try
     Startupinfo.hStdError:=DumpHandle;
     Startupinfo.hStdOutput:=DumpHandle;
     if CreateProcess( nil, pChar(CmdInt + Edit1.Text),
           nil, nil, true, NORMAL_PRIORITY_CLASS,
           nil, nil, Startupinfo, ProcessInfo)
     then WaitforSingleObject(Processinfo.hProcess, infinite);
   finally
     CloseHandle(DumpHandle);
     CloseHandle(ProcessInfo.hProcess);
     if FileExists(DumpFileName) then begin
       Memo1.Lines.LoadFromFile(DumpFileName);
       if (Memo1.Lines.Count>0)
       and (Memo1.Lines[ 0 ]='')
       then Memo1.Lines.Delete(0);
       while (Memo1.Lines.Count>0)
       and (Memo1.Lines[ Memo1.Lines.Count-1 ]='')
       do Memo1.Lines.Delete(Memo1.Lines.Count-1);
       Memo1.Update;
       Windows.DeleteFile(pChar(DumpFileName));
     end;
   end;
end;


Report
Re: Writing a DOS app and Capturing DOS data Posted by mydelphi on 19 Jul 2003 at 8:21 PM
Hi Jeff P.

Does, "not" having CMD.EXE matter ?

I'm under windows 98, and I did a complete search of this file, and
its nowhere to be found. Is it important to this code ?

Or, can I use with brcc32.exe app ?
It does look a bit criptic, but I'll go over it with a fine toothed
comb.

Thank you for your suggestion.
-mydelphi



: : 2nd Question:
: : How do I "capture" the data that is being generated (outputed)
: : in a DOS screen (or session) into my app, in a TMEMO box ?
:
:
: This should capture the output of the Command in Edit1.Text and send it to Memo1.Lines....
:
:
: procedure TForm1.Button1Click(Sender: TObject);
: var
:  StartupInfo: TStartupinfo;
:  ProcessInfo: TProcessInformation;
:  DumpHandle:THandle;
:  DumpFileName:string;
:  CmdInt:string;
:  SecyAttr:TSecurityAttributes;
: begin
:    if (SysUtils.Win32Platform = VER_PLATFORM_WIN32_NT)
:    then CmdInt:='c:\cmd.exe /c '
:    else CmdInt:='c:\command.com /c ';
:    with SecyAttr do begin
:      nLength:=SizeOf(SecyAttr);
:      lpSecurityDescriptor:=nil;
:      bInheritHandle:=True;
:    end;
:    Memo1.Clear;
:    Memo1.Update;
:    DumpFileName:=ExtractFilePath(ParamStr(0))+'DEBUG.TXT';
:    Windows.DeleteFile(pChar(DumpFileName));
:    FillChar(Startupinfo,Sizeof(TStartupinfo),0);
:    Startupinfo.cb:=Sizeof(TStartupInfo);
:    Startupinfo.dwFlags:= STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES ;
:    Startupinfo.wShowWindow:=SW_HIDE;
:    DumpHandle:=CreateFile(pChar(DumpFileName),
:        GENERIC_WRITE, FILE_SHARE_WRITE,
:        @SecyAttr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0) ;
:    try
:      Startupinfo.hStdError:=DumpHandle;
:      Startupinfo.hStdOutput:=DumpHandle;
:      if CreateProcess( nil, pChar(CmdInt + Edit1.Text),
:            nil, nil, true, NORMAL_PRIORITY_CLASS,
:            nil, nil, Startupinfo, ProcessInfo)
:      then WaitforSingleObject(Processinfo.hProcess, infinite);
:    finally
:      CloseHandle(DumpHandle);
:      CloseHandle(ProcessInfo.hProcess);
:      if FileExists(DumpFileName) then begin
:        Memo1.Lines.LoadFromFile(DumpFileName);
:        if (Memo1.Lines.Count>0)
:        and (Memo1.Lines[ 0 ]='')
:        then Memo1.Lines.Delete(0);
:        while (Memo1.Lines.Count>0)
:        and (Memo1.Lines[ Memo1.Lines.Count-1 ]='')
:        do Memo1.Lines.Delete(Memo1.Lines.Count-1);
:        Memo1.Update;
:        Windows.DeleteFile(pChar(DumpFileName));
:      end;
:    end;
: end;
: 
: 

:

Report
Re: Writing a DOS app and Capturing DOS data Posted by Manning on 19 Jul 2003 at 9:10 PM
: Hi Jeff P.
:
: Does, "not" having CMD.EXE matter ?
:
: I'm under windows 98, and I did a complete search of this file, and
: its nowhere to be found. Is it important to this code ?
:
: Or, can I use with brcc32.exe app ?
: It does look a bit criptic, but I'll go over it with a fine toothed
: comb.


The part that uses cmd.exe is in an if statement, and so is only used on NT systems. If you dont use an NT system it uses c:\command.com instead.

One note on that method though...it would probably just be easier to use GetEnv('comspec') since hardcoding the path isnt a great solution (for example, c:\cmd.exe doesnt exist. On some systems it would be c:\winnt\system32\cmd.exe, and on others c:\windows\system32\cmd.exe)



 

Recent Jobs

Official Programmer's Heaven Blogs
Web Hosting | Browser and Social Games | Gadgets

Popular resources on Programmersheaven.com
Assembly | Basic | C | C# | C++ | Delphi | Flash | Java | JavaScript | Pascal | Perl | PHP | Python | Ruby | Visual Basic
© Copyright 2011 Programmersheaven.com - All rights reserved.
Reproduction in whole or in part, in any form or medium without express written permission is prohibited.
Violators of this policy may be subject to legal action. Please read our Terms Of Use and Privacy Statement for more information.
Operated by CommunityHeaven, a BootstrapLabs company.