us select our own mouse pointer fg and bg for standard pointers?
It's ludicrous that we can only do it for pixmap-derived ones. :-( )
[originally from svn r2035]
uninitialised. This problem only showed up with mingw builds of PuTTY
(maybe MSVCRT is more forgiving with malloc initialisation than CRTDLL?).
The 'error' field was causing me most trouble, and I think the other two
were necessary too before things started working.
Note however that I don't fully understand the code, and that there are
more uninitialised fields in the structure.
[originally from svn r2029]
pick up the font's real width and height. This means I now _can't_
use my font of choice until I implement some command-line options; I
wonder what feature will appear next :-)
[originally from svn r2027]
loopback interface; pterm now runs $SHELL and gives every impression
of being not a bad terminal emulator. I'm quite pleased with that. :-)
[originally from svn r2015]
would have been better to abstract the general key-handling rules
away from the platform-specific keysyms rather than doing clone-
and-hack as I've done - but it'll serve for now. Now all I need is a
real pty back end and pterm should be a just-about-usable prototype.
[originally from svn r2013]
This means pterm actually _looks_ like the PuTTY terminal emulator
engine, instead of merely giving evidence to the expert eye that
said engine is hidden in there somewhere :-)
[originally from svn r2011]
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]
