parts of the versioning code which might not like them.
As a result of this checkin, bob builds from modified SVN working
copies will still announce themselves as revision nnnnM in the
textual version strings, but their binary version in the Windows
VERSIONINFO will now be 0.0.0.0.
[originally from svn r7231]
base files. (The signatures aren't actually _generated_ by bob, of
course, but the redirects are harmless in their absence.)
[originally from svn r7228]
Saves me having to remember all the fiddly gpg arguments every time.
Should be usable for both releases (with manual passphrase input)
and snapshots (run automatically).
[originally from svn r7227]
and custom svn builds should now have appropriately named Unix
source archives and installer binaries, plus .htaccess files
providing redirects to them from totally standard filenames. I
_think_ this now makes it feasible to switch the nightly builds to
using bob.
[originally from svn r7226]
a fourth class of PuTTY version tags in addition to release,
snapshot and unidentified: we now have `Custom build r1234',
indicating a build made from that SVN revision in a context other
than that of a dated snapshot. The build script generates these when
it doesn't know what else to do; `unidentified builds' will now only
occur when you run nmake from the command line.
Also, the build script now generates sensible version data in the
installer to match this. So I _think_ we should now be set to use
bob to generate installer builds of the nightly snapshots, although
of course I'll have to wait until tomorrow to test one.
[originally from svn r7211]
appears to merely fix the background colour (arranging for it to
have transparency rather than being on some kind of default grey
background), but it turns out to also fix the strange blurry
behaviour I see in the GNOME Taskbar, for no very obvious reason.
[originally from svn r7186]
comes last on the compiler command line. This makes it easier to
override the normal compile options (since conflicting command-line
options usually follow a last-wins policy) in order to compile (for
example) the Unix version -g -O0.
[originally from svn r7170]
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]
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.)
[originally from svn r7132]
[r6797 == 291533d3f9]
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.
[originally from svn r7125]
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".
[originally from svn r7121]
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?
[originally from svn r7117]
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.)
[originally from svn r7107]
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.)
[originally from svn r7098]
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...)
[originally from svn r7087]
[r7082 == dbbd6eb5ec]
[this svn revision also touched putty-wishlist]
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.)
[originally from svn r7084]
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.
[originally from svn r7082]
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.)
[originally from svn r7077]
[r7071 == 57a763b0ec]
