Capture Desktop ?

[Ken Wilson]

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

[Lance Edmonds]

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

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

[Ken Wilson]

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.

------------------

[Lance Edmonds]

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!

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

[Walt Decker]

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).]

[Mike Luther]

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
else.

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
            ELSE
               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
technique.

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
network!

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]

[Dave Navarro]

Mike,

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.

--Dave


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

[Mike Luther]

Dave ..

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

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]

[Paul Mullen PC Guru]

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.

[Walt Decker]

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).]

[Gary Russell]

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.

Gary

------------------

[Lance Edmonds]

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


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

[Mike Luther]

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]