I've done this on a 'where possible' basis: in Windows paletted mode
(in case anyone is still using an old enough graphics card to need
that!) I simply haven't bothered, and will completely ignore the dim
flag.
Markus Gans points out that some applications which (not at all
unreasonably) don't trust $TERM to tell them the full capabilities of
their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for
the colour-palette value in position nn, and they may not particularly
care _what_ the results are but they will use them to decide whether
the right number of colour palette entries even exist.
I know some users don't like any colour _at all_, and we have a
separate option to turn off xterm-style 256-colour sequences, so it
seems remiss not to have an option to disable true colour as well.
A mouse drag which manages to reach x < 0 (via SetCapture or
equivalent) was treated as having the coordinates of (x_max, y-1).
This is intended to be useful when the mouse drag is part of ordinary
raster-ordered selection.
But we were leaving that treatment enabled even for mouse actions that
went to xterm mouse tracking mode - thanks to Markus Gans for
reporting that - and when I investigated, I realised that this isn't a
sensible transformation in _rectangular_ selection mode either. Fixed
both.
This is a heavily rewritten version of a patch originally by Lorenz
Diener; it was tidied up somewhat by Christian Brabandt, and then
tidied up more by me. The basic idea is to add to the termchar
structure a pair of small structs encoding 24-bit RGB values, each
with a flag indicating whether it's turned on; if it is, it overrides
any other specification of fg or bg colour for that character cell.
I've added a test line to colours.txt containing a few example colours
from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run
the whole of rgb.txt through this treatment, with a command such as
perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
A user reports that a remote window title query, if the window title
is empty or if the option to return it is disabled, fails the
assertion in ldisc_send that I introduced as part of commit c269dd013
to catch any lingering uses of ldisc_send with length 0 that should
have turned into ldisc_echoedit_update. Added a check for len > 0
guarding that ldisc_send call, and likewise at one or two others I
noticed on my way here.
(Probably at some point I should decide that the period of smoking out
lingering old-style ldisc_send(0) calls is over, and declare it safe
to remove that assertion again and get rid of all the cumbersome
safety checks at call sites like these ones. But not quite yet.)
Ilya Shipitsin sent me a list of errors reported by a tool 'cppcheck',
which I hadn't seen before, together with some fixes for things
already taken off that list. This change picks out all the things from
the remaining list that I could quickly identify as actual errors,
which it turns out are all format-string goofs along the lines of
using a %d with an unsigned int, or a %u with a signed int, or (in the
cases in charset/utf8.c) an actual _size_ mismatch which could in
principle have caused trouble on a big-endian target.
Copying large scrollback buffers to the clipboard can take a long time,
up to several minutes. Doubling the size of the clipboard copy buffer
when more space is needed, instead of just adding a small constant size,
significantly speeds up clipboard copies of large scrollback buffers.
An opcode for this was recently published in
https://tools.ietf.org/html/draft-sgtatham-secsh-iutf8-00 .
The default setting is conditional on frontend_is_utf8(), which is
consistent with the pty back end's policy for setting the same flag
locally. Of course, users can override the setting either way in the
GUI configurer, the same as all other tty modes.
This is a minimal fix for CVE-2015-5309, and while it's probably
unnecessary now, it seems worth committing for defence in depth and to
give downstreams something reasonably non-intrusive to cherry-pick.
Parameters are now accumulated in unsigned integers and carefully checked
for overflow (which is turned into saturation). Things that consume them
now have explicit range checks (again, saturating) to ensure that their
inputs are sane. This should make it much harder to cause overflow by
supplying ludicrously large numbers.
Fixes two bugs found with the help of afl-fuzz. One of them may be
exploitable and is CVE-2015-5309.
I broke it as a side effect of commit 30e63c105, in which I intended
to ignore mouse drag events that hadn't been preceded by a click. I
didn't spot that right-clicks (assuming Unix-style button mappings) go
through the same code path as left-drags, and hence were being ignored
even though they _were_ their own initiating click.
On OS X GTK, when you click in a pterm that wasn't the active window,
the first click activates it but is swallowed by the windowing system
- but a subsequent tiny drag can still be taken as part of a selection
action, making it difficult to activate the window in order to paste
into it.
Fixed by ignoring mouse drags when the terminal.c mouse state was
NO_SELECTION; if we've seen one prior click then it should be
ABOUT_TO, or DRAGGING if we saw a double or triple click.
The original version of the xterm mouse tracking protocol did not
support character-cell coordinates greater than 223. If term_mouse()
got one, it would fail to construct an escape sequence for the mouse
event, and would then call ldisc_send() with a zero-length string -
which fails an assertion that I added in November (c269dd0135) on the
occasion of moving ldisc_echoedit_update() into its own function. So
the corresponding operation before that change would have done a
gratuitous ldisc_echoedit_update(), which is exactly the sort of thing
the assertion was there to catch :-)
Later extensions to the mouse tracking protocol support larger
coordinates anyway (try ESC[?1006h or ESC[?1015h in addition to the
ESC[?1000h that turns the whole system on in the first place). It's
only clients that don't use one of those extensions which would have
had the problem.
Thanks to Mirko Wolle for the report.
Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
A minus sign is illegal at that position in a control sequence, so if
ESC[13t should report something like ESC[3;-123;234t then we won't
accept it as input. Switch to printing the numbers as unsigned, so
that negative window coordinates are output as their 32-bit two's
complement; experimentation suggests that PuTTY does accept that on
input.
I'm not actually sure why we've always had back ends notify ldisc of
changes to echo/edit settings by giving ldisc_send(ldisc,NULL,0,0) a
special meaning, instead of by having a separate dedicated notify
function with its own prototype and parameter set. Coverity's recent
observation that the two kinds of call don't even have the same
requirements on the ldisc (particularly, whether ldisc->term can be
NULL) makes me realise that it's really high time I separated the two
conceptually different operations into actually different functions.
While I'm here, I've renamed the confusing ldisc_update() function
which that special operation ends up feeding to, because it's not
actually a function applying to an ldisc - it applies to a front end.
So ldisc_send(ldisc,NULL,0,0) is now ldisc_echoedit_update(ldisc), and
that in turn figures out the current echo/edit settings before passing
them on to frontend_echoedit_update(). I think that should be clearer.
Now Jacob has reminded me that 'resize-no-truncate' was already on the
wishlist, I notice that it suggested Clear Scrollback should remove
the preserved information off to the right. On the basis that that's
(at least partly) a privacy feature, that seems sensible, so let's do it.
[originally from svn r10210]
We now only truncate a termline to the current terminal width if we're
actually going to modify it. As a result, resizing to a narrower
terminal width and then immediately back again, with no terminal
output in between, should restore the previous screen contents. Only
lines that are actually modified while the terminal is narrow (and
scrolling them around doesn't count as modification) should now be
truncated.
This will be a bit nicer for Unix window resizing (since X lacks the
Windows distinction between mid-drag resize events and the ultimate
drag-release, so can't defer the call to term_size until the latter as
we can on Windows), but mostly it's inspired by having played with a
tiling window manager recently and hence realised that in some
environments windows will be resized back and forth without much
control as a side effect of just moving them around - so it's
generally desirable for resizes to be non-destructive.
[originally from svn r10208]
On Windows (X mouse reporting of the mouse wheel isn't currently done
by the Unix front end, though I'm shortly about to fix that too) a
mouse wheel event is translated into a virtual button, and we send
both a press and a release of that button to terminal.c, which encodes
both in X mouse reporting escape sequences and passes them on to the
server. This isn't consistent with what xterm does - scroll-wheel
events are encoded _like_ button presses, but differ semantically in
that they don't have matching releases. So we're updating to match
xterm.
[originally from svn r10138]
Handlers for a number of escape sequences, notably including ESC[J and
the sequences that switch to/from the alternate screen, were
unconditionally resetting the scrollback instead of first checking the
'Reset scrollback on display activity' configuration option. I've
added the missing if statements, so now 'Reset scrollback on display
activity' should actually mean what it says.
For example, this would have inconvenienced an mplayer user, who
wouldn't be able to go up and check their scrollback while mplayer was
repeatedly redisplaying its status line, because mplayer uses ESC[J to
erase each version of the status line before printing the next
version.
[originally from svn r10125]
Previously I had unthinkingly called the general-purpose
check_selection() routine to indicate that I was going to mess with n
character cells right of the cursor position, causing the selection
highlight to be removed if it intersected that region. This is all
wrong, since actually the whole region from cursor to EOL is modified
by any character insertion or deletion, so if we were going to call
check_selection it should be on that whole region. (Quick demo: select
part of the line to the right of the cursor, then emit ESC[P or ESC[@
and see the text move left or right while the highlight stays put.)
So we could just call check_selection() on that larger affected
region, and that would be correct. However, we can do something
slightly more elegant in the case where the selection is contained
entirely within the subregion that moves to one side (as opposed to
the characters that actually vanish at one or other end): we can move
the selection highlight with the text under it, to preserve the visual
reminder of which text was selected for as long as possible.
[originally from svn r10097]
In r10020 I carefully reimplemented using timing.c and callback.c the
same policy for large pastes that the previous code appeared to be
implementing ad-hoc, which included a 450ms delay between sending
successive lines of pasted text if no visible acknowledgment of the
just-sent line (in the form of a \n or \r) came back from the
application.
However, it turns out that that *wasn't* what the old code was doing.
It *would* have done that, but for the bug that it never actually set
the 'last_paste' variable, and never has done since it was first
introduced way back in r516! So the policy I thought had been in force
forever has in fact only been in force since I unwittingly fixed that
bug in r10020 - and it turns out to be a bad idea, breaking pastes
into vi in particular.
So I've removed the timed paste code completely, on the basis that
it's never actually worked and nobody seems to have been unhappy about
that. Now we still break large pastes into separate lines and send
them in successive top-level callbacks, and the user can still press a
key to interrupt a paste if they manage to catch it still going on,
but there's no attempted *delay* any more.
(It's possible that what I *really* ought to be doing is calling
back->sendbuffer() to see whether the backend is consuming the data
pasted so far, and if not, deferring the rest of the paste until the
send buffer becomes smaller. Then we could have pasting be delayed by
back-pressure from the recipient, and still manually interruptible
during that delay, but not have it delayed by anything else. But what
we have here should at least manage to be equivalent to the *actual*
rather than the intended old policy.)
[originally from svn r10041]
[r516 == 0d5d39064a]
[r10020 == 7be9af74ec]
I've removed the ad-hoc front-end bodgery in the Windows and GTK ports
to arrange for term_paste to be called at the right moments, and
instead, terminal.c itself deals with knowing when to send the next
chunk of pasted data using a combination of timers and the new
top-level callback mechanism.
As a happy side effect, it's now all in one place so I can actually
understand what it's doing! It turns out that what all that confusing
code was up to is: send a line of pasted data, and delay sending the
next line until either a CR or LF is returned from the server
(typically indicating that the pasted text has been received and
echoed) or 450ms elapse, whichever comes first.
[originally from svn r10020]
buffered in terminal.c indefinitely and only released when further
output turned up.
Arose because we suppress the call to term_out from term_data if a
drag-select is in progress, but when the drag-select ends we weren't
proactively calling term_out to release the buffered data. So if your
session generated some terminal output while you were in mid-select,
_and had stopped by the time you let go of the mouse button_, then the
output would just sit there until released by the next call to
term_data.
[originally from svn r9768]
xterm mouse tracking, both supported by the current up-to-date xterm
(288). They take the form of two new DEC terminal modes, 1006 and
1015, which do not in themselves _enable_ mouse tracking but they
modify the escape sequences sent if mouse tracking is enabled in the
usual way.
[originally from svn r9752]
attempting to call lineptr() with a y-coordinate off the bottom of the
screen and triggering the dreaded 'line==NULL' message box.
This crash can only occur if the bottommost line of the screen has the
LATTR_WRAPPED flag set, which as far as I can see you can only
contrive by constructing a LATTR_WRAPPED line further up the screen
and then moving it down using an insert-line escape sequence. That's
probably why this bug has been around forever without anyone coming
across it.
[originally from svn r9726]
window. scroll() iterates that many times, so this prevents a tedious
wait if you give a very large parameter to ESC[L or ESC[M, for
example.
A side effect is that very large requests for upward scrolling in a
context that affects the scrollback will not actually wipe out the
whole scrollback: instead they push just the current lines of the
screen into the scrollback, and don't continue on to fill it up with
endless boring blank lines. I think this is likely to be more useful
in general, since it avoids wiping out lots of useful scrollback data
by mistake. I can imagine that people might have been using it
precisely _to_ wipe the scrollback in some situations, but if so then
they should use CSI 3 J instead.
[originally from svn r9677]
First, make absolute times unsigned. This means that it's safe to
depend on their overflow behaviour (which is undefined for signed
integers). This requires a little extra care in handling comparisons,
but I think I've correctly adjusted them all.
Second, functions registered with schedule_timer() are guaranteed to be
called with precisely the time that was returned by schedule_timer().
Thus, it's only necessary to check these values for equality rather than
doing risky range checks, so do that.
The timing code still does lots that's undefined, unnecessary, or just
wrong, but this is a good start.
[originally from svn r9667]
platform manner, but which nothing ever called. It thus served only to
trap up the unwary. The live function key handling code lives in the
frontends, i.e. window.c on Windows and gtkwin.c on Unix.
[originally from svn r9579]
the offset horizontal line characters in the VT100 line-drawing set
(o,p,r,s), so that no trace of it - and hence no pointless performance
hit - is compiled into the cross-platform modules on non-Windows
platforms.
[originally from svn r9467]
which text pasted into the terminal is preceded and followed by
special function-key-like escape sequences ESC[200~ and ESC[201~ so
that the application can identify it and treat it specially (e.g.
disabling auto-indent-same-as-previous-line in text editors). Enabled
and disabled by ESC[?2004h and ESC[?2004l, and of course off by
default.
[originally from svn r9412]
UTF-16 support. High Unicode characters in the terminal are now
converted back into surrogates during copy and draw operations, and
the Windows drawing code takes account of that when splitting up the
UTF-16 string for display. Meanwhile, accidental uses of wchar_t have
been replaced with 32-bit integers in parts of the cross-platform code
which were expecting not to have to deal with UTF-16.
[originally from svn r9409]
(o,p,r,s). They are displayed in Windows by actually writing the
centred one (q) with a vertical offset, in case fonts don't have the
offset versions; this requires terminal.c to separate those characters
into distinct calls to do_text(). Unfortunately, it was only breaking
up a text-drawing call _before_ one of those characters, not after
one. Spotted by Robert de Bath.
[originally from svn r9221]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
today reported an SSH2_MSG_UNIMPLEMENTED from a Cisco router which
looks as if it was triggered by SSH2_MSG_IGNORE, so I'm
experimentally putting this flag in. Currently must be manually
enabled, though if it turns out to solve the user's problem then
I'll probably add at least one version string...
[Edited commit message: actually, I also committed in error a piece
of experimental code as part of this checkin. Serve me right for not
running 'svn diff' first.]
[originally from svn r8926]
function in terminal.c, and replace the cloned-and-hacked handling
code in all our front ends with calls to that.
This was intended for code cleanliness, but a side effect is to make
the GTK arrow-key handling support disabling of application cursor
key mode in the Features panel. Previously that checkbox was
accidentally ignored, and nobody seems to have noticed before!
[originally from svn r8896]
UTF-16 when exchanging wchar_t strings with the front end. Enabled
by a #define in the platform's header file (one should not
promiscuously translate UTF-16 surrogate pairs on 32-bit wchar_t
platforms since that could give rise to redundant encoding attacks),
which is present on Windows.
[originally from svn r8495]
as unsigned char. This means that passing in a bare char is incorrect on
systems where char is signed. Sprinkle some appropriate casts to prevent
this.
[originally from svn r8406]
has width and height swapped. Since both a random xterm I have and
<http://invisible-island.net/xterm/ctlseqs/ctlseqs.txt> agree with him, I've
changed ours. (This stuff appears to originate in dtterm, but I can't check the
behaviour of that right now.)
While I'm here, the are-we-iconified report (CSI 11 t) looks to have the
wrong sense compared to the same sources, so swap that too.
(All this has been this way since it was originally implemented in r1414,
which doesn't cite a source. all-escapes is silent too.)
[originally from svn r8376]
[r1414 == bb1f5cec31]
The scenario: I start a small, say 80x24, pterm. I do some work in
it, generating plenty of scrollback, and eventually I `less' a file.
`less' switches to the alt screen. Then I want more vertical space
to look at the file, so I enlarge the window to more like 80x60.
When I quit `less' and switch back to the primary screen, some
scrollback has been pulled down into the screen, as expected - but
the saved _cursor position_ is still at line 24, not at the bottom
of the new terminal where the prompt it goes with has moved to.
Solution: term_size() should adjust the alt-screen saved cursor
positions as well as the normal cursor position.
(Curiously, the problem doesn't happen on my home Debian box, even
without this fix. It happens on my RH9 box at work, though.)
[originally from svn r7911]
term_provide_resize_fn() was not being broken when the back end was
destroyed on session termination, causing resizing an inactive PuTTY
to be a segfault hazard.
[originally from svn r7143]
We now have an option where a remote window title query returns a well-formed
response containing the empty string. This should keep stop any server-side
application that was expecting a response from hanging, while not permitting
the response to be influenced by an attacker.
We also retain the ability to stay schtum. The existing checkbox has thus
grown into a set of radio buttons.
I've changed the default to the "empty string" response, even in the backward-
compatibility mode of loading old settings, which is a change in behaviour;
any users who want the old behaviour back will have to explicitly select it. I
think this is probably the Right Thing. (The only drawback I can think of is
that an attacker could still potentially use the relevant fixed strings for
mischief, but we already have other, similar reports.)
[originally from svn r7043]
I've been having with the cursor sometimes restoring to the wrong
place when screen(1) terminates. The offending sequence of escape
sequences goes ESC 7 (save cursor), ESC [?47h (switch to alternate
screen), ESC 7 (save cursor _again_), do some stuff, ESC 8 (restore
cursor), run screen session for a bit, ESC [?47l (return to main
screen), ESC 8 (restore cursor). The final ESC 8 is expected to
restore the cursor to where it was saved by the initial ESC 7.
Translation: the ESC 7 saved cursor state is part of the state we
must swap out when switching to the alternate screen. In other
words, we need to track _four_ cursor positions: active and saved,
on each of main and alternate screen. Previously we were tracking
only three.
[originally from svn r6788]
we otherwise would (for instance, if Shift is released before the mouse button
being used for selection).
[originally from svn r6727]
[this svn revision also touched putty-wishlist]
accepting 'G' as a hex digit. (The _first_ digit of the sequence
intentionally goes up further than F, but the remaining ones
shouldn't have.)
[originally from svn r6581]
A growable buffer was only being grown for actual text, not for newlines or
trailing NULs. A large run of empty lines could lead to newlines overflowing
the buffer (> 100 should be enough to guarantee this on all platforms, after
the initial 5k size of the buffer).
Also fix some valgrind in the same area (was probably harmless), and a memory
leak introduced by the RTF attribute pasting.
[originally from svn r6570]
[this svn revision also touched putty-wishlist]
basis for other terminal-involving applications: a stub
implementation of the printing interface, an additional function in
notiming.c, and also I've renamed the front-end function beep() to
do_beep() so as not to clash with beep() in lib[n]curses.
[originally from svn r6479]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
Unix Plink sends everything sensible it can find, and it's fully configurable
from the GUI.
I'm not entirely sure about the precise set of modes that Unix Plink should
look at; informed tweaks are welcome.
Also the Mac bits are guesses (but trivial).
[originally from svn r5653]
[this svn revision also touched putty-wishlist]
<http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c>.
This is identified both internally and in HTTP headers as 2003-05-20,
for Unicode 4.0.
Only changes from upstream are to make mk_wcwidth_cjk() non-static and to
#include "putty.h" for prototypes.
The status of some code points has changed; see the wishlist item. We've
had some feedback from the CJK and Arabic communities that upgrading is
probably the right thing to do.
[originally from svn r5547]
[this svn revision also touched putty-wishlist]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
its `line != NULL' assertion, so I've replaced the assertion with a
call to fatalbox() giving oodles of information. I may still not be
able to reproduce it, but at least next time it happens we should
see a decent amount of debugging data!
[originally from svn r5447]
to call _either_ do_text() _or_ do_cursor() on a given character
cell. In fact you're supposed to call do_text() no matter what, and
then call do_cursor() as well if it's got the cursor on it, since
do_cursor() _only_ draws the actual cursor, which often doesn't also
cause the text to get drawn.
I'm half tempted to change this in the interface, retire do_cursor()
as an external function and relegate it to an internal function in
each front end, and require that do_text() must fully process all
cursor attributes it is passed. However, I haven't done this yet.
[originally from svn r5017]
the start of every contiguous run passed to do_text() or
do_cursor(), and arranges never to overwrite only part of such a run
on the next update.
I'm a bit worried about this checkin because I've also completely
revamped cursor handling: the cursor was previously being drawn
_outside_ the main loop over the display line, and is now drawn as
part of that loop when it gets to the cursor location. It _seems_ to
still work sensibly, even in complex cases involving LATTR_WIDE and
double-width CJK characters etc, but I won't be entirely happy until
it's had some beta use.
[originally from svn r5003]
[this svn revision also touched putty-wishlist]
going through the line and working out which bits need to be redrawn
is now in a separate loop from the subsequent activity of actually
going through and doing the redraws. This _should_ enable me to
tinker with the which-bits-to-redraw data in between the two, thus
fixing `font-overflow'. However, I thought it would be sensible to
break the work up into two commits so we can track bugs in the
restructuring separately from bugs introduced by the new feature.
Also added a couple more terminal test files.
[originally from svn r5001]
results in unacceptable performance for him on Win2000. Add a checkbox to
revert to the old behaviour.
[originally from svn r4988]
[this svn revision also touched putty-wishlist]
_width_ of a terminal line (number of character cell positions) and
its _size_ (number of termchars), since of course these differ in
the presence of combining characters.
[originally from svn r4938]
transformed back and forth according to the character position
permutation output from the bidi algorithm. I was expecting that to
be a lot harder.
[originally from svn r4915]
blink when the window doesn't have focus, we don't schedule blink
timers at that point either.
Infrastructure change: term->has_focus should now not be written
directly from outside terminal.c. Instead, use the function
term_set_focus, which will sort out the blink timers as well.
[originally from svn r4911]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
the scrollback if you then leak away all the memory you saved!) One
of the leaks - by far the bigger of the two - was in my temporary
diagnostic function cc_check(), which is particularly embarrassing :-)
[originally from svn r4638]
was checking whether lattr == LATTR_NORM, where it should have been
checking (lattr & LATTR_MODE) to mask off LATTR_WRAPPED et al.
[originally from svn r4627]
XXX-REMOVE-BEFORE-RELEASE tag, since they're performance-intensive.
And now that I'm reasonably confident of remembering to remove them
before the next release, I feel less guilty about adding them willy-
nilly all over the place, so I've shoved in a couple more for now :-)
[originally from svn r4624]
array of each `termline' structure now contains optional additional
entries after the normal number of columns, which are used to chain
a linked list of combining characters off any primary termchar that
needs it. This means we support arbitrarily many combining
characters per cell (unlike xterm's hard limit of 2).
Cut and paste works correctly (selecting a character cell containing
multiple code points causes all those code points to be cut and
pasted). Display works by simply overlaying all the relevant
characters on top of one another; this is good enough for Unix
(xterm does the same thing), and mostly seems OK for Windows except
that the Windows Unicode fonts have a nasty habit of not containing
most of the combining characters and thus overlaying an
unknown-code-point box on your perfectly good base glyph.
I had no idea how to add support in the Mac do_text(), so I've
simply stuck in an assertion that will trigger the first time a
combining character is displayed, and hopefully this will bite
someone with the clue to fix it.
[originally from svn r4622]
The active terminal screen is no longer an array of `unsigned long'
encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of
`termchar' structures, which currently have 32-bit Unicode and 32
attribute bits but which will probably expand further in future.
To prevent bloat of the memory footprint, I've introduced a mostly
RLE-like compression scheme for storing scrollback: each line is
compressed into a compact (but hard to modify) form when it moves
into the term->scrollback tree, and is temporarily decompressed when
the user wants to scroll back over it. My initial tests suggest that
this compression averages about 1/4 of the previous (32 bits per
character cell) data size in typical output, which means this is an
improvement even without counting the new ability to extend the
information stored in each character cell.
Another beneficial side effect is that the insane format in which
Unicode was passed to front ends through do_text() has now been
rendered sane.
Testing is incomplete; this _may_ still have instabilities. Windows
and Unix front ends both seem to work as far as I've looked, but I
haven't yet looked very hard. The Mac front end I've edited (it
seemed obvious how to change it) but I can't compile or test it.
As an immediate functional effect, the terminal emulator now
supports full 32-bit Unicode to whatever extent the host platform
allows it to. For example, if you output a 4-or-more-byte UTF-8
character in Unix pterm, it will not display it properly, but it
will correctly paste it back out in a UTF8_STRING selection. Windows
is more restricted, sadly.
[originally from svn r4609]
`all session data' modes, without completely mauling the performance, by
fflush()ing once per term_out(). If anyone complains I suppose we can
make this optional.
[originally from svn r4445]
scrollback and the terminal to the clipboard, rather than just the
content before the cursor. Should fix copyall-to-cursor.
[originally from svn r3929]
from_backend() interface, after having made all implementations safe against
being called with len==0 and possibly-NULL/undefined "data".
(This includes making misc.c:bufchain_add() more robust in this area.)
Assertion was originally added 2002-03-01; e.g., see plink.c:1.53 [r1571].
I believe this now shouldn't break anything.
This should hopefully make `ppk-empty-comment' finally GO AWAY. (Tested
with Unix PuTTY.)
[originally from svn r3500]
[r1571 == fdbd697801]
by the SCO SNF and SNB sequences, which seems to be what the SCO console does
(at least in the new mode documented for OpenServer 5.0.6).
[originally from svn r3286]
CSI = Ps c
CSI = Pn1 ; Pn2 C
CSI = Ps D
CSI = Ps F
CSI = Ps G
SGR 6
Patch derived from one supplied by Leonid Lisoskiy, with several fixes from me.
[originally from svn r3263]
screen'. Now it also disables the save-and-restore-cursor behaviour
of ESC[?1048h and ESC[?1049h, since these sequences seem to be
output by software trying to switch to the alternate screen, and it
looks very odd to have the cursor position restored to where it was
before `less' when the garbage `less' wrote all over the screen is
still around. The `traditional' ESC 7 and ESC 8 still function as
normal, on the basis that they aren't usually used in conjunction
with the alternate screen. I'm not sure whether this will be the
right decision; I'm prepared to change it back if a sufficiently
serious counterexample shows up.
[originally from svn r3222]
time. This gives rise to a whole bunch of spare warnings, one or two
of which might have been actual bugs; now all resolved.
[originally from svn r3134]
hazard. I considered removing it completely, but I can't rule out
the possibility of an OS that actually takes security of its
terminal devices seriously, and which might be able to make sensible
and safe use of this feature.
[originally from svn r3103]
of PuTTY (terminal, backend, logctx etc) take a `void *' handle
passed to them from the frontend, and used as a context for all
their callbacks. Most of these point at the frontend structure
itself (on platforms where this is meaningful), except that the
handle passed to the backend has always pointed at the terminal
because from_backend() was implemented in terminal.c. This has
finally bitten Unix PuTTY, because both backend and logctx have
been passing their respective and very different frontend handles to
logevent(), so I've fixed it.
from_backend() is now a function supplied by the _frontend_ itself,
in all cases, and the frontend handle passed to backends must be the
same as that passed to everything else. What was from_backend() in
terminal.c is now called term_data(), and the typical implementation
of from_backend() in a GUI frontend will just extract the terminal
handle from the frontend structure and delegate to that.
This appears to work on Unix and Windows, but has most likely broken
the Mac build.
[originally from svn r3100]
being able to be a PuTTY as well as a pterm. In the process I've
also moved icky things like actually reading from the pty fd and
printing the `terminated on signal' messages into pty.c where they
obviously should have been in the first place. Also there's been one
interesting repercussion in the terminal code: terminal.c's
from_backend now calls term_out() directly rather than expecting the
front end to call it afterwards. This has had the entertaining side
effect of fixing a Windows-specific bug whereby activity in a port
forwarding through a PuTTY with a blinking cursor caused the cursor
to blink to ON (!!!!). So, a surprisingly far-reaching checkin as it
turns out...
[originally from svn r3017]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
but PuTTY was running out of memory, which is both easy and fatal under Mac OS
at present. Having fixed that, I've re-instated the screen-clearing and
cursor-homing on DECCOLM, and added resetting the scroll region, since this
seems to help VTL's keypad diagram display correctly.
[originally from svn r3006]
Correct interactions with DECOM and DECSTBM not investigated.
Should fix bug "deccolm-cls", but I'll leave it open till I've checked the
interactions.
[originally from svn r3001]
a marker which defines everything before it as `permanent'
scrollback and everything after it as `temporary'; only temporary
scrollback lines are returned to the main screen when the window
height is increased. Screen clears mark the lines pushed into the
scrollback as permanent; so lines explicitly cleared off the screen
by ESC[2J are never returned to it by mistake. This patch also fixes
the incorrect state the primary screen is left in when the window is
resized while the alternate screen is active.
[originally from svn r2923]
clears, and also to temporarily push the primary screen contents
into the scrollback while the alternate screen is active and bring
it back afterwards.
[originally from svn r2910]
combining adjacent ones for the same region, and runs them all in do_paint.
I'm not sure it's entirely right, but it works on my Mac in every case I've
tested.
[originally from svn r2763]
these fiddly little changes are no longer bugs I introduced
recently, they're bugs that have been around all along and I've only
just smoked out by altering the ATTR_* definitions.
[originally from svn r2754]
Apparently I used to rely on the fact that the same `erase_char'
used to wipe parts of the screen was also a good value to use for
resetting line attributes. Should now be more robust against future
reorganisations of the ATTR_* bit fields.
[originally from svn r2740]
foreground colours, and ESC[100m through ESC[107m to set bright
background colours. Hence, so do we. Bright-foreground is
distinguishable from bold, and bright-background distinguishable
from blink, when it leaves terminal.c; the front end may then choose
to display them in the same way if it's configured to do so. This
change makes the xterm backend for Turbo Vision (!!!) work properly.
Untested on Mac.
[originally from svn r2734]
