If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Pasting into DOS - slowing it down ?
Hello all,
I'm trying to paste some text into a DOS program (using alt-space, e, p), but see just a few chars appear (many are lost). I would like to try to use a slower char-buy-char pasting to see if that helps, but could not find any such speed setting (using Google). Does anyone know if 1) its possible 2) if so, how to change it ? Regards, Rudy Wieser |
Ads |
#2
|
|||
|
|||
Pasting into DOS - slowing it down ?
On Thu, 15 Aug 2019 13:45:16 +0200, R.Wieser wrote:
Hello all, I'm trying to paste some text into a DOS program (using alt-space, e, p), but see just a few chars appear (many are lost). That problem doesn't occur when pasting at the COMMAND.COM prompt. So chances are that your DOS program's use character based input and clears the keyboard buffer each time. I would like to try to use a slower char-buy-char pasting to see if that helps, but could not find any such speed setting (using Google). Does anyone know if 1) its possible 2) if so, how to change it ? There's no such setting. Clipboard is not designed with performance throttling. You'll just have to create custom application or AutoIt/AutoHotkey script to paste the text one character at a time. By preparing a character in the clipboard from the source text, then send the WM_COMMAND window message for the console's "Paste" menu. Repeat that until all characters are processed. |
#3
|
|||
|
|||
Pasting into DOS - slowing it down ?
JJ,
That problem doesn't occur when pasting at the COMMAND.COM prompt. Indeed (I did try that too, just to be sure it was the DOS program that caused it). I would like to try to use a slower char-buy-char pasting [snip] There's no such setting. Clipboard is not designed with performance throttling. I was already afraid of that. So chances are that your DOS program's use character based input and clears the keyboard buffer each time. Thats plausable. It is an old DOS program, and its rather possible that the designer of the program wanted to be sure the user could not type-ahead (some keystroke combinations are rather destructive) as some of its actions could be rather slow to execute. You'll just have to create custom application :-) I already did (just in case the preferred method would not exist). Sending a string already works. Using "keybd_event()" (User32.dll) and a few Sleep()'s caused the pasting to work as intended, just slowish (a ten-finger typer could easily outperform it). Though I think Windows task-switching could be partly to blame there. Thanks for the confirmation (of it not existing) and the suggestions. Regards, Rudy Wieser |
#4
|
|||
|
|||
Pasting into DOS - slowing it down ?
On Thu, 15 Aug 2019 13:45:16 +0200, "R.Wieser"
wrote: Hello all, I'm trying to paste some text into a DOS program (using alt-space, e, p), but see just a few chars appear (many are lost). I right-click on the blue bar at the top of the window, and then click "Edit -- Paste" Would that make a difference, or is it effectively the same thing? Perhaps it could be a setting in the DOS program itself. -- Steve Hayes http://www.khanya.org.za/stevesig.htm http://khanya.wordpress.com |
#5
|
|||
|
|||
Pasting into DOS - slowing it down ?
Steve,
I right-click on the blue bar at the top of the window, and then click "Edit -- Paste" Would that make a difference, or is it effectively the same thing? It looks very similar. I've tried it, but still lots of chars disappear. Perhaps it could be a setting in the DOS program itself. :-) The program in case is so old that it doesn't have any concept of copy-pasting from/to other sources/targets. Thanks for the suggestion though. Regards, Rudy Wieser "Steve Hayes" wrote in message ... On Thu, 15 Aug 2019 13:45:16 +0200, "R.Wieser" wrote: Hello all, I'm trying to paste some text into a DOS program (using alt-space, e, p), but see just a few chars appear (many are lost). I right-click on the blue bar at the top of the window, and then click "Edit -- Paste" Would that make a difference, or is it effectively the same thing? Perhaps it could be a setting in the DOS program itself. -- Steve Hayes http://www.khanya.org.za/stevesig.htm http://khanya.wordpress.com |
#6
|
|||
|
|||
Pasting into DOS - slowing it down ?
R.Wieser wrote:
Steve, I right-click on the blue bar at the top of the window, and then click "Edit -- Paste" Would that make a difference, or is it effectively the same thing? It looks very similar. I've tried it, but still lots of chars disappear. Perhaps it could be a setting in the DOS program itself. :-) The program in case is so old that it doesn't have any concept of copy-pasting from/to other sources/targets. Thanks for the suggestion though. Regards, Rudy Wieser In things like C code, some people use a "flush" function after gets() or similar. Which normally (when typing input) is not a problem, as the user cannot possibly type fast enough to "miss" a character because of the flush() call. However, pasting into a window and converting a paste buffer into a pipe to stdin, means the character stream is already queued up. Then it's a race condition, between the system loading the queue, and the DOS program (lightning fast) trying to eat characters and interspersing the calls with bogus flush(). I wrote some little five line program a month or two ago, where I learned of the various possible implementations, and I was using the wrong character input routine initially. And settled on another function which didn't need flush for consistency. This could mean, if you don't have access to source, you might not be able to correct the stdin behavior. It's not really a "speed thing" in the conventional sense - the use of FIFO queuing in a lot of file functions means (normally) the software would never lose a thing. Calling flush() is just dumb in a sense, bad juju as a programmer. It's just asking for trouble. It might mean that only typed input allows the race condition to be won in the DOS programs favor. int m; /* this won't hiccup */ while ( (m = getch()) != 13 ) { QueryPerformanceCounter((LARGE_INTEGER *)&time1); /* record time when key pressed */ /* do something with "m" */ } In the case of pasted input, the "time" value might have very small differences between each perceived character input. Paul |
#7
|
|||
|
|||
Pasting into DOS - slowing it down ?
Paul,
In things like C code, some people use a "flush" function after gets() or similar. JJ also mentioned something like that. Which normally (when typing input) is not a problem, as the user cannot possibly type fast enough to "miss" a character because of the flush() call. Agreed. However, pasting into a window and converting a paste buffer into a pipe to stdin, means the character stream is already queued up. Yep. So I wrote a program myself, emulating pushing chars into the keyboard buffer, using "keybd_event()", and saw the same dropping of characters. I had to put a Sleep() of 20 ms between the down and up calls, and another 70 ms afterwards to get the chars to appear as they should. Which makes me think that something else is paying a role here too (a max of about 11 char/sec is rather slow) This could mean, if you don't have access to source, you might not be able to correct the stdin behavior. And thats the case here. Other than trying to do some binary patching there is no way to alter the pasted-into program. Calling flush() is just dumb in a sense, bad juju as a programmer. I do not fully agree there. In the affected programs case certain keystroke combinations can result in rather time-consuming actions (like writing to/reading from floppy), which also could cause error messages to pop up (the floppy not beying ready). You don't want to have some type-ahead chars answering those "what to do now?" messages. Also, I get the feeling that its not fully the DOS programs fault. A max of 11 chars/sec is way too slow, even when a gets/flush sequence is interfering with the user typing chars. Regards, Rudy Wieser |
#8
|
|||
|
|||
Pasting into DOS - slowing it down ?
R.Wieser wrote:
I do not fully agree there. In the affected programs case certain keystroke combinations can result in rather time-consuming actions (like writing to/reading from floppy), which also could cause error messages to pop up (the floppy not beying ready). You don't want to have some type-ahead chars answering those "what to do now?" messages. Also, I get the feeling that its not fully the DOS programs fault. A max of 11 chars/sec is way too slow, even when a gets/flush sequence is interfering with the user typing chars. Regards, Rudy Wieser On Linux, you can use Xsendkeys to send characters to a window. I think Windows has sendkeys, but I don't know what the best packaging would be. If you write your own program, you could add a parameter to set the character rate. Windows Virtual PC uses a SendKeys approach to implement host to guest copy/paste. Which is fine, until some text gets lost. VirtualBox, I think once the driver is installed, it interacts at the buffer level instead. Which gives better integrity on copies, but doesn't allow "consumption throttling". If you're suitably motivated, I bet it can be fixed. Paul |
#9
|
|||
|
|||
Pasting into DOS - slowing it down ?
Paul,
I think Windows has sendkeys, but I don't know what the best packaging would be. I'm not sure where I should find 'sendkeys'. Is not a funcion in one of the regular DLLs (not in my header files), nor can I find it in de 'C:\Windows' tree. Ah, found it: https://docs.microsoft.com/en-us/win...user-sendinput Yes, I was also thinking of that one. But I'd like to be able to send the keystokes to a specific window (did already try WM_KEYDOWN and -UP send and post messages, but didn't work yet. Probably need WM_CHAR too) - so there is less chance that the paste is dumped in a window which could go crazy over it. If you write your own program, you could add a parameter to set the character rate. :-) I was thinking of two settings actually: the down-to-up delay, as well as the delay to the next down. VirtualBox, I think once the driver is installed, it interacts at the buffer level instead. Which gives better integrity on copies, but doesn't allow "consumption throttling". I take it you mean that as "hasn't been implemented", as I do not see any problem with delaying between chars there either. If you're suitably motivated, I bet it can be fixed. Inserting those Sleep()'s already did - even though it slows the whole thing down quite a bit. :-) Regards, Rudy Wieser |
Thread Tools | |
Display Modes | |
|
|