- remove a couple of "fixed in 0.52" (or before) type questions
- mention Mac OS X port that someone was working on
- add a missing {Question}
[originally from svn r3997]
can do it by hand, I've converted the man page set from Unix PuTTY
into Halibut format, and enhanced the Makefile so it will build
them. At some future point this will also allow me to include the
man pages as an appendix in the main manual (once I _have_ a main
manual for Unix PuTTY).
[originally from svn r3966]
problem and verified the fix on Win2K with the US-International keyboard layout.
(Closes: `win-dead-keys')
<20040323143836.GA40414@rcs.urz.tu-dresden.de>
[originally from svn r3963]
scrollback and the terminal to the clipboard, rather than just the
content before the cursor. Should fix copyall-to-cursor.
[originally from svn r3929]
trying to _follow_ it for the first time :-) And also due to the
fact that it now needs to mention the Unix source tarball as well.
[originally from svn r3853]
It appears that this is because Visual C's sscanf works by first
calling strlen to get the length of the string, so that its internal
read-character routine can be sure of never overrunning the buffer.
Quite why the internal read-char routine can't detect \0 _itself_
rather than having to have it found for it in advance I have no
idea. Sigh.
[originally from svn r3844]
will validate an md5sums manifest and if all md5sums match will use
a version number provided in a file. This should allow me to produce
a Unix release source archive with the property that when unpacked
and built it will produce binaries advertising themselves as
`Release X.YZ', but as soon as the user starts fiddling with the
sources it will revert to `Unidentified build' (though of course the
user can still _explicitly_ ask for a release tag, and in fact this
will override the default if any default is specified).
[originally from svn r3818]
keys. This _appears_ to be due to me computing the byte count of the
key by dividing the bit count by 8 and rounding _down_ rather than
up. Therefore, I can't see how this code could ever have worked on
any SSH2 RSA key whose length was not a multiple of 8 bits; and
therefore I'm staggered that we haven't noticed it before! OpenSSH's
keygen appears to be scrupulous about ensuring the returned key
length is exactly what you asked for rather than one bit less, but
even so I'm astonished that _all_ keygen implementations for servers
we've ever interoperated with have avoided tripping this bug...
[originally from svn r3815]
