The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
beginning of a Unix port. It's nowhere near done, and currently it
won't even compile on Unix. But this represents the start of the
process of separating out platform-specific code, and also contains
the mkfiles.pl changes required to support a Unix makefile and a
non-flat source tree.
[originally from svn r1993]
longer just sit there like a lemon if we can't find the channel in
question, we bomb out and complain. With any luck, remaining
problems of this type should be easier to catch under this policy.
[originally from svn r1962]
receiving of CLOSE and CLOSE_CONFIRMATION separately rather than
taking short cuts. I believe ssh-1.2.33 sending CLOSE_CONFIRMATION
before CLOSE was causing the remaining incidences of bug
`nonexistent-channel'. (ssh-1.2.33 appears to have unilaterally
decreed that CLOSE and CLOSE_CONFIRMATION are respectively renamed
INPUT_EOF and OUTPUT_CLOSING, hence there is no longer an ordering
constraint on them. Bah.)
[originally from svn r1961]
Bump username storage from 32 to 100 chars. Also replaced a couple of magic
numbers with sizeof in ssh.c.
I don't believe this is going to startle any of the protocols PuTTY talks.
[originally from svn r1952]
Updated manual to reflect reality (e.g. usage messages, '-p port' not actually
implemented, sprinkle references to '-i keyfile').
(I've put "Release 0.53" in the messages; let's hope this doesn't cause a
flood of "where is 0.53?" email.)
I don't guarantee that the result is entirely sane and sensible in all
respects, but it is at least consistent.
[originally from svn r1951]
finally isolated the _important_ difference between Romano Trampus's
working printing.c and my failing one: he ignores the error return
from the first exploratory how-big-does-my-buffer-need-to-be call to
EnumPrinters(), because not having enough buffer space counts as an
error condition. Hence I am officially a klutz, but this should now
work. (Also reverted ENUM_LEVEL to 1, again, because that seems to
be the choice of people whose code works.)
[originally from svn r1915]
versions 2.0.*, and causing the shared secret not to be included in
key derivation hashes. (This doesn't quite cause a blatant security
hole because the session ID - _derived_ from the shared secret - is
still included.)
[originally from svn r1853]
subsequent packet-receiver code would fail to notice anything was
wrong and segfault. Since this is clearly a silly packet length
anyway, we now explicitly reject it as a daft encryption error.
[originally from svn r1852]
containing more than one prompt instead of less than one, and also
correctly enables echo on prompts that the server requests it for.
In the process I've moved the whole username/password input routine
out into its own function, where it's called independently of which
SSH protocol we're using, so this should even have _saved_ code
size. Rock!
[originally from svn r1830]
specifying both PRINTER_ENUM_LOCAL and PRINTER_ENUM_CONNECTIONS
catches more printers in some circumstances than two EnumPrinters()
calls each specifying just one of them. We'll try it for a bit; if
it goes wrong I might have to put back the two original calls as
well and sort out some means of removing duplicate printers from the
list.
[originally from svn r1829]
uncompressed block at the end of each compressed packet) which we
were embarrassingly unable to deal with because we assumed every
uncompressed block contained at least one byte. Particularly silly
because I _knew_ about the existence of sync flush when I coded this
module. Arrgh. Still, now fixed.
[originally from svn r1824]
it for preserving file attributes in PSCP! Ah well; looks as if
that's one where we'll have to agree to differ with OpenSSH.
[originally from svn r1821]
Simon Tatham
Jacob Nevins