Fix several bugs that stopped %proxyport from doing anything useful.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7133 cda61777-01e9-0310-a592-d414129be87e

Fix Plink, the serial backend, and local-proxy support on Win98SE (at least),
which have been broken since r6797.
(At least some versions of Win9x are gratuitously picky about the arguments to
CreateThread(), requiring lpThreadId not to be NULL.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7132 cda61777-01e9-0310-a592-d414129be87e

Fix compiles on GCC 3.3, which doesn't know about assert(0);

git-svn-id: svn://svn.tartarus.org/sgt/putty@7130 cda61777-01e9-0310-a592-d414129be87e

Mention more versions of Windows. (Not Vista, yet.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7127 cda61777-01e9-0310-a592-d414129be87e

Don't use C99 mid-block declarations and don't do arithmetic on void *.
This helps with compilations on ancient Sun compilers.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7126 cda61777-01e9-0310-a592-d414129be87e

Move README.txt into windows subdir.
It's specific to the Windows installer, so it seems unnecessarily confusing to
have it in the top level of the source distribution alongside README.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7125 cda61777-01e9-0310-a592-d414129be87e

Flag user cancellation of authentication as a clean exit, so that it
will close the window even in `close window only on clean exit'
mode. Also, while I'm here, arrange a suitable exit code for
"exit-signal".

git-svn-id: svn://svn.tartarus.org/sgt/putty@7121 cda61777-01e9-0310-a592-d414129be87e

Update WINVER to 0x500 to avoid build failures from Jacob's
FlashWindow changes. Also fiddle with the <multimon.h> include,
which was subtly broken in turn by that.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7120 cda61777-01e9-0310-a592-d414129be87e

At least, I have the technology to fix `beepind-win2k'.
Tested on Win98, Win2K, and WinXP.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7119 cda61777-01e9-0310-a592-d414129be87e

Add more ifdefs to make uxser.c compile on OS X.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7118 cda61777-01e9-0310-a592-d414129be87e

Fold up the `SSH' branch of the treeview by default; it's getting
quite big and tends to hide the existence of the `Serial' config
panel.

This is implemented by folding up every branch of depth 2 or more,
which with any luck might turn out to be general enough to carry
over unchanged if other branches start expanding. Then again, we may
have to fiddle with it again when that time comes; who knows?

git-svn-id: svn://svn.tartarus.org/sgt/putty@7117 cda61777-01e9-0310-a592-d414129be87e

I've just realised that the data-logging options only work in PuTTY proper.
Document this.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7108 cda61777-01e9-0310-a592-d414129be87e

Remove the loops that close all open fds before running a
subprocess. They were intended to make sure the child process didn't
inherit anything embarrassing or inconvenient from us, such as the
master end of its own pty, but now we instead do this by making sure
to set all our own fds to not-FD_CLOEXEC on creation. This should
fix Debian bug #357520.

(This doesn't seem to work _quite_ right in uxproxy.c's invocation
of a local proxy command: both ends of a GTK internal pipe end up in
the child process's fd space. This appears to be another GTK 1 bug,
inasmuch as it goes away when I build with Colin's preliminary GTK 2
patch; for the moment I think leaving that pipe lying around is
probably less harmful than hampering the proxy process's ability to
use extra fds by prior arrangement with PuTTY's parent process.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7107 cda61777-01e9-0310-a592-d414129be87e

Experimental fix for `psftp-hang'. (Experimental only in that I haven't thought
about it very hard; it's a plausible fix for the observed cause of the extreme
CPU usage, being that we were asking to be notified of Windows messages and
then not dealing with them, plausibly leading to a loop. Works for me,
anyway.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7098 cda61777-01e9-0310-a592-d414129be87e

Remove redundant sentence.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7097 cda61777-01e9-0310-a592-d414129be87e

Miscellaneous updates.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7090 cda61777-01e9-0310-a592-d414129be87e

According to Frank Dijcks, this cast makes OpenWatcom happier.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7089 cda61777-01e9-0310-a592-d414129be87e

Various SSH-related things were appearing in the PuTTYtel configuration dialog,
probably since the addition of the serial backend. Use a more robust check for
SSH support.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7088 cda61777-01e9-0310-a592-d414129be87e

MinGW needs an extra symbol _WIN32_IE defined to a particular value before
it'll let you see an identifier (SHGFP_TYPE_CURRENT) referenced since r7082.
(Actually, you need a pretty recent w32api before it's there at all.)

Morally, this should be defined for all toolchains, not just MinGW/Cygwin, but  I'll leave that to people who have those toolchains.
<http://msdn2.microsoft.com/en-us/library/aa383745.aspx>

Also add some other comments on our use of this API (since it's a horrible one
that I suspect will come back and haunt us...)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7087 cda61777-01e9-0310-a592-d414129be87e

Get rid of all the MSVC warnings.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7086 cda61777-01e9-0310-a592-d414129be87e

Fix `puttygen-unix-perms': f_open(), PuTTY's wrapper on fopen, now
takes a third argument which is TRUE if the file is being opened for
writing and wants to be created in such a way that it's readable
only to the owner. This is used when saving private keys.

While I'm here, I also use this option when writing session logs, on
the general principle that they probably contain _something_
sensitive.

The new argument is only supported on Unix, for the moment. (I think
writing owner-accessible-only files is the default on Windows.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7084 cda61777-01e9-0310-a592-d414129be87e

Fix `win-randseed-location': use SHGetFolderPath() to find the
Application Data directory in preference to the old-fashioned
attempt to find the user's home directory, and use the _local-
machine_ Application Data directory in preference even to that.

SHGetFolderPath() is called via GetProcAddress, so this degrades
gracefully on old Windowses. (Tested myself on Win95.)

As part of this change, we now search for a location for the seed
file separately for reading and writing, so that installing the new
PuTTY should cause a seamless migration as the old seed file is read
from the old location and then a new one written to the new location.

`putty -cleanup' attempts to delete the seed file from _all_
affected locations.

Naturally, a user-specified seed file path in the Registry still
takes priority over all other means of finding the location.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7082 cda61777-01e9-0310-a592-d414129be87e

The remaining issue in `win-askappend-multi' appears to have been
caused by the MessageBox() internal message loop eating WinSock
FD_READ notifications, which then don't reappear afterwards because
you have to explicitly prod a socket in order to get a repeat
notification on it.

Hence, here's a piece of infrastructure which seems to sort it out:
a new winnet.c function called socket_reselect_all(), whose function
is to go through all currently active sockets and re-run
WSAAsyncSelect() on them, causing repeat notifications for anything
we might have missed. I call this after every call to MessageBox(),
and that seems to solve the problem.

(The problem was actually masked in very recent revisions, probably
by the reinstatement of pending_netevent in r7071. However, I don't
believe that was a complete fix. This should be.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7077 cda61777-01e9-0310-a592-d414129be87e

Have one call to from_backend() per call to do_telnet_read(),
instead of the previous rate of one per character. In `Flush log
file frequently' mode, the latter was causing excessive slowdown due
to fflush()ing once per byte.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7076 cda61777-01e9-0310-a592-d414129be87e

Fix ssh2-cisco-pw-pad by reverting r5122. However, I've kept the
ability to easily re-enable the r5122 behaviour, in case we need to
conditionally switch between the two at a later date.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7073 cda61777-01e9-0310-a592-d414129be87e

Greater leniency when importing private key files: accept both CRLF
and LF, and don't object if the final line of the key lacks a
newline. Also, while I'm here, switch to using fgetline() throughout
so as not to have to do nasty buffer-size ad-hockery.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7072 cda61777-01e9-0310-a592-d414129be87e

Reinstate RDB's pending_netevent mechanism, which was removed in
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.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7071 cda61777-01e9-0310-a592-d414129be87e

Tweak the icon script, and the generated icons, to more closely
match the original icons. (Apparently I managed to introduce errors
while transcribing the originals for detailed analysis.)

While I'm at it, add the obviously useful `make install' target in
icons/Makefile, and fix the svn:ignore property on the icons
directory.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7068 cda61777-01e9-0310-a592-d414129be87e

I think this change to Recipe was accidentally omitted from r7064.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7065 cda61777-01e9-0310-a592-d414129be87e

No, I tell a lie: GTK 1 _does_ support icons, at least partially. Ooh.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7064 cda61777-01e9-0310-a592-d414129be87e

Shiny new script which constructs the various icons for the PuTTY
suite. In a dramatic break with tradition, I'm actually checking in
the resulting icon files as well as the script that generates them,
because the script requires Python and ImageMagick and I don't think
it's reasonable to require that much extra infrastructure on
everyone checking out from Subversion.

The new icons should be _almost_ indistinguishable from the old
ones, at least at the 32x32 resolution. The immediately visible
change is that all the icons now come in 16x16, 32x32 and 48x48
formats, in both 16 colours and monochrome, instead of an ad-hoc
mixture of whichever ones I could be bothered to draw.

The same code can also be adapted to generate icons for the GTK port
(although icons for the running programs don't seem to be supported
by GTK 1 - another reason to upgrade to GTK 2!).

git-svn-id: svn://svn.tartarus.org/sgt/putty@7063 cda61777-01e9-0310-a592-d414129be87e

Francois L'Archeveque spotted that the variable `winsock2_module'
only exists when compiling for IPv6, so we shouldn't try assigning
to it the rest of the time.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7059 cda61777-01e9-0310-a592-d414129be87e

It's a new year.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7048 cda61777-01e9-0310-a592-d414129be87e

Patch inspired by one from Daniel Silverstone in Debian bug #229232:

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.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7043 cda61777-01e9-0310-a592-d414129be87e

Patch from Colin Watson intended to give a clean Unix compile with GCC 4.
(Since we choose to compile with -Werror, this is particularly important.)

I haven't yet checked that the resulting source actually compiles cleanly with
GCC 4, hence not marking `gcc4-warnings' as fixed just yet.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7041 cda61777-01e9-0310-a592-d414129be87e

Use va_copy() where available. This should fix a segfault in vsnprintf()
on AMD 64 Linux.
(This has been sitting in my checkout for ages and hasn't obviously caused
any trouble -- I think I was waiting to get round to trying it with VC6, which
I haven't yet. There are some notes in comments on further tweaks that could
be made.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7035 cda61777-01e9-0310-a592-d414129be87e

Colin Watson points out that there was no need for me to write the
custom Panels container widget for the PuTTY config box, since the
perfectly standard GtkNotebook does the same job. Hence, let's
remove Panels completely in favour of doing it the proper way.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7034 cda61777-01e9-0310-a592-d414129be87e

Add a NO_HTMLHELP option, and enable it by default in the Cygwin Makefile,
since even the latest version of w32api (3.6) shows no sign of HTMLHelp
support.

(This touches mkfiles.pl because that's where the details of what Cygwin
doesn't support are kept currently. This may be deliberate, so I haven't
changed it.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@7032 cda61777-01e9-0310-a592-d414129be87e

I'm not sure why I added htmlhelp.lib to the PuTTY link lines in
r7000. I was probably half asleep. Actually, it's completely
unnecessary to bind to it at link time, because we load it at run
time in order to continue working as before on Win95. So I'm
removing it again.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7030 cda61777-01e9-0310-a592-d414129be87e

Nearly forgot: add the .CHM to the PuTTY installer. This involves
making the manual shortcut in the Start menu point to one or other
of the two help files depending on the version of Windows;
fortunately Inno Setup has no difficulty doing that.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7028 cda61777-01e9-0310-a592-d414129be87e

`make mostlyclean', to remove everything directly Halibut-generated
but not the CHM. It'll come in useful during the release process.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7027 cda61777-01e9-0310-a592-d414129be87e

Add some CHM-related stuff to the release checklist. Don't want to
forget about it when the time comes.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7012 cda61777-01e9-0310-a592-d414129be87e

After discussion with Jeroen Massar, here's a patch (mostly his)
which we think fixes the vista-ipv6 problem.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7007 cda61777-01e9-0310-a592-d414129be87e

Minor style tweaks for the CHM.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7002 cda61777-01e9-0310-a592-d414129be87e

Sort out line-endings on new file.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7001 cda61777-01e9-0310-a592-d414129be87e

Initial support for HTML Help. All the ad-hoc help-file finding code
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.

git-svn-id: svn://svn.tartarus.org/sgt/putty@7000 cda61777-01e9-0310-a592-d414129be87e

Set FD_CLOEXEC in a little convenience function that does the right thing
with F_GETFD and F_SETFD.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6978 cda61777-01e9-0310-a592-d414129be87e

Correct an embarrassingly wrong comment.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6926 cda61777-01e9-0310-a592-d414129be87e

I've just discovered that using the saved sessions menu from Unix
PuTTY causes the child process to inherit a lot of socket fds from
its parent, which is a pain if one of them then ends up holding open
a listening socket which the parent was using for port forwarding
after the parent itself is dead.

Therefore, this checkin sprinkles FD_CLOEXEC throughout the Unix
platform directory wherever there looks like being a long-lived fd.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6917 cda61777-01e9-0310-a592-d414129be87e

Reinstate as much of the Windows font-linking behaviour as I can
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.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6910 cda61777-01e9-0310-a592-d414129be87e

Chris Boucher spotted that after "-nc" was added (r6823), cfg->ssh_nc_host
was not always initialised, which could lead to spurious attempts to open
a bogus channel (typically refused: "FATAL ERROR: Server refused to open
a direct-tcpip channel"). Fixed.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6907 cda61777-01e9-0310-a592-d414129be87e

(Config).remote_cmd2[512] was added in r1208, but it wasn't used then and isn't
now, so presumably never has been. Remove.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6906 cda61777-01e9-0310-a592-d414129be87e

publickeyfile now an RFC

git-svn-id: svn://svn.tartarus.org/sgt/putty@6905 cda61777-01e9-0310-a592-d414129be87e

Link to faq-cleanup from faq-settings.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6904 cda61777-01e9-0310-a592-d414129be87e

There's been an increase in people posting non-SSH PuTTY-related questions
to comp.security.ssh, posting queries that are clearly about PuTTY to
newsgroups without actually mentioning PuTTY, and so on. They may have been
directed there by this document :( Add a futile attempt to instil a sense of
etiquette.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6895 cda61777-01e9-0310-a592-d414129be87e

Administrivia: most SSH-2 specs are no longer drafts.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6890 cda61777-01e9-0310-a592-d414129be87e

Tiny comment fix.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6885 cda61777-01e9-0310-a592-d414129be87e

Spotted by Tim Kosse: we were returning an incorrect path in canonify() when
we couldn't get any sense out of the server.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6877 cda61777-01e9-0310-a592-d414129be87e

Minor semantic tweak to bug-compatibility modes: make
BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent
of whether BUG_CHOKES_ON_SSH1_IGNORE is set.

This is invisible in the default configuration, as all servers marked as having
the second bug have the first one too, but it would allow one to manually
configure PuTTY to cope with a SSH-1 server that got upset by ignore messages
during authentication, but was fine with their use as keepalives.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6876 cda61777-01e9-0310-a592-d414129be87e

Disable a bunch of undesirable termios flags. ICRNL, in particular,
is liable to have been set on serial ports previously used as
terminal devices, and definitely wants not to be set on serial ports
being used for callout.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6865 cda61777-01e9-0310-a592-d414129be87e

IXON and IXOFF belong in _iflag_, not cflag! While I'm here, be more
reliable in clearing of RTS/CTS flags.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6864 cda61777-01e9-0310-a592-d414129be87e

Fix breakage of `Restart Session' in r6802. When restarting the
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.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6857 cda61777-01e9-0310-a592-d414129be87e

Note that the dynamic-tunnel proxy does not support UDP, since we get asked
about this quite often.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6855 cda61777-01e9-0310-a592-d414129be87e

CSI 3 J now clears the scrollback, as in xterm.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6847 cda61777-01e9-0310-a592-d414129be87e

I seem to have slightly funted Plink's display of banners etc in r6437, oops.
Fixed.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6846 cda61777-01e9-0310-a592-d414129be87e

Slight change to password expiry UI for the benefit of Cisco servers, which
are as usual slightly odd.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6845 cda61777-01e9-0310-a592-d414129be87e

Support for an alternative mechanism for displaying wide characters
under X: instead of having two separate fixed-width fonts one of
which is twice the width of the other, you can instead have a single
font in which some characters are twice as wide as others.

This is implemented very simply: if you specify a wide font, it will
be used for wide characters, and if you don't then the normal font
will be used for wide characters (so they'd better _be_ wide in that
font, or there'll be trouble).

I got this idea from Jed, whose latest version supports UTF-8 and
requires a font of this type. If there are going to be X fonts like
that kicking around, there will doubtless be people who want to use
them.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6844 cda61777-01e9-0310-a592-d414129be87e

Add a mini-rant to the top comment explaining why threads are
required. (I just tried getting rid of them; it worked fine for
serial ports, but not for anything else. The Windows I/O API sucks.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6843 cda61777-01e9-0310-a592-d414129be87e

Updates for today's changes:
 - changes to Logging panel
 - breaks in serial backend
(Plus, completely unrelated, an index term entry related to port forwarding
which seems to have been sitting around for ages, possibly waiting for me to
think about `see also' index terms in Halibut.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6836 cda61777-01e9-0310-a592-d414129be87e

New logging mode, which records the exact bytes sent over the wire
in an SSH connection _in addition_ to the decrypted packets. This
will hopefully come in useful for debugging wire data corruption
issues: you can strace the server, enable this mode in the client,
and compare the sent and received data.

I'd _like_ to have this mode also log Diffie-Hellman private
exponents, session IDs, encryption and MAC keys, so that the
resulting log file could be used to independently verify the
correctness of all cryptographic operations performed by PuTTY.
However, I haven't been able to convince myself that the security
implications are acceptable. (It doesn't matter that this
information would permit an attacker to decrypt the session, because
the _already_ decrypted session is stored alongside it in the log
file. And I'm not planning, under any circumstances, to log users'
private keys. But gaining access to the log file while the session
was still running would permit an attacker to _hijack_ the session,
and that's the iffy bit.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6835 cda61777-01e9-0310-a592-d414129be87e

Explicitly closing logctx on various kinds of error exit means that
the log file gets fclosed properly and the critical last few
messages might be recoverable from the log file more often...

git-svn-id: svn://svn.tartarus.org/sgt/putty@6834 cda61777-01e9-0310-a592-d414129be87e

The Windows HANDLE type, despite being a `void *', does not actually
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.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6833 cda61777-01e9-0310-a592-d414129be87e

Support for sending serial breaks, in both the Windows and Unix
serial backends.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6832 cda61777-01e9-0310-a592-d414129be87e

Inhibit the Serial configuration panel in mid-session if the session
isn't a serial one. In particular, this causes pterm not to fail an
assertion if you select `Change Settings'. Ahem.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6831 cda61777-01e9-0310-a592-d414129be87e

Apparently MsgWaitForMultipleObjects doesn't always return the
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.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6830 cda61777-01e9-0310-a592-d414129be87e

That OVERLAPPED fix seems to have made flow control useful as well
(presumably Windows's serial buffer is actually _filling up_,
causing an XOFF to be sent, now that my dodgy I/O code isn't causing
it to leak). So I think I'll switch the default flow control to
XON/XOFF, since it actually seems to do something now.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6829 cda61777-01e9-0310-a592-d414129be87e

Eep! Next bit flag after 1 and 2 is _4_, not 3. Perhaps it's time I
stopped coding and went and sat down quietly and tried not to touch
anything for a while.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6828 cda61777-01e9-0310-a592-d414129be87e

Reading 4K at a time from a serial port turns out to be a bit
unfriendly in an interactive session, because at 19200 baud it takes
nearly two seconds to receive that much data, and as long as the
data is flowing continuously Windows waits until it has a full
buffer. So here's another annoying flag in the winhandl API, which
restricts reads to length 1 so that serial output shows up as it
appears.

(I tried this yesterday, but without the OVERLAPPED fix in r6826 it
behaved very erratically. It now seems solid.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6827 cda61777-01e9-0310-a592-d414129be87e

Apparently it helps for an OVERLAPPED structure to contain a valid
event handle. This seems to have fixed _some_, but not all, of the
curious data loss issues in the Windows serial backend.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6826 cda61777-01e9-0310-a592-d414129be87e

Minor tweaks to -nc:
 - log host:port in event log
 - add -nc to Plink usage message

git-svn-id: svn://svn.tartarus.org/sgt/putty@6825 cda61777-01e9-0310-a592-d414129be87e

Missed a couple of instances of cfg_launchable().

git-svn-id: svn://svn.tartarus.org/sgt/putty@6824 cda61777-01e9-0310-a592-d414129be87e

New command-line option in Plink (and PuTTY, though it's less useful
there): `plink host -nc host2:port' causes the SSH connection's main
channel to be replaced with a direct-tcpip connection to the
specified destination. This feature is mainly designed for use as a
local proxy: setting your local proxy command to `plink %proxyhost
-nc %host:%port' lets you tunnel SSH over SSH with a minimum of
fuss. Works on all platforms.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6823 cda61777-01e9-0310-a592-d414129be87e

Serial back end for Unix. Due to hardware limitations (no Linux box
I own has both an X display and a working serial port) I have been
unable to give this the full testing it deserves; I've managed to
demonstrate the basic functionality of Unix Plink talking to a
serial port, but I haven't been able to test the GTK front end. I
have no reason to think it will fail, but I'll be more comfortable
once somebody has actually tested it.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6822 cda61777-01e9-0310-a592-d414129be87e

... and here's the rest of r6820. Ahem.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6821 cda61777-01e9-0310-a592-d414129be87e

Because not all OSes will support the same set of serial port
options, here's a slight change to the API of ser_setup_config_box()
to make it filter its parity and flow control options using
platform-supplied bit masks.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6820 cda61777-01e9-0310-a592-d414129be87e

Fix small event log bug.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6819 cda61777-01e9-0310-a592-d414129be87e

Forgot to initialise serial->bufsize to zero.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6818 cda61777-01e9-0310-a592-d414129be87e

Fix line endings (svn:eol-style properties and actual CRs).

git-svn-id: svn://svn.tartarus.org/sgt/putty@6817 cda61777-01e9-0310-a592-d414129be87e

Support for Windows PuTTY connecting straight to a local serial port
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'.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6815 cda61777-01e9-0310-a592-d414129be87e

Now that Local proxy type exists on both Unix and Windows, document it and
associated stuff.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6814 cda61777-01e9-0310-a592-d414129be87e

Grow some nasty warts on the side of winhandl.c, in preparation for
a serial port backend:
 - In order to do simultaneous reading and writing on the same
   HANDLE, you must enable overlapped access and pass an OVERLAPPED
   structure to each ReadFile and WriteFile call. This would make
   sense if it were an optional thing I could do if I wanted to do
   the reading and writing in the same thread, but making it
   mandatory even if I'm doing them in _different_ threads is just
   annoying and arbitrary.
 - Serial ports occasionally return length 0 from ReadFile, for no
   particularly good reason. Fortunately serial ports also don't
   have a real EOF condition to speak of, so ignoring EOFs is
   actually a viable response in spite of sounding utterly gross.
Hence, handle_{input,output}_new() now accept a flags parameter,
which includes a flag to enable the OVERLAPPED bureaucracy and a
flag to cause EOFs to be ignored on input handles. The current
clients of winhandl.c do not use either of these.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6813 cda61777-01e9-0310-a592-d414129be87e

Remove spurious #include.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6812 cda61777-01e9-0310-a592-d414129be87e

Call console_provide_logctx _before_ initialising the back end, so
that logevent() will go to stderr in -v mode even during the back
end init function.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6811 cda61777-01e9-0310-a592-d414129be87e

The `socket' function in the backends is only ever checked to see if
it's NULL. Since we already have one back end (uxpty) which doesn't
in fact talk to a network socket, and may well have more soon, I'm
replacing this TCP/IP-centric function with a nice neutral
`connected' function returning a boolean. Nothing else about its
semantics has currently changed.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6810 cda61777-01e9-0310-a592-d414129be87e

It's critically important that the local proxy process should not
inherit _our_ ends of its I/O pipes! Otherwise, closing our copy of
those handles does not cause it to see EOF on its stdin, because
it's holding the pipe open itself.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6808 cda61777-01e9-0310-a592-d414129be87e

We _can_ have handle_throttle() called on defunct handles after all,
so it should just do nothing rather than failing an assertion.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6807 cda61777-01e9-0310-a592-d414129be87e

ProxyCommand support for Windows, using the new winhandl.c API.
Seems a bit clunky when I actually try to use it - not sure why -
but I think all the actual functionality is there.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6806 cda61777-01e9-0310-a592-d414129be87e

Another bug fix: always set the busy flag when telling a subthread
to do something, otherwise handle_get_events will forget to tell the
front end to check for that subthread finishing. This applies even
when we're only setting `busy' to tell the subthread to terminate!

git-svn-id: svn://svn.tartarus.org/sgt/putty@6805 cda61777-01e9-0310-a592-d414129be87e

Cleanups to reduce dependency on Windows SFTP tools always having a
real network socket.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6804 cda61777-01e9-0310-a592-d414129be87e

On cleanup, PSCP and PSFTP should explicitly check that the back end
is still running rather than relying on ssh_sftp_loop_iteration() to
return a bogus value.

git-svn-id: svn://svn.tartarus.org/sgt/putty@6803 cda61777-01e9-0310-a592-d414129be87e