remember changes in COE so it knows whether to print a message, and
(b) once the session has already ended, Warn On Close should shut up.
[originally from svn r3102]
`Special Command' menu, in which any backend can place its own list
of magical things the user might want to ask the backend to do. In
particular I've implemented the recently proposed "break" extension
in SSH2 using this mechanism.
NB this checkin slightly breaks the Mac build, since it needs to
provide at least a stub form of update_specials_menu().
[originally from svn r3054]
practically trivial to put all the pieces together and create a
working prototype of Unix PuTTY! It's missing a lot of things -
notably GUI request boxes for host keys and logfiles and so forth,
the Event Log, mid-session reconfiguration, session loading and
saving, sensible population of the character sets drop-down list and
probably other fiddly little things too - but it will put up a
config box and then create a GUI window containing an SSH connection
to the host you specified, so it's _basically_ there. Woo!
[originally from svn r3020]
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]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
and have a function to pass in a new one. (Well, actually several
back ends don't actually bother to do this because they need nothing
out of Config after the initial setup phase, but they could if they
wanted to.)
[originally from svn r2561]
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]
now compiles and runs again after the major destabilisation.
Unfortunately it wasn't feasible to actually encapsulate all of the
pty backend's data, since the utmp helper and the need to fork and
drop privileges before doing anything else at all rather confuses
matters. So the data handle passed around to the pty backend is a
null pointer, and the pty backend is just as global-ridden as it
always has been. Shame, but such is life.
[originally from svn r2128]
only on clean exit, which is a departure from most xterm-alikes but
Ian reckons people will love me for it. If this turns out to be
wrong, we can always change the default for Unix.
[originally from svn r2120]
terminal.c was apparently relying on implicit initialisation to
zero, and also I've removed the backends' dependency on terminal.h
by having terminal sizes explicitly passed in to back->size().
[originally from svn r2117]
all the global and function-static variables out of terminal.c into
a dynamically allocated data structure. Note that this does not yet
confer the ability to run more than one of them in the same process,
because other things (the line discipline, the back end) are still
global, and also in particular the address of the dynamically
allocated terminal-data structure is held in a global variable
`term'. But what I've got here represents a reasonable stopping
point at which to check things in. In _theory_ this should all still
work happily, on both Unix and Windows. In practice, who knows?
[originally from svn r2115]
set[ug]id. All privs-requiring pty operations are done at the very
start of the run, then privs are dropped before initialising GTK.
Utmp is handled by forking a still-privileged subprocess at this
point, and later asking it (through a pipe) to stamp utmp. The
subprocess cleans up utmp on exit, which has the additional
advantage that if the main pterm process suffers some sort of
unexpected termination (up to and including SIGKILL) the subprocess
can still mop up utmp.
[originally from svn r2082]
login shell or not. Also moved these new pieces of configuration
into the Config structure, though they won't stay there forever
since they will need to be moved out into platform-dependent config.
[originally from svn r2060]
terminals right. Irritatingly this was working when run from another
[xsp]term but not when run from my GNOME panel. I think it's now
more robust.
[originally from svn r2041]
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]
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]
