read console display screen buffer with a different program

[Paul Purvis]

i wanted to say a few words about one program being able to read another programs screen output and did not want those words hidden deep inside another thread, so bear with me.

Chris Holbrook wrote a good example on how to read a console programs console screen buffer.

title:screen scrape a DOS application in the source code section
http://www.powerbasic.com/support/pb...ad.php?t=37868

the code does not work in windows 2000 pro or below because the program uses the attachconsole function and that function is only support in windows xp and up versions. do a search on attachconsole and get some details on operating systems supported.

so far i have not found a way to do what the program above code from Chris does in windows 2000 pro.
there are some workarounds but still have not found an alternative to his type of program where it can read, as far as i know, most all console programs output. it appears there is a way of locking the console's screen buffer of a console program to keep another program from reading the buffer, but that is another story.

in my efforts to read a consoles screen buffer and put that to good use for my needs, i also knew that i was going to have concerns in trying to have a program read a specific console programs screen. you surely do not want two console programs running with the same caption or program title inside the process ids. how easily could it make your program find which console screen buffer to read if there were more than one program running with the same ids.

the reason for this post is to report that maybe a combination of two programs can be used get the desired effects and have easily resolved problems of more that one instance of a console program running and trying to acquire the console screen buffer.

i am doing my best to make this short so stick with me

many programs written do not have embedded code to recognize that another instance of the same program is running, and also may console programs run very well behaved when having more than one instance of the program running and perform well behaved even while using a the same database.

half of the incentive behind a program i wrote call ISITRNIT was for the reason of having a second program monitor the console screen buffer of another program and insuring that the program monitoring the program knows which programs console screen buffer to monitor.

ISITRNIT.EXE and CONSNAME.EXE can be gotten here.

http://www.powerbasic.com/support/pbforums/showthread.php?t=37879

by using ISITRNIT, the program should not let you run multiple instances of the same batch job from a certain point after the program ISITRNIT is used in the batch job, and you do have to place statements in the batch file to interpret the ERRLEVEL returned to either abort the batch job or let the batch job continue to execute other statements.

when the batch job continues to execute(does not abort) after the IRITRNIT program, then the batch file will hopefully have the process id name as what was named from the IRITRNIT program. if any other statements have an effect of renaming the process id name, then maybe by using the CONSNAME program can reset the process id name back to what name you wanted in the beginning of the batch job.

using IRITRNIT and using CONSNAME to reinforce the process id name can hopefully limit the chance of second instance of the program starting thereby allowing a different program written to monitor just that one console program's console screen buffer.

sorry, it is only wordy because i am having a hard time with describing the events.

so as i said before elsewhere, i like using batch files to start programs and using these two programs, ISITRNIT and CONSNAME, you can do something like this
a simple batch file listing

c:
md \temp
cd \temp
ISITRNIT EDIT1
IF ERRLEVEL = 1 GOTO ABORT
rem consname is only to reinforce the processes name and might not be needed
CONSNAME EDIT1
cd \directoryofprogram
START c:\directory\monitorprgram EDIT1
EDIT ME.TXT
GOTO STOP
:ABORT
:STOP
EXIT

from the lines above, you can see where i would put my program that is monitoring the program "EDIT ME.TXT".
without being said, it is up to you to create the program "monitorprogram", using Chris's code as a starter.

there will be some problems where programs name their own captions/program id names and you can use the program ISITRNIT by itself to list program id names from a command prompt window.

hopefully the console program you are going to use does not rename the window's title caption making it easier for you to accomplish your goal of reading a console program's console screen buffer. it could be the end of the ropes as one might say if that would happen if you wanted to run multiple instances of the same program.

if you find yourself needing to run multiple instances of a program, create a second or more batch files like the first but altering the process names such as EDIT1 to EDIT2.

i could of probably made this clearer, but i do not have a editor on staff.

as of today, if you are wanting to do something of this sort in pre windows xp, i only know of two options.
one is to write a tsr program using powerbasic for dos and have the tsr write to a file the screen when either a certain key is pressed or when there has been no activity from the key board after so much time has lapsed.
second is to have a windows console or gui program start a second console program and monitor the second console's screen buffer and what a pain it will be if the console program you are monitoring uses emulators, tsrs, and god only knows what else to make the second console program run correctly. if you are using this method, you just might want to consider writing the captured screen buffer to a file and have third program making use of the captured screen data by reading the console screens buffer data that was saved inside the file.

a third way is to use the clipboard which works great for some things, but i do not know of any way of automate it, might as well do option 1 or 2 above.


ps, i am using windows 2000 pro, i wish attachconsole would have been implemented into my operating system, so i have the pain.

[Roger Garstang]

I agree his app/code was pretty slick and I wish it worked in all cases too as it would help me in testing old DOS apps against new GUI or console based ones. Windows is likely to block certain abilities at some point too once people start abusing them. Seems they make something good, then some virus abuses it and M$ or some Firewall/AV then block it.

[Paul Purvis]

Roger
i dislike changing of standards also.
i am not sure that they will remove this one soon because as examples in the forum have shown ways to retrieve data from other GUI programs as well and unless Microsoft removes console programs, that would be the only way i see them removing this function.
if i have read correctly, you can keep a console program from not sharing its screen buffer with embedded code, but i have not tested that because i wish to remain on my working windows 2k systems. at some point everything changes, if for no other reason, money.
also a move toward GUI programs is more than creation of console programs, so i do not believe they will spend time on the console screen buffer protection much.

if i can help you in some way just tell me what you want, it might also give me another way of looking at something i had not thought of myself in dealing with my own programming issues.

here is a program called TSRSR2FL written with Powerbasic for Dos.
it can print to a file a screen 25x80 characters and places a formfeed at the end of the file. the program originally was made to print to dos devices.
to print screen to the file or a device LPT1..LPT3 and also LPT4 in MSDOS OS, press the F12 key.
the code was just altered today to print to a file and there is no error checking.
ex: TSRSR2LF C:\TEMP.PRN
ex: TSRSR2LF LPT3
it may lock your program up, so it does not work in all cases and it uses quiet a bit of memory, but it works for our company.
you should be able to alter the code easily for your needs.

[Paul Purvis]

fyi on "console accessibility"
notes about accessing a console application's properties from a different application on windows os XP and later

http://msdn.microsoft.com/en-us/library/ms971319.aspx

[Michael Mattias]

I'm not sure I truly understand your problem, but let me try:

You want to 'screen scrape' some process' console output, but because the code you are currently using relies on the caption of the target console, you need some way to resolve ambiguity when more than one instance of said target program is running. One way you have thought to resolve the ambiguity is by preventing it altogether by not allowing more than one instance of the target program.

This is further complicated by the fact your operating system does not support one or more Windows' API functions used in your code.

Is that close?

Pray what does this third-party non-cooperating application do? Maybe you can just rewrite that. In my experience a lot of older systems use separate 'console utility' programs to do stuff 'the old way' when there is a new, simple way to do these things.

That is, I think you need to take a look at the bigger picture here... don't try to replace things "one piece at a time"... take a look at the whole application and see if you can't replace the whole shebang for a lot less effort than jerry-rigging (oops, political correctness violation!) something to work with the other existing pieces.

MCM

[Paul Purvis]

MCM

The program is a finance program operated in main line duties. The software is being supported by a third party and it is canned software in respect that there are over 100 companies now using it and bc there is only a few programmers, the software is standard in nature and can change at any time by the programmers to their liking. The software developed from msdos console programming and because of special calculations in the software, and all businesses are practicing with state and fed regulator guidelines and laws, i do not see the software changing as long as windows oses allow console programming.

There are things the program lacks in servicing a customer and it can be filled by using a gui program that runs in parallel with the console program. We have built up a substantial amount of database files similar to another program we where using in previous years.

I have a TSR program now running in the background to print the screen by pressing the F12 key and i am going change the program to save the screen to a file instead of sending the screen contents to the printer, then read the file by the user gui program. The gui program can send the F12 key to the console when it wants the file to be updated with the current screen.
By using this method, i believe that i can have different code to acquire the screen text for cases where the operating system is able to use the ATTACHCONSOLE API and when it does not exist in the os. Windows 2000 does not have Console WinEvents API programming as stated by Microsoft where i posted above.


MCM, I have been reviewing what you have posted already about PB 3.5 tsr programming.
I am mostly trying to reduce the size of memory the TSR program uses in case the msdos console software grows.

Thanks for the response.

later, i have tested the speed at which the tsr program reads the screen and sends the text to a file and it is far faster than i need.

[Michael Mattias]

MCM, I have been reviewing what you have posted already about PB 3.5 tsr programming.

Sheesh, I never would have guessed any of that stuff was still around. It's gotta be at least ten years since I did anything at all with TSRs for PB/DOS.

Although ..... my very first PAYING job as a contractor was a PB/DOS TSR... I don't think I'll ever forget that... 'twas 1994, for a company in Elk Grove Village IL. Nine hundred then very-much needed dollars.

MCM

[Paul Purvis]

Here is a listing of a pb 3.5 tsr program to capture the screen text into a text file.

Other than the main goal of simply putting the text into a 8.3 file,
My goal was to reduce the tsr memory down as far as possible , and that
meant the only error checking is to see if the file could be written, or created(opened for output)
The tsr program uses only 39376 bytes of memory, no swapping

To use the program, you must supply a valid 8.3 file name and directory or suffer any consequences. like "c:\temp\scrn.tmp"
This program uses hot key F12 to activate the tsr.
There is no tsr removal code in the program or checking for another instance of the tsr program running. for my purposes, it can stay in memory until the console is removed.
There are programs to remove tsr programs from memory.
This program was written for a special set of msdos applications that do not recognize the F12 key, if you test and change the key from F12 to something other like CRTL-ALT-F12 you may find the program source listing useful to almost any other program, but i am just guessing.
I have spent a lot of time in reducing down the amount of memory this program takes up.

The text file saved will probably give the same results as the ATTACHCONSOLE API along with using the GETCONSOLESCREENBUFFERINFO API.

If some improvement cannot be done by myself or anybody else to reduce the memory foot print, or changes made to improve the program will little increase in memory, i will put it in the source code section.
One piece of code code be added for idiot proofing is probably

  if len(prnfile)=0 then end ' before the setmem statment to keep the program from not loading if a file name is not given

The program will attempt 18 times to write to a file with some time pauses inbetween each before giving up and popping back down after the F12 key is pressed.
This is in case your gui program is reading the same file.

This program was designed mostly to work with other gui programs that will send the F12 key to the console where this tsr program is running and pause a short while for the file to be written.

For those of you who do not have PB 3.5, a nice program to do tsr programming with and here is a gift of the executable code.

REM TSRFSCRN.BAS
REM TSR WILL SEND THE SCREEN TEXT TO A FILE GIVEN ON THE COMMAND LINE
REM WHEN THE F12 IS PRESSED
REM POWERBASIC SOURCE CODE
REM VERSION 12-31-2009
REM COMPILED WITH POWERBASIC 3.5 FOR DOS
$CPU 80386 'program works on only 386 CPU and above
$DEBUG MAP OFF 'turn off map file generation
$DEBUG PBDEBUG OFF 'don't include pbdebug support in our executable
$LIB all OFF 'turn off all PowerBASIC's  libraries.
$ERROR BOUNDS OFF 'turn on bounds checking
$ERROR NUMERIC OFF 'turn off numeric checking
$ERROR OVERFLOW OFF 'turn off overflow checking
$ERROR STACK OFF 'turn off stack checking
$FLOAT NPX  'use floating point hardware only
$COM 0 'set communications buffer to nothing
$STRING 4 'set largest string size at 4k
$STACK 1536 'let's use a 1536 byte stack
$SOUND 0 'smallest music buffer possible
$DYNAMIC 'all arrays will be dynamic by default
$OPTION CNTLBREAK OFF 'don't allow Ctrl-Break to exit program
$OPTION GOSUB OFF 'don't preserve GOSUB stack on error
$COMPILE EXE 'this tells PB to make a standalone EXE
$EVENT OFF
DIM I AS INTEGER
DIM X AS LONG
REM DIM J AS INTEGER
DIM ABSOLUTE Video( 7999% ) AS BYTE AT &HB800
DIM PBUFFER AS BYTE PTR
DIM PRNFILE AS STRING
DIM SCREENTEXT AS STRING

SCREENTEXT = SPACE$( 4000% )
PRNFILE = COMMAND$

REM CTRL-ALT P   POPUP KEY CHR$(12,&H19,&H73)
REM ALT P POPUP KEY CHR$(&H08,&H19,&H70)
REM CTRL- P   POPUP KEY CHR$(04,&H19,&H73)
REM POPUP KEY CHR$(&H08,&H19,&H7B)
POPUP KEY CHR$(0,&H58,247) ' F12 is the hot key
X = SETMEM( -700000 ) 'release unused memory

POPUP SLEEP ' going to sleep the first time

REM here begins the loop writing screen text to a file upon tsr popup
READSCREENTEXT:
    PBUFFER = STRPTR32( SCREENTEXT )
    FOR I = 0 TO 7999 STEP 2
      @PBUFFER = Video( I )
      INCR PBUFFER
    NEXT

  X=18&
WRITESCREENTOFILE:
  REM ABORT SAVING THE SCREENTEXT TO THE FILE IF X=0
  IF X=0& THEN GOTO SLEEPAGAIN

  ON ERROR RESUME NEXT
  ERRCLEAR
  OPEN PRNFILE FOR BINARY AS #1
  PUT$ #1,SCREENTEXT
  CLOSE #1
  IF ERR THEN
     ERRCLEAR
     SLEEP .04
     X=X-1&
     GOTO WRITESCREENTOFILE
  END IF

SLEEPAGAIN:
  ON ERROR GOTO 0
  POPUP SLEEP 'going to sleep till

GOTO READSCREENTEXT

END

[Michael Mattias]

You could go to a smaller $STRING size were you to write the video to the buffer as you read it... because you would not have to build up a 4K string to hold it...e.g.

READANDWRITESCREENTEXT:
    LOCAL pB   AS BYTE PTR 
    OPEN PRNFILE FOR BINARY AS #1
    PB     =  VARPTR (Video(0))  ' point to first element of video for base 
    FOR Z =  0 TO 7999 STEP 2    
         PUT   #1,  ,@pb[Z]       ' write the first byte of current 2-char screen pos 
    NEXT 
    CLOSE   #1 
...

IF PB/DOS does not support the offset pointer syntax "@pB[Z]" then just
"INCR pBb, 2" in each loop.

MCM

[Paul Purvis]

Cool MCM
I edited a previous program to create this one and i would alter the screentext string variable then write the string back to screen memory.
The variable can be removed and code could be added easily if the programmer wants to insert CRLFs every 80 characters if wanted.
I will post back asap.

[Paul Purvis]

here is the program with MCM's suggestion that helped to remove about 4k of tsr memory foot print by removing a 4k string in the program altogether
now there are no strings in the program at all, except for the COMMAND$ variable.

i also rearranged some lines of code and changed a few line labels to make the labels more understandable.
i also put in a line of code to check if the command line was empty or not, if empty, then not let the program load.

the program now only takes up about 34528 bytes of memory without any swapping memory to either EMS memory or disk.

MCM's code implemented

$DIM ALL
REM TSRFSCRN.BAS
REM TSR WILL SEND THE SCREEN TEXT TO A FILE GIVEN ON THE COMMAND LINE
REM WHEN THE F12 IS PRESSED
REM POWERBASIC SOURCE CODE
REM VERSION 01-02-2010
REM COMPILED WITH POWERBASIC 3.5 FOR DOS
$CPU 80386 'program works on only 386 CPU and above
$DEBUG MAP OFF 'turn off map file generation
$DEBUG PBDEBUG OFF 'don't include pbdebug support in our executable
$LIB all OFF 'turn off all PowerBASIC's  libraries.
$ERROR BOUNDS OFF 'turn on bounds checking
$ERROR NUMERIC OFF 'turn off numeric checking
$ERROR OVERFLOW OFF 'turn off overflow checking
$ERROR STACK OFF 'turn off stack checking
$FLOAT NPX  'use floating point hardware only
$COM 0 'set communications buffer to nothing
$STRING 1 'set largest string size at 1k
$STACK 1536 'let's use a 1536 byte stack
$SOUND 0 'smallest music buffer possible
$DYNAMIC 'all arrays will be dynamic by default
$OPTION CNTLBREAK OFF 'don't allow Ctrl-Break to exit program
$OPTION GOSUB OFF 'don't preserve GOSUB stack on error
$COMPILE EXE 'this tells PB to make a standalone EXE
$EVENT OFF
DIM I AS INTEGER
DIM X AS LONG
DIM J AS INTEGER
DIM VIDEOBASE AS BYTE PTR
VIDEOBASE=&HB800??*65536??
IF LEN(COMMAND$)=0% THEN END

REM CTRL-ALT P   POPUP KEY CHR$(12,&H19,&H73)
REM ALT P POPUP KEY CHR$(&H08,&H19,&H70)
REM CTRL- P   POPUP KEY CHR$(04,&H19,&H73)
REM POPUP KEY CHR$(&H08,&H19,&H7B)
POPUP KEY CHR$(0,&H58,247) ' F12 is the hot key

ON ERROR RESUME NEXT

X = SETMEM( -700000 ) 'release unused memory

REM THE NEXT TO LINES OF CODE ARE IF  YOU WANT TO CREATE THE FILE WHEN THIS
REM     PROGRAM FIRST LOADS UP THE TSR
REM THE DEFAULT METHOD IS NOT CREATE THE FILE, THE TWO LINES ARE REMARKED OUT
REM X=18&
REM GOTO READANDWRITESCREENTEXT


REM PUTTING TO TSR TO SLEEP
PUTTSRTOSLEEP:
  POPUP SLEEP 'going to sleep till
  X=18&

REM here begins the loop writing screen text to a file on tsr popup
READANDWRITESCREENTEXT:

  REM ABORT SAVING THE SCREENTEXT TO THE FILE IF X=0
  IF X=0& THEN GOTO PUTTSRTOSLEEP
  ERRCLEAR
  J=(pbvScrnRows * pbvScrnCols*2) - 1
  KILL COMMAND$
  OPEN COMMAND$ FOR BINARY AS #1
    FOR I = 0 TO J STEP 2
    PUT #1,, @VIDEOBASE[I]
    NEXT
  CLOSE #1

  IF ERR THEN
     SLEEP .04
     DECR X
     GOTO READANDWRITESCREENTEXT
  END IF

  GOTO PUTTSRTOSLEEP

END