No announcement yet.

Capture Desktop ?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Capture Desktop ?

    Does anyone have any idea how I can capture my Desktop image
    on the fly (800 x 600 size), save it as a file, and thus use
    it in a screensaver ? I'm using PB 3.2 ... any code ideas, asm
    ideas ?

    Thanks very much - Ken

  • #2
    Are you talking about the Windows "desktop", or a {hi-res} DOS graphic's mode desktop (ie, using ModeX)?

    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      I'm referring to the Windows Desktop , even though I'm using the
      PB for DOS. My quess is that there could be a work-around, just as one can perform "behind the scenes" work through regular DOS commands, batch files, etc. I'm curious as to what the code would be in PB DOS ... perhaps if even some of it would be in ASM. I appreciate any help you give. Again, my aim is to save or
      "capture" the desktop image as a BMP, JPG, etc. (24 bit color image) into a file. This saved image could be later used/worked
      as it interacts with a screen-saver project I'd like to create. I appreciate any help you offer. Thank you, Lance, and everyone.



      • #4
        I seriously doubt this is at all possible with DOS, but it is definately possible to do this with a Windows (PB/DLL or PB/CC) application.

        Generally speaking, it involves getting a device context to the desktop window, create a compatible device context, creating a bitmap (using the desktop window size) into the compatible device context, and then performing a "bit-blit" (BITBLT) transfer from the desktop device context to the compatible context. At this point you'll have a memory bitmap of the desktop. All that remains is to write the bitmap to a disk file, release all of the DC's and bitmap handles, and you are done.

        Simple, eh? This is not a project that I would recommend for someone that has not programmed in Windows before. An understanding of the concepts of Windows programming is definitely required!

        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        mailto:[email protected]


        • #5
          Just an idea. You may try using a PB TSR which can scan the video memory when the desktop is visible without the TSR being visible at the same time. Since I'm new to PB I know little of how the PB TSRs work; however, if they work like most others, that is a possibility. You would probably have to use interrupts to query the video card for screen resolution and also to read the screen pixel by pixel (I think the colors would be 6-bit) but it may work. Check Ralph Brown's interrupt list. It may be possible.


          [This message has been edited by Walt Decker (edited March 02, 2000).]
          Walt Decker


          • #6
            Walt Decker is right on the money.

            We do this all the time to create holes in the current screen for
            help blocks. Most folks do not realize that there are provisions
            in BASIC for six screens of video in the video memory area of the
            system in at least the video mode we use all the time in character
            or text based work.

            There are, in our mode, some 8K of bytes for the text which is on
            the screen. Two bytes are used for each character. One byte is the
            character at the position on the line and the adjacent byte to it
            is the video attribute for the byte. Thus, a whole screen of text
            may be recovered, even while the screen in in view, by simply taking
            a peek at this array in memory and copying it off to someplace

            Just above the 8k space reserved for the screen you see will be
            another 8K! It's reserved for the next screen. Above that will
            be another 8K; that's the next screen and so on.

            In over 15 years at this, only one HP video card implementation
            has ever violated the ability to pop video up into the next 8K
            and store it there, to my experience!

            A typical code snip to chunk what is in a rectangle in the current
            window and pop it up into the next screen is below:

                        IF GFX% <> 3 THEN
                           DEF SEG = &HB800
                           DEF SEG = &HB000
                        END IF
                           FOR NZ% = HCLL% TO HCLR%
                              HXX% = PEEK(NZ% + 8000)
                              POKE (NZ%), HXX%
                           NEXT NZ%
            In the above, GFX% is a flag to tell the system whether it is in
            the Heathkit Z100 video system or not. And yes, some of our code
            is still running on Heathkit Z100 computers!! They used a non-
            standard location in memory for the video page back when Gordon
            Letwin, the father of HDOS, and later the father of DOS for Bill
            Gates, as well as the chief architect for OS/2, BASCOM PD7 and
            all was working for HeathKit and not Bill Gates!

            By selecting the appropriate values for the start and end of the
            block of memory you want, you can easily slush what is in there
            in memory into a hiding place. You can write what you want in
            place of that block using the common tools available to you in
            PowerBASIC, such as a complete little sub-screen for a help box.
            That, among other things, is how we get <f1> function key help
            boxes in all our programs. When you are through with the help
            box, you just invert the memory locations and copy the location
            you wrote up 8K higher and the screen is re-constructed.

            We also use the same technique for TSR's that are running in
            the background! We write the proposed video from the background
            running TSR that isn't asleep to one of the other reserved video
            pages in BASIC! Then, when we want to know what is to be
            revealed in the visible program, of the results of the work of
            the TSR, we simply peek at the memory in that location and poke
            it into a temporarily cleared hole in the screen using the above

            You can do all this with the commonly avaiable 3GL tools and
            functions available to you in PowerBASIC. In the alternative,
            if you are simply possessed for speed, you can substitute
            assembler code if you like, but, in practice, I've never seen
            where one would need this, unless one were blitzing through
            a milli-second critical comm port program or whatever.

            I think you will find that one of the fasted normal CPU low
            level instruction sets happens to be the simple copy of a
            block in memory to another place in memory.

            If you are using a screen display mode to which you can gain
            access for a peek at what is in raw memory for the above sort
            of technique, you can simply peek it byte by byte and poke it
            into a slush area reserved for it wherever you like. You can
            then store it in binary form on a disk file. You can then do
            a simple binary read of that disk file and pop it back on the
            screen, or print it as you like.

            You can even, using a time related sniffer read client in a
            pre-emptive multi-tasker, such as OS/2, do a complete min-
            server application that writes the screen data or print data to
            a known or random file name file on the server, which if seen
            there or anywhere else on the network that can see the server,
            will get you screen pops or printer pops for near-realtime
            alerts in OS/2 or Novell operations.

            We make extensive use of the techhnique and have been for many
            many years, such as creating a PowerBASIC print-server module
            which takes data from any invoicing terminal in a medical clinic
            with the standard printer doing demographic work, and, as far
            as the client can see, having this little print-server pop of
            the HCFA1500 form on a seemingly unrelated box across the whole

            All the trick takes is knowing where to get the data in memory
            from the pointer to it gained either as a function in good old
            PowerBASIC, or as in the case above, as a given we know from
            the technical standards for DOS which are published.

            Hope this gives you some ideas!

            Mike Luther
            [email protected]
            Mike Luther
            [email protected]


            • #7

              Are you sure that will work with Windows 95/98 (I know for a fact it won't with NT/2000)?

              Windows keeps DOS application memory (including video memory) seperate from its own. So I don't think that a DOS program can scan video memory and capture the Windows desktop.


              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Home of the BASIC Gurus


              • #8
                Dave ..

                I have no idea what WIN-98 etc. can or cannot do. I don't run

                As well, as far as I know, even an application in a session in
                OS/2 is protected and, can't see the desktop memory as well,
                unless it is allowed to do that. That would be leaving its
                allowable block of memory, wouldn't it?

                Yet in some ways, we do exactly that, so somehow the technique
                has to be allowed here.

                What I was trying to do was to help try to help solve the
                process of passing information to and from the application.

                I realize he asked about the whole screen, it wasn't my claim
                that he could access that part directly from the program.

                Subject opened, I realize that OS/2 is different than WIN-x ..
                I think I understand that it is possible in OS/2, for a thread
                to have access to some of the processes and resources of other
                threads. For example, in comm port use, we can ask to share a
                comm port between applications so that, so long as one app is
                not using it, another can use that same port.

                That means that, somehow, a thread must have the ability to
                check to see if someplace in memory is occupied on a shared
                basis and copy the information from that place to someplace
                else! Now, writing that portion in memory from two sources,
                a la two different threads, must be a different condtion.

                Otherwise, one couldn't gain information that a process was
                tied up by another process for sharing, right? It's all a
                binary deal; yes I'm occupied, no I'm not. To be able to
                answer that question between threads means that something
                has to be acceptable for looking at memory to determine yes
                or no.

                How much of this is allowed to be seen, that's the question.

                Don't we face this same thing in all TSR concepts? After all,
                isn't a TSR something of a surealistic sub operating system,
                that even the current one doesn't realize is really there? In
                reality, that's why, if you do ask to share resources with the
                formal operating system, you have to be so careful to check to
                see if the process is being used elsewhere before you go do
                it in the TSR, right?

                Take the timer tick for example. Ain't nice to steal it, but
                chaining it is, more or less, sometimes, OK, right?

                I don't pose to be knowledgable enough to know if there is a
                way to gain cross-thread capability to get at the section of
                memory. I sure don't have any WIN-xx experience.

                I posed the remark to open up thought about it, citing how it
                could be used to advantage, if it the concept could be done..

                Perhaps it didn't come out right off the screen as I posted it.
                My perceptions of all this are limited at times. You may laugh
                if you like, but working in a tiny posting window isn't quite
                the same thing as having both pages of a book open before you
                and the ability to flip pages instantly to compose things!

                A compliment!

                I assure you the current form of the composition capability in
                this BBS is *FAR* better than it was. Thank you! Thank you!

                Mike Luther
                [email protected]
                Mike Luther
                [email protected]


                • #9
                  Let's get this straight please! What you see from a DOS program running under Windows is NOT real physical memory but is the memory map allocated to your virtual DOS session.

                  So the video memory at A000 to BFFF, only relates to what your program is doing and NOT the Windows desktop.

                  In fact even Windows has no idea what physical memory is being used by the video card - that is a matter for the card and its driver. The days are long gone when this memory physically resided at A000 - after all that address space is only 128kb and most video cards these days have 4 or 8 Mb of memory.

                  To capture the Windows desktop you'll need a Windows application - there are plenty around. Or else just try the Print Screen key - which when running a Windows but not a DOS program, will copy the desktop into the clipboard.

                  The PC Guru, Austin Tx
                  Working on data recovery tools.


                  • #10
                    Originally posted by Paul Mullen PC Guru:

                    So the video memory at A000 to BFFF, only relates to what your program is doing and NOT the Windows desktop.

                    The days are long gone when this memory physically resided at A000 - after all that address space is only 128kb and most video cards these days have 4 or 8 Mb of memory.

                    Strange. The desktop graphic produced by WIN98 displays just fine (although a little slow) on my 128k video card. That seems to indicate that the grapics display still resides at A000h regardless of the amount of memory on the card. And the display is all Ken is interested in, not the data that produces the image.


                    [This message has been edited by Walt Decker (edited March 05, 2000).]
                    Walt Decker


                    • #11
                      Hears my $.02 warth.

                      Ovisaly if you have a 1 mag card the placment of the starting address will be limited, (of corse a 1 mag card will not do 800 by 600) and therefore eazy to find. But as stated above most cards are atlest 4 mag or more. Becouse many windows programs use DirectX, and DirectX does page filpping by using pointers instade of copying memory to memory you could not know where the image is on the video cord at any one time.




                      • #12
                        FYI, you can have 800*600 in 256 colors on a 1Mb card. You wont be able to have more then 256 colors though.

                        PowerBASIC Support
                        mailto:[email protected][email protected]</A>
                        mailto:[email protected]


                        • #13
                          Dave and Lance ..

                          There is, to date, not one peep of a reply to my quaint little
                          post in the alt.comp.OS2.programmer OOP or whatever the the
                          use group is called.

                          All I did is ask how I could do this from an OS/2 DOS-VDM session!

                          Ah well ..

                          Mike Luther
                          [email protected]
                          Mike Luther
                          [email protected]