mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-12 00:28:06 -05:00
1ce8ec9c82
When the user pressed Return at the end of a line, we were calling the TermLineEditor's receiver function once for each character in the line buffer. A Telnet user reported from looking at packet traces that this leads to each character being sent in its own TCP segment, which is wasteful and silly, and a regression in 0.82 compared to 0.81. You can see the SSH version of the phenomenon even more easily in PuTTY's own SSH logs, without having to look at the TCP layer at all: you get a separate SSH2_MSG_CHANNEL_DATA per character when sending a line that you entered via local editing in the GUI terminal. The fix in this commit makes lineedit_send_line() collect keystrokes into a temporary bufchain and pass them on to the backend in chunks the size of a bufchain block. This is better, but still not completely ideal: lineedit_send_line() is often followed by a call to lineedit_send_newline(), and there's no buffering done between _those_ functions. So you'll still see a separate SSH message / Telnet TCP segment for the newline after the line. I haven't fixed that in this commit, for two reasons. First, unlike the character-by-character sending of the line content, it's not a regression in 0.82: previous versions also sent the newline in a separate packet and nobody complained about that. Second, it's much more difficult, because newlines are handled specially - in particular by the Telnet backend, which sometimes turns them into a wire sequence CR LF that can't be generated by passing any literal byte to backend_send. So you'd need to violate a load of layers, or else have multiple parts of the system buffer up output and then arrange to release it on a toplevel callback or some such. Much more code, more risk of bugs, and less gain.
PuTTY source code README
========================
This is the README for the source code of PuTTY, a free Windows and
Unix Telnet and SSH client.
PuTTY is built using CMake <https://cmake.org/>. To compile in the
simplest way (on any of Linux, Windows or Mac), the general method is
to run these commands in the source directory:
cmake .
cmake --build .
These commands will expect to find a usable compile toolchain on your
path. So if you're building on Windows with MSVC, you'll need to make
sure that the MSVC compiler (cl.exe) is on your path, by running one
of the 'vcvars32.bat' setup scripts provided with the tools. Then the
cmake commands above should work.
To install in the simplest way on Linux or Mac:
cmake --build . --target install
On Unix, pterm would like to be setuid or setgid, as appropriate, to
permit it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) The cmake install step
doesn't attempt to add these privileges, so if you want user login
recording to work, you should manually ch{own,grp} and chmod the
pterm binary yourself after installation. If you don't do this,
pterm will still work, but not update the user login databases.
Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory. If you aren't using one of our source snapshots,
you'll need to do this yourself. Halibut can be found at
<https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
https://www.chiark.greenend.org.uk/~sgtatham/putty/
If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.
See the file LICENCE for the licence conditions.