PCbanter

PCbanter (http://www.pcbanter.net/index.php)
-   General XP issues or comments (http://www.pcbanter.net/forumdisplay.php?f=18)
-   -   Pasting into DOS - slowing it down ? (http://www.pcbanter.net/showthread.php?t=1108751)

R.Wieser August 15th 19 12:45 PM

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



JJ[_11_] August 15th 19 05:17 PM

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.

R.Wieser August 15th 19 07:07 PM

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



Steve Hayes[_2_] August 16th 19 11:38 AM

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

R.Wieser August 16th 19 11:52 AM

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




Paul[_32_] August 16th 19 03:37 PM

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

R.Wieser August 16th 19 04:43 PM

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




Paul[_32_] August 16th 19 05:28 PM

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

R.Wieser August 16th 19 06:11 PM

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




All times are GMT +1. The time now is 12:03 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 2004 - 2006 PCbanter
Comments are property of their posters