Announcement

Collapse
No announcement yet.

read console display screen buffer with a different program

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • read console display screen buffer with a different program

    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/pb...ad.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
    Code:
    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.
    Last edited by Paul Purvis; 7 Jul 2008, 04:12 PM.
    p purvis

  • #2
    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.
    sigpic
    Mobile Solutions
    Sys Analyst and Development

    Comment


    • #3
      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.
      Attached Files
      Last edited by Paul Purvis; 7 Jul 2008, 05:40 PM.
      p purvis

      Comment


      • #4
        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
        p purvis

        Comment


        • #5
          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
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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.
            Last edited by Paul Purvis; 31 Dec 2009, 01:43 PM.
            p purvis

            Comment


            • #7
              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
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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
                Code:
                  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.

                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
                Attached Files
                Last edited by Paul Purvis; 31 Dec 2009, 08:10 PM.
                p purvis

                Comment


                • #9
                  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.

                  Code:
                  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
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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.
                    p purvis

                    Comment


                    • #11
                      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
                      Code:
                      $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
                      Attached Files
                      Last edited by Paul Purvis; 2 Jan 2010, 11:34 PM.
                      p purvis

                      Comment

                      Working...
                      X