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.
[originally from svn r6822]
rather than relying on the user to edit the Makefile. Makefile.gtk
still works as well as it ever did, but now we get a Makefile.in alongside
it. mkunxarc.sh now relies on autoconf and friends to build the configure
script for the Unix source distribution.
[originally from svn r5673]
in question vary per OS: on Windows the problem is that WM_TIMER
sometimes goes off too early, so that GetTickCount() is right and
the callback time is wrong, whereas on Unix the problem is that my
GETTICKCOUNT implementation comes from the system clock which means
it can change suddenly and non-monotonically if the sysadmin is
messing about (meaning that the timing of callbacks from GTK or
select timeouts is _more_ likely to be right than GETTICKCOUNT).
This checkin provides band-aid workarounds for both problems, which
aren't pretty but ought to at least prevent catastrophic assertion
failure.
[originally from svn r5556]
* Make sk_getxdmdata() return an arbitrary string rather than two integers.
This better matches the spec, even if the current version always returns
six bytes
* On Unix, for PF_UNIX sockets, return a counter rather than a constant along
with the PID. This should allow multiple clients to connect within one
second, and is what Xlib does.
* On Unix, interpret AF_INET6 addresses like Xlib does, returning the
embedded IPv4 address for v4-mapped addresses, and six bytes of zeroes
otherwise. The latter is silly, but if I'm going to do anything more sane
I need to check that X servers won't reject it.
[originally from svn r5219]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
comment when I unblock it in pty.c to reflect reality. Also I've
moved block_signal() out of pterm.c into signal.c, so I can
conveniently use it for unblocking SIGCHLD rather than having to
reinvent it in pty.c.
[originally from svn r5006]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
feels strongly that it should be easy to make _all_ your
applications work in UTF-8 mode, without having to remember a switch
for each one. Every application should simply note a UTF-8 locale
setting and switch into UTF-8 mode automatically.
Therefore, for the Unix port only, there's now a checkbox, enabled
by default, which causes the drop-down Translation box to be
overridden if the locale indicates UTF-8. Anyone who doesn't like
this, or doesn't like MGK, is welcome to turn it straight back off.
I'm not _completely_ convinced by MGK's argument myself; for
xterm/pterm to do _useful_ UTF-8 you also need to specify a decently
Unicode-capable font, and there's no way _that_ can be automagically
done on noticing a locale setting. But it's a de facto standard
(i.e. xterm does it :-) so I might as well at least be _able_ to
support it.
[originally from svn r4648]
... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be
somewhat harder; there's more Windows code interleaved than there
was in PSFTP.)
[originally from svn r3419]
ptrs and ints of different size and -Werror makes this serious).
The GTK bits are done by Colin's patch to use GINT_TO_POINTER
(thanks); the uxnet bits are done by cleaning up the rest of the
code. In particular, network.h now typedefs `OSSocket' to be a type
capable of holding whatever the OS's socket data type is that
underlies our socket abstraction. Individual platforms can make this
typedef themselves if they define OSSOCKET_DEFINED to prevent
network.h redoing it; so the Unix OSSocket is now int. Default is
still void *, so other platforms should be unaffected.
[originally from svn r3171]
Euro-supporting font with a Euro-enabled X key map will now actually
generate a Euro character rather than shrugging and doing nothing.
[originally from svn r3151]
had to move another of its values out into wincfg.c - paradoxically,
this was the `font has X encoding' option! (Because the Unix font
handling code expects to be able to tell for _itself_ whether it has
a font with X-encoded line drawing glyphs.)
[originally from svn r3145]
contents, and doesn't automatically maintain scroll position at the
bottom when new entries are added while the list is open, but it's a
start.
[originally from svn r3087]
This menu is not yet fully populated, but it has an About box (yet
another licence location :-/ ) and supports the new configurable
specials menu (thus making Unix PuTTY do one tiny thing which
OpenSSH-in-a-pterm can't :-).
[originally from svn r3062]
think it's now actually usable as a day-to-day SSH client, even if
things like the Event Log are still missing. So I call that a decent
lunch hour's work :-)
[originally from svn r3034]
being able to be a PuTTY as well as a pterm. In the process I've
also moved icky things like actually reading from the pty fd and
printing the `terminated on signal' messages into pty.c where they
obviously should have been in the first place. Also there's been one
interesting repercussion in the terminal code: terminal.c's
from_backend now calls term_out() directly rather than expecting the
front end to call it afterwards. This has had the entertaining side
effect of fixing a Windows-specific bug whereby activity in a port
forwarding through a PuTTY with a blinking cursor caused the cursor
to blink to ON (!!!!). So, a surprisingly far-reaching checkin as it
turns out...
[originally from svn r3017]
functionality that deal with selectable fds in general. The idea is
that pty.c will stop passing its fd straight to pterm.c and hand it
to this module instead, and pterm.c will start requesting a general
list of fds from this module rather than expecting a single one from
pty.c, with the ultimate aim of pterm.c being able to form the basis
of a Unix PuTTY as well as pterm proper.
[originally from svn r3015]
Unix-specific config items; moved a stray Windows-specific config
item (scrollbar-in-fullscreen) out into wincfg.c to stop it
appearing on Unix; continued updates to gtkdlg.c. I now believe the
GTK config box looks basically correct (modulo minor cosmetic issues
and keyboard accelerators). Next step, add the event handling so
it's actually functional.
[originally from svn r2933]
(list boxes are particularly conspicuously absent), it has no event
handling at all, and it isn't in any way integrated into pterm - you
have to build it specially using the test stubs in gtkdlg.c. But
what there is so far seems to work plausibly well, so it's a start.
Rather than browbeat the existing GTK container/layout widgets into
doing what I wanted, I decided to implement two subclasses of
GtkContainer myself, which implement precisely the layout model
assumed by the config box specification; this has the rather cool
consequence that the box can be resized and will maintain the same
layout at all times that it would have had if initially created at
that size.
[originally from svn r2931]
opaque to all platform-independent modules and only handled within
per-platform code. `Filename' is there because the Mac has a magic
way to store filenames (though currently this checkin doesn't
support it!); `FontSpec' is there so that all the auxiliary stuff
such as font height and charset and so on which is needed under
Windows but not Unix can be kept where it belongs, and so that I can
have a hope in hell of dealing with a font chooser in the forthcoming
cross-platform config box code, and best of all it gets the horrid
font height wart out of settings.c and into the Windows code where
it should be.
The Mac part of this checkin is a bunch of random guesses which will
probably not quite compile, but which look roughly right to me.
Sorry if I screwed it up, Ben :-)
[originally from svn r2765]
holdout static I hadn't noticed; unicode.c had one too; and a large
number of statics that were perfectly OK due to being constants have
been made `const', with assorted `const' repercussions all over the
place. I now declare `remove-statics' to be fixed.
[originally from svn r2594]
just done this the very simple way - bundle all the globals into a
data structure and pass pointers around. One particularly ugly wart
is that wc_to_mb now takes a pointer to this structure as an
argument (optional, may be NULL, and unused in any Unicode layer
that's even marginally less of a mess than the Windows one). I do
need to do this properly at some point, but for now this should just
about be adequate. As usual, the Mac port has not been updated.
[originally from svn r2592]
relevant bits of it passed in to init_ucs(). (Actually I pass in all
of it in the Windows version, since it's a bit hairy in there.)
[originally from svn r2565]
we're going to be a security program, we can at least make a token
effort to use the most secure local X auth available! And I'm still
half-tempted to see if I can support it for remote X servers too...
[originally from svn r2537]
font whose encoding comes up as CS_NONE - but this is also true for
iso10646-1 fonts, since libcharset doesn't support wide-character
encodings! Hence UTF-8 cut and paste was enabled in ordinary modes,
but disabled in UTF-8 mode, which was a bit embarrassing. Now we
have a dedicated flag variable indicating direct-to-font mode.
[originally from svn r2425]
know what that encoding actually is, we can do our best to support
additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using
the available characters; if we don't, we fall back to a mode where
we disable all Unicode cut-and-paste and assume any Unicode
character is undisplayable.
[originally from svn r2413]
does UTF-8 copy and paste (falling back to normal strings if
necessary), it understands X font encodings and translates things
accordingly so that if you have a Unicode font you can ask for
virtually any single-byte encoding and get it (Mac-Roman pterm,
anyone?), and so on. There's work left to be done (wide fonts for
CJK spring to mind), but I reckon this is a pretty good start.
[originally from svn r2395]
doesn't yet use the SSH agent, no way to specify arbitrary config
options, no manpage yet, couple of other fiddly things need doing,
but it makes SSH connections and doesn't fall over horribly so I say
it's a good start. Now to run it under valgrind...
[originally from svn r2165]
source files in which it's no longer required (it was previously
required in anything that included <putty.h>, but not any more).
Also moved a couple of stray bits of exposed WinSock back into
winnet.c (getservbyname from ssh.c and AF_INET from proxy.c).
[originally from svn r2160]
absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
lpage_send out into the line discipline, making them _clients_ of
the Unicode layer rather than part of it. This means they can access
ldisc->term, which in turn means I've been able to remove the
temporary global variable `term'. We're slowly getting there.
[originally from svn r2143]
