Solve : Copy DOS screen after it's Displayed?

1.	Solve : Copy DOS screen after it's Displayed?
Answer» Quote from: timrob on January 24, 2010, 04:45:28 PM Is there a way to copy a DOS screen? They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much DATA as the redirection.Quote from: Geek-9pm on January 27, 2010, 01:18:09 PM They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much data as the redirection. You can edit the screen buffer size (H: chars V: lines) in the cmd window properties.Quote from: Salmon Trout on January 27, 2010, 01:24:33 PM You can edit the screen buffer size (H: chars V: lines) in the cmd window properties. Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job. Is that what he wants? Quote from: Geek-9pm on January 27, 2010, 01:18:09 PM They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much data as the redirection. The setup for the screen shot and text capture are similar. Then, 1) Either PrintScreen key for a screen shot. or 2) click copy for text capture or 3) Redirection before the text is displayed Which method does TimRob need?Quote from: Geek-9pm on January 27, 2010, 01:32:51 PM Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job. Is that what he wants? http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspxQuote from: timrob on January 25, 2010, 04:06:16 PM Sorry, I misread your statement. I meant I wanted to capture what ever is on the DOS screen. whatever is on the DOS screen is whatever your DOS batch program spewed out via echo statements. Therefore, you can just redirect them to a file using > or >>. The rest of what's on your DOS screen are the cmd.exe prompt, plus whatever text you type in, which I don't really know why you want to capture them as well. There used to be, sometime in the dim past, a way to redirect all console output to a serial port. Would that be a hardware method? I think taht is still used when doing debugging on some kinds of system programs. Quote from: Geek-9pm on January 27, 2010, 01:32:51 PM Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job. Is that what he wants? Quote from: Salmon Trout on January 27, 2010, 01:38:13 PM http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx Main issue being that you'd need to somehow acquire the console handle, and even then I don't think you'd have much luck, since HANDLES aren't accessible cross-process. Quote And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. Have you ever used C#? or programmed for the NT environment? FIRST: it doesn't matter if you had a pointer. every memory pointer is only valid within the address space of a single process. you cannot, for example, take a handle to a string from one program and access that string in another program using that pointer; it simply doesn't work that way. Two programs can be running at the same time that have pointers that are the same but point to other items. Thus is the benefit of PROTECTED memory space and Virtualization. Additionally, even IF that was possible C# doesn't really give you any easy way of using direct pointers. C does, though it wouldn't be simple. How would you determine the size of the buffer? you don't, your pretty much forced to guess, and chances are you'll overrun that storage area and start emitting some other stuff from elsewhere. Quote from: Geek-9pm on January 27, 2010, 08:08:48 PM There used to be, sometime in the dim past, a way to redirect all console output to a serial port. Would that be a hardware method? I think taht is still used when doing debugging on some kinds of system programs. Yes. that's still possible. If you have a checked build of windows (read: dev build). And it doesn't output "Console" data it outputs messages direct from the kernel.Thank you , BC_Programmer, No I have not down programming is a NT environment. NT was after my days. I did assembly language in the old DOS environment . We just had to know where the segment was. I used to do this like this: Code: [Select] ... push cs pop dx ... Well, that is all i can remember, am not sure if it means anything anymore. Quote from: Geek-9pm on January 27, 2010, 08:54:53 PM Thank you , BC_Programmer, No I have not down programming is a NT environment. NT was after my days. I did assembly language in the old DOS environment . We just had to know where the segment was. I used to do this like this: Code: [Select] ... push cs pop dx ... Well, that is all i can remember, am not sure if it means anything anymore. yep, good ol' Segment:offset, IIRC; actually, although MS seems to claim otherwise in their literature, Win 9x never had a "protected memory model" you could inspect the memory of any process through ASM in a DEBUG session, I think. being based on a "protected memory pre-emptive tasking environment" was one of the requirements MS had to meet in order to get into the government market; It's more secure for the same reasons it's more difficult to work with in some scenario's. If you could inspect a command sessions memory for the command buffer you could just as easily inspect "super high profile banking application" for passwords stored directly in variables; or, if the program is designed properly, you'd be able to inspect the memory contents after the user typed in the super ultra secure password and copy it down. Of course they are contrived examples but it prevents spyware from being used against the government too much. On the other hand, it's still possible to inspect the memory of any process; the trick is to get a piece of code to run within that process, and then communicate (perhaps via named pipes) to the "main" process that collects the information. There are a few METHODS of injecting code into other processes, but it's rather involved. the "easy" way is to simply write a small DLL that get's loaded via the appInit_DLLs key in the registry; then there will be a DLL loaded into every single EXE process that starts, and that problem is solved; and Interprocess communication can be initiated between any process since that process will have "your" DLL loaded.To get back to the OP. You wold have to get the CMD.EXE to load another DLL that would "SPY" on the memory assignment. In the OP, he said in a batch file. Maybe he did not know that for a one-time thing anybody can do it manually by scrolling back into the screen buffer and then select EDIT MARK COPY and then open notepad and paste it into notepad. When he said batch. and screen capture i took him literally. We should have asked what he might earlier.

Answer»

Quote from: timrob on January 24, 2010, 04:45:28 PM

Is there a way to copy a DOS screen?

They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much DATA as the redirection.Quote from: Geek-9pm on January 27, 2010, 01:18:09 PM

They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much data as the redirection.

You can edit the screen buffer size (H: chars V: lines) in the cmd window properties.Quote from: Salmon Trout on January 27, 2010, 01:24:33 PM

You can edit the screen buffer size (H: chars V: lines) in the cmd window properties.

Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job.

Is that what he wants?

Quote from: Geek-9pm on January 27, 2010, 01:18:09 PM

They may be a limit of about 7 screens. When I scroll the screen it looks like about seven pages and the it truncates pages before that. So a screen capture would not get as much data as the redirection.

The setup for the screen shot and text capture are similar.

Then,

1) Either PrintScreen key for a screen shot.
or
2) click copy for text capture
or
3) Redirection before the text is displayed

Which method does TimRob need?Quote from: Geek-9pm on January 27, 2010, 01:32:51 PM

Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job.

Is that what he wants?

http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspxQuote from: timrob on January 25, 2010, 04:06:16 PM

Sorry, I misread your statement. I meant I wanted to capture what ever is on the DOS screen.

whatever is on the DOS screen is whatever your DOS batch program spewed out via echo statements. Therefore, you can just redirect them to a file using > or >>. The rest of what's on your DOS screen are the cmd.exe prompt, plus whatever text you type in, which I don't really know why you want to capture them as well. There used to be, sometime in the dim past, a way to redirect all console output to a serial port. Would that be a hardware method?
I think taht is still used when doing debugging on some kinds of system programs.
Quote from: Geek-9pm on January 27, 2010, 01:32:51 PM

Great! Now how do you find the pointer to the screen buffer? And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file. You would run it after the batch was all done. Theat way you would not have to modify the batch in any way. other that starting the screen buffer grabber at the end of the job.

Is that what he wants?

Quote from: Salmon Trout on January 27, 2010, 01:38:13 PM

http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx

Main issue being that you'd need to somehow acquire the console handle, and even then I don't think you'd have much luck, since HANDLES aren't accessible cross-process.

Quote

And is it a 32 bit absolute address? If so, you could compile a simple C# program to grab the whole thing and put it into a file.

Have you ever used C#? or programmed for the NT environment?

FIRST: it doesn't matter if you had a pointer. every memory pointer is only valid within the address space of a single process. you cannot, for example, take a handle to a string from one program and access that string in another program using that pointer; it simply doesn't work that way. Two programs can be running at the same time that have pointers that are the same but point to other items. Thus is the benefit of PROTECTED memory space and Virtualization.

Additionally, even IF that was possible C# doesn't really give you any easy way of using direct pointers. C does, though it wouldn't be simple. How would you determine the size of the buffer? you don't, your pretty much forced to guess, and chances are you'll overrun that storage area and start emitting some other stuff from elsewhere.

Quote from: Geek-9pm on January 27, 2010, 08:08:48 PM

There used to be, sometime in the dim past, a way to redirect all console output to a serial port. Would that be a hardware method?
I think taht is still used when doing debugging on some kinds of system programs.

Yes. that's still possible. If you have a checked build of windows (read: dev build). And it doesn't output "Console" data it outputs messages direct from the kernel.Thank you , BC_Programmer,
No I have not down programming is a NT environment. NT was after my days. I did assembly language in the old DOS environment . We just had to know where the segment was. I used to do this like this:
Code: [Select] ...
push cs
pop dx
...
Well, that is all i can remember, am not sure if it means anything anymore.
Quote from: Geek-9pm on January 27, 2010, 08:54:53 PM

Thank you , BC_Programmer,
No I have not down programming is a NT environment. NT was after my days. I did assembly language in the old DOS environment . We just had to know where the segment was. I used to do this like this:
Code: [Select] ...
push cs
pop dx
...
Well, that is all i can remember, am not sure if it means anything anymore.

yep, good ol' Segment:offset, IIRC; actually, although MS seems to claim otherwise in their literature, Win 9x never had a "protected memory model" you could inspect the memory of any process through ASM in a DEBUG session, I think.

being based on a "protected memory pre-emptive tasking environment" was one of the requirements MS had to meet in order to get into the government market; It's more secure for the same reasons it's more difficult to work with in some scenario's. If you could inspect a command sessions memory for the command buffer you could just as easily inspect "super high profile banking application" for passwords stored directly in variables; or, if the program is designed properly, you'd be able to inspect the memory contents after the user typed in the super ultra secure password and copy it down. Of course they are contrived examples but it prevents spyware from being used against the government too much.

On the other hand, it's still possible to inspect the memory of any process; the trick is to get a piece of code to run within that process, and then communicate (perhaps via named pipes) to the "main" process that collects the information. There are a few METHODS of injecting code into other processes, but it's rather involved. the "easy" way is to simply write a small DLL that get's loaded via the appInit_DLLs key in the registry; then there will be a DLL loaded into every single EXE process that starts, and that problem is solved; and Interprocess communication can be initiated between any process since that process will have "your" DLL loaded.To get back to the OP. You wold have to get the CMD.EXE to load another DLL that would "SPY" on the memory assignment.
In the OP, he said in a batch file. Maybe he did not know that for a one-time thing anybody can do it manually by scrolling back into the screen buffer and then select EDIT MARK COPY and then open notepad and paste it into notepad.

When he said batch. and screen capture i took him literally.

We should have asked what he might earlier.

Solve : Copy DOS screen after it's Displayed?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment