maximised state, we must be sure to disable the window offset used to
centre the terminal in cases where the window is non-negotiably the
wrong size (e.g. maximised). Hence we must call reset_window after our
terminal resize.
[originally from svn r9044]
restoring a maximised window.
Failure to do this was noticeable in the following scenario (again
using Aero UI enhancements):
1. resize window using topmost resize handle, and move pointer to top
of screen which 'maximises' the window vertically
2. now maximise the window properly using the maximise button in top
right
3. now restore. Notepad restores to its position before step 1,
because Aero remembers that position for the purpose, but PuTTY
thinks it knows better. Only now it doesn't any more.
[originally from svn r9041]
Firstly, maximise and restore events were expected never to occur
during an interactive resize process (i.e. between WM_ENTERSIZEMOVE
and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if
you move the pointer to the top of the screen while dragging the
window.
Secondly, plain old WM_SIZE events were expected never to occur
_outside_ interactive resizes, but Aero permits that too (e.g.
Windows-left and Windows-right), and also third-party window
repositioning tools will send these.
[originally from svn r9040]
called load_system32_dll() which constructs a full pathname for the
DLL using GetSystemDirectory.
The only DLL load not covered by this change is the one for
gssapi32.dll, because that one's not in the system32 directory.
[originally from svn r8993]
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]
sessions submenu of the terminal window context menu (as Pageant does), rather
than an empty menu (which often renders poorly).
[originally from svn r8648]
only call it when the _last_ mouse button comes back up. Otherwise,
xterm mouse tracking will lose a button-up event if you press down
two buttons, move the mouse outside the window, then release them
one at a time.
[originally from svn r8425]
case of double-width text (ESC # 3, ESC # 4, ESC # 6), because the
string passed to it was not truncated to the same width as the
clipping rectangle. (In fact, it _can't_ reliably be, in the case
where the window width is odd.) So instead we just assert that we
managed to _at least_ fill the clipping rectangle, not that we
exactly filled it.
The problem is easily reproduced by sending ESC # 8 (fill the screen
with Es) followed by ESC # 3. It doesn't typically happen, though,
if you _manually_ fill the screen with Es, because in that case
PuTTY's terminal buffer ends up being filled with CSET_ACP | 'E' or
similar, which means that general_textout() never gets called
because one of the other branches of do_text_internal() does the
work instead. ESC # 8 will fill the terminal buffer with genuine
_Unicode_ 'E' characters, which exercises the failing code path.
[originally from svn r8403]
subthread, so that it won't deadlock if fetching the content of the
clipboard turns out to depend on a network connection forwarded
through PuTTY.
[originally from svn r8338]
combination Ctrl + \ as the Ctrl-\ character. All of mine have, but
at least one laptop turns out not to. Do so explicitly.
[originally from svn r8182]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
simply specifying a hostname on the command line -- this would bring up the
config dialog. Use a slightly more sophisticated notion of whether the user
meant to launch a session.
[originally from svn r7321]
[r7265 == 5d76e00dac]
wouldn't care about except for the fact that it's still used to
implement the Saved Sessions menu item in PuTTY and Pageant.
[originally from svn r7291]
[r7265 == 5d76e00dac]
represent a launchable session, unless the user can be construed to
have really meant it. This means:
- starting up PuTTY when the Default Settings are launchable still
brings up the config box, and you have to hit Open to actually
launch that session
- double-clicking on Default Settings from the config box will load
them but not launch them.
On the other hand:
- explicitly loading the Default Settings on the command line using
`-load' _does_ still launch them.
[originally from svn r7265]
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]
r4906 in the process of adding the new timing code. It seems to have
been what was previously preventing spew-lockup, and still seems to
prevent it now I've put it back in.
[originally from svn r7071]
[r4906 == 7ecf13564a]
[this svn revision also touched putty-wishlist]
and various calls to WinHelp() have been centralised into a new file
winhelp.c, which in turn has been modified to detect a .CHM file as
well as .HLP and select between them as appropriate. It explicitly
tries to load HHCTRL.OCX and use GetProcAddress, meaning that it
_should_ still work correctly on pre-HTML-Help platforms, falling
gracefully back to WinHelp, but although I tested this by
temporarily renaming my own HHCTRL.OCX I haven't yet been able to
test it on a real HTML-Help-free platform.
Also in this checkin: a new .but file and docs makefile changes to
make it convenient to build the sources for a .CHM. As yet, owing to
limitations of Halibut's CHM support, I'm not able to write a .CHM
directly, more's the pity.
[originally from svn r7000]
easily manage, by adopting a hybrid approach to Unicode text
display. The old approach of simply calling ExtTextOutW provided
font linking without us having to lift a finger, but didn't do the
right thing when it came to bidirectional or Arabic-shaped text.
Arabeyes' replacement exact_textout() supported the latter, but
turned out to break the former (with no warning from the Windows API
documentation, so it's not their fault).
So now I've got a second wrapper layer called general_textout(),
which splits the input string into substrings based on bidi
character class. Any character liable to cause bidi or shaping
behaviour if fed straight to ExtTextOutW is instead fed through
Arabeyes' exact_textout(), but the rest is fed straight to
ExtTextOutW as it used to be.
The effect appears to be that font linking is restored for all
characters _except_ Arabic and other bidi scripts, which means in
particular that we are no longer in a state of regression over 0.57.
(0.57 would have done font linking on Arabic as well, but would also
have misbidied it, so we've merely exchanged one failure mode for
another slightly less harmful one in that situation.)
[originally from svn r6910]
session, we were clearing the new session_closed flag, but failing
to clear must_close_session; with that set, the session was being
opened but immediately re-closed.
[originally from svn r6857]
[r6802 == 0dcdb6c3c1]
behave like a pointer. In particular, the right thing to set a
HANDLE to to indicate that it's invalid is INVALID_HANDLE_VALUE, not
NULL. Crack down on sloppy use of NULL HANDLEs across all Windows
code.
(There is one oddity, which is that {Create,Open}FileMapping are
documented to return a NULL HANDLE instead of INVALID_HANDLE_VALUE
on failure. Shrug. If MS want to be inconsistent, I suppose I have
to live with it.)
[originally from svn r6833]
values one might expect, which means that GetMessage() was
occasionally blocking the process. That appears to be the last of
the annoying data loss issues, so I think the Windows serial back
end actually looks vaguely reliable now. Phew.
[originally from svn r6830]
in place of making a network connection. This has involved a couple
of minor infrastructure changes:
- New dlg_label_change() function in the dialog.h interface, which
alters the label on a control. Only used, at present, to switch
the Host Name and Port boxes into Serial Line and Speed, which
means that any platform not implementing serial connections (i.e.
currently all but Windows) does not need to actually do anything
in this function. Yet.
- New small piece of infrastructure: cfg_launchable() determines
whether a Config structure describes a session ready to be
launched. This was previously determined by seeing if it had a
non-empty host name, but it has to check the serial line as well
so there's a centralised function for it. I haven't gone through
all front ends and arranged for this function to be used
everywhere it needs to be; so far I've only checked Windows.
- Similarly, cfg_dest() returns the destination of a connection
(host name or serial line) in a text format suitable for putting
into messages such as `Unable to connect to %s'.
[originally from svn r6815]
of the previous ad-hockery which depended on the return value from
select_result() and hence which will not adapt sensibly to a world
in which the primary session is something local rather than a
network connection.
[originally from svn r6802]
thread-based approach to stdin and stdout, wraps it in a halfway
sensible API, and makes it a globally available service across all
network tools.
There is no direct functionality enhancement from this checkin:
winplink.c now talks to the new API instead of doing it all
internally, but does nothing different as a result.
However, this should lay the groundwork for several diverse pieces
of work in future: pipe-based ProxyCommand on Windows, a serial port
back end, and (hopefully) a pipe-based means of communicating with
Pageant, which should have sensible blocking behaviour and hence
permit asynchronous agent requests and decrypt-on-demand.
[originally from svn r6797]
Shift-hjklyubn for batch movement in NetHack, because they have
subtly different behaviour within the game and the Ctrl-moves are
more useful. Unfortunately, PuTTY's NetHack keypad mode doesn't
support Ctrl-moves. Therefore, it does now :-)
[originally from svn r6593]
button tend to get disabled on login.
After a suggestion by "Tkil", change the way we handle the specials menu
to be robust against the window menu being externally modified.
[originally from svn r6546]
[this svn revision also touched putty-wishlist]
