nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 01:48:00 +00:00
Code Issues Projects Releases Wiki Activity
6f0adb243a
putty-source/windows/window.c

5811 lines
192 KiB
C
Raw Normal View History

Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 18:26:03 +00:00
/*
* window.c - the PuTTY(tel) main program, which runs a PuTTY terminal
* emulator and backend in a window.
*/
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
#include <stdio.h>
#include <stdlib.h>
Cleanups to remove warnings for GNU/mingw32 compilation [originally from svn r325]
1999-11-22 10:07:24 +00:00
#include <ctype.h>
Robert de Bath's big patch: - cope with strange WinSock wrappers not supporting SIOCATMARK - define yet more terminal compatibility modes - support UK-ASCII (just like US-ASCII but # is a sterling sign) - support connection keepalives at a configurable interval [originally from svn r692]
2000-10-09 12:53:32 +00:00
#include <time.h>
Start using notify_remote_exit() in the Windows front end, in place of the previous ad-hockery which depended on the return value from select_result() and hence which will not adapt sensibly to a world in which the primary session is something local rather than a network connection. [originally from svn r6802]
2006-08-26 10:04:46 +00:00
#include <limits.h>
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
#include <assert.h>
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#ifdef __WINE__
#define NO_MULTIMON /* winelib doesn't have this */
#endif
Update WINVER to 0x500 to avoid build failures from Jacob's FlashWindow changes. Also fiddle with the <multimon.h> include, which was subtly broken in turn by that. [originally from svn r7120]
2007-01-16 21:32:02 +00:00
#ifndef NO_MULTIMON
#define COMPILE_MULTIMON_STUBS
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define PUTTY_DO_GLOBALS /* actually _define_ globals */
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
#include "putty.h"
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
#include "terminal.h"
Rationalised host key storage. Also started code reorg: persistent-state routines have been moved out into a replaceable module winstore.c. [originally from svn r639]
2000-09-27 15:21:04 +00:00
#include "storage.h"
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
#include "win_res.h"
Make our process's ACL more restrictive. By default Windows processes have wide open ACLs which allow interference by other processes running as the same user. Adjust our ACL to make this a bit harder. Because it's useful to protect PuTTYtel as well, carve winsecur.c into advapi functions and wincapi.c for crypt32 functions.
2015-11-24 22:02:24 +00:00
#include "winsecur.h"
Implement true-colour in write_clip for Windows This allows text copied from PuTTY to a rich-text program to retain the true-colour attribute.
2017-06-13 04:55:57 +00:00
#include "tree234.h"
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
#ifndef NO_MULTIMON
#include <multimon.h>
#endif
#include <imm.h>
#include <commctrl.h>
#include <richedit.h>
#include <mmsystem.h>
Simon has reminded me _why_ menu identifiers were spaced every sixteen, so let's add a comment so that we don't forget again. Source: <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardaccelerators/keyboardacceleratorreference/keyboardacceleratormessages/wm_syscommand.asp> [originally from svn r4732]
2004-11-02 22:30:24 +00:00
/* From MSDN: In the WM_SYSCOMMAND message, the four low-order bits of
* wParam are used by Windows, and should be masked off, so we shouldn't
* attempt to store information in them. Hence all these identifiers have
Go back to using intervals of 16 for the saved session identifiers for the system menu, but expand from 256 entries to 1024 as there seems to be plenty of space. Also remove a couple of unused IDM_* constants. [originally from svn r4733]
2004-11-02 23:06:20 +00:00
* the low 4 bits clear. Also, identifiers should < 0xF000. */
Simon has reminded me _why_ menu identifiers were spaced every sixteen, so let's add a comment so that we don't forget again. Source: <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardaccelerators/keyboardacceleratorreference/keyboardacceleratormessages/wm_syscommand.asp> [originally from svn r4732]
2004-11-02 22:30:24 +00:00
Stop putting meaning in bottom four bits of WM_SYSCOMMAND wParam [originally from svn r265]
1999-10-28 16:29:06 +00:00
#define IDM_SHOWLOG 0x0010
#define IDM_NEWSESS 0x0020
#define IDM_DUPSESS 0x0030
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
#define IDM_RESTART 0x0040
#define IDM_RECONF 0x0050
#define IDM_CLRSB 0x0060
#define IDM_RESET 0x0070
Integrate PuTTY and its help file. Now that's what I call a good lunchtime's work :-) [originally from svn r1458]
2001-12-06 13:28:02 +00:00
#define IDM_HELP 0x0140
#define IDM_ABOUT 0x0150
#define IDM_SAVEDSESS 0x0160
#define IDM_COPYALL 0x0170
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define IDM_FULLSCREEN 0x0180
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#define IDM_COPY 0x0190
#define IDM_PASTE 0x01A0
Users of Virtual Dimension are reporting that the "Close" menu item and button tend to get disabled on login. After a suggestion by "Tkil", change the way we handle the specials menu to be robust against the window menu being externally modified. [originally from svn r6546] [this svn revision also touched putty-wishlist]
2006-02-09 23:06:57 +00:00
#define IDM_SPECIALSEP 0x0200
Stop putting meaning in bottom four bits of WM_SYSCOMMAND wParam [originally from svn r265]
1999-10-28 16:29:06 +00:00
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
#define IDM_SPECIAL_MIN 0x0400
#define IDM_SPECIAL_MAX 0x0800
Stop putting meaning in bottom four bits of WM_SYSCOMMAND wParam [originally from svn r265]
1999-10-28 16:29:06 +00:00
#define IDM_SAVED_MIN 0x1000
Go back to using intervals of 16 for the saved session identifiers for the system menu, but expand from 256 entries to 1024 as there seems to be plenty of space. Also remove a couple of unused IDM_* constants. [originally from svn r4733]
2004-11-02 23:06:20 +00:00
#define IDM_SAVED_MAX 0x5000
#define MENU_SAVED_STEP 16
Since neither I nor Owen know why the IDM_ values for the saved-sessions submenu were going up in steps of 16, I've changed to steps of 1, thus increasing the possible number of sessions from ~256 to 4096, since a recent report seemed to indicate that the previous limit might not be enough for someone (!) I can't find any documentation that puts an upper limit on the number of menu items, and it seems to work on Win98, which is where I'd expect it to break if anywhere. Also a number of other tweaks to this code. [originally from svn r4731]
2004-11-02 17:44:06 +00:00
/* Maximum number of sessions on saved-session submenu */
Go back to using intervals of 16 for the saved session identifiers for the system menu, but expand from 256 entries to 1024 as there seems to be plenty of space. Also remove a couple of unused IDM_* constants. [originally from svn r4733]
2004-11-02 23:06:20 +00:00
#define MENU_SAVED_MAX ((IDM_SAVED_MAX-IDM_SAVED_MIN) / MENU_SAVED_STEP)
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Ben Rudiak-Gould points out that we should be using WM_APP as the base for our app-private window messages, which is considerably higher than the WM_XUSER we arbitrarily chose. (This isn't known to be causing any actual problems. The fix seems not to have obviously broken anything.) [originally from svn r6183] [this svn revision also touched putty-wishlist]
2005-08-10 18:31:24 +00:00
#define WM_IGNORE_CLIP (WM_APP + 2)
#define WM_FULLSCR_ON_MAX (WM_APP + 3)
Remove agent_schedule_callback(). This is another piece of the old 2003 attempt at async agent requests. Nothing ever calls this function (in particular, the new working version of async-agent doesn't need it). Remove it completely, and all its special-window-message implementations too. (If we _were_ still using this function, then it would surely be possible to fold it into the more recently introduced general toplevel-callback system, and get rid of all this single-use special code. But we're not, so removing it completely is even easier.) In particular, this system was the only reason why Windows Plink paid any attention to its message queue. So now I can make it call plain WaitForMultipleObjects instead of MsgWaitForMultipleObjects.
2020-01-30 06:40:21 +00:00
#define WM_GOT_CLIPDATA (WM_APP + 4)
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Chinese support patch from zmx@cdpa.nsysu.edu.tw [originally from svn r740]
2000-10-20 18:36:15 +00:00
/* Needed for Chinese support and apparently not always defined. */
#ifndef VK_PROCESSKEY
#define VK_PROCESSKEY 0xE5
#endif
Replace the definition of WHEEL_DELTA which was removed in rev 1.185 [r1499]. For some reason Borland builds were working perfectly OK without it, but VC builds were failing. *shrug* [originally from svn r1500] [r1499 == d6016149bfd0fe316629ff74e32e06f42948cf87]
2001-12-16 12:11:56 +00:00
/* Mouse wheel support. */
Define WM_MOUSEWHEEL (to 0x20A) if it's not defined by windows.h. [originally from svn r1115]
2001-05-13 11:19:20 +00:00
#ifndef WM_MOUSEWHEEL
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define WM_MOUSEWHEEL 0x020A /* not defined in earlier SDKs */
Replace the definition of WHEEL_DELTA which was removed in rev 1.185 [r1499]. For some reason Borland builds were working perfectly OK without it, but VC builds were failing. *shrug* [originally from svn r1500] [r1499 == d6016149bfd0fe316629ff74e32e06f42948cf87]
2001-12-16 12:11:56 +00:00
#endif
#ifndef WHEEL_DELTA
#define WHEEL_DELTA 120
Define WM_MOUSEWHEEL (to 0x20A) if it's not defined by windows.h. [originally from svn r1115]
2001-05-13 11:19:20 +00:00
#endif
Handle the VK_PACKET virtual key code. This is generated in response to the SendInput() Windows API call, if that in turn is passed an KEYBDINPUT structure with KEYEVENTF_UNICODE set. That method of input generation is used by programs such as 'WinCompose' to send an arbitrary Unicode character as if it had been typed at the keyboard, even if the keyboard doesn't actually provide a key for it. Like VK_PROCESSKEY, this key code is an exception to our usual policy of manually translating keystrokes: we handle it by calling TranslateMessage, to get back the Unicode character it contains as a WM_CHAR message. (If that Unicode character in turn is outside the BMP, it may come back as a pair of WM_CHARs in succession containing UTF-16 surrogates; if so, that's OK, because the new Unicode WM_CHAR handler can cope.)
2015-07-27 19:06:02 +00:00
/* VK_PACKET, used to send Unicode characters in WM_KEYDOWNs */
#ifndef VK_PACKET
#define VK_PACKET 0xE7
#endif
Fix minor breakage on Windows as a result of term_mouse revamp. [originally from svn r2722]
2003-01-25 16:22:49 +00:00
static Mouse_Button translate_button(Mouse_Button button);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
static int TranslateKey(UINT message, WPARAM wParam, LPARAM lParam,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unsigned char *output);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
static void conftopalette(void);
Implement `default-colours' on Windows based loosely on Michael Wardle's patch. [originally from svn r3444]
2003-09-03 20:14:38 +00:00
static void systopalette(void);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static void init_palette(void);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
static void init_fonts(int, int);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
static void another_font(int);
static void deinit_fonts(void);
Set up kbd_codepage at the start of the program, as well as when the input locale changes. With any luck this should sort out the Polish Unicode problems. [originally from svn r1427]
2001-11-29 21:30:59 +00:00
static void set_input_locale(HKL);
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
static void update_savedsess_menu(void);
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
static void init_winfuncs(void);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool is_full_screen(void);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
static void make_full_screen(void);
static void clear_full_screen(void);
static void flip_full_screen(void);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void process_clipdata(HGLOBAL clipdata, bool unicode);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
static void setup_clipboards(Terminal *, Conf *);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Window layout information */
static void reset_window(int);
Wez Furlong's patch to tidy up full-screen mode: make it multi-monitor aware and make the scrollbar separately configurable in and out of full-screen mode. Also (not Wez's patch, this bit) fix the case where the user reconfigures _while_ the window is full-screen, and disables full-screening. (In this case the window should return gracefully to normal, rather than losing all its title bars and getting confused.) [originally from svn r1310]
2001-10-17 21:21:03 +00:00
static int extra_width, extra_height;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static int font_width, font_height;
static bool font_dualwidth, font_varpitch;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
static int offset_width, offset_height;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool was_zoomed = false;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
static int prev_rows, prev_cols;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
static void flash_window(int mode);
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
static void sys_cursor_update(void);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool get_fullscreen_rect(RECT * ss);
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
static int caret_x = -1, caret_y = -1;
Further deglobalisation: settings.c now has a more sensible interface. [originally from svn r2162]
2002-10-30 18:12:46 +00:00
static int kbd_codepage;
Expose the Ldisc structure tag throughout the code. That's one fewer anonymous 'void *' which might be accidentally confused with some other pointer type if I misremember the order of function arguments. While I'm here, I've made its pointer-nature explicit - that is, 'Ldisc' is now a typedef for the structure type itself rather than a pointer to it. A stylistic change only, but it feels more natural to me these days for a thing you're going to eventually pass to a 'free' function.
2018-09-11 14:02:59 +00:00
static Ldisc *ldisc;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
static Backend *backend;
Line discipline module now uses dynamically allocated data. Also fixed one or two other minor problems. [originally from svn r2141]
2002-10-26 10:16:19 +00:00
Deglobalise the Unicode module. Despite all my grand plans, I've 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]
2003-01-14 18:28:23 +00:00
static struct unicode_data ucsdata;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool session_closed;
static bool reconfiguring = false;
Further deglobalisation: settings.c now has a more sensible interface. [originally from svn r2162]
2002-10-30 18:12:46 +00:00
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
static const SessionSpecial *specials = NULL;
Users of Virtual Dimension are reporting that the "Close" menu item and button tend to get disabled on login. After a suggestion by "Tkil", change the way we handle the specials menu to be robust against the window menu being externally modified. [originally from svn r6546] [this svn revision also touched putty-wishlist]
2006-02-09 23:06:57 +00:00
static HMENU specials_menu = NULL;
static int n_specials = 0;
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
#define TIMING_TIMER_ID 1234
static long timing_next_time;
Introduce a context menu which appears on Ctrl+rightclick. This menu contains all the stuff in the System menu except for the standard System menu bits (move, resize, close etc), and also contains `Paste'. [originally from svn r3555]
2003-11-19 20:48:30 +00:00
static struct {
HMENU menu;
} popup_menus[2];
enum { SYSMENU, CTXMENU };
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
static HMENU savedsess_menu;
Introduce a context menu which appears on Ctrl+rightclick. This menu contains all the stuff in the System menu except for the standard System menu bits (move, resize, close etc), and also contains `Paste'. [originally from svn r3555]
2003-11-19 20:48:30 +00:00
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
struct wm_netevent_params {
/* Used to pass data to wm_netevent_callback */
WPARAM wParam;
LPARAM lParam;
};
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
static void conf_cache_data(void);
int cursor_type;
int vtmode;
Having laid all the groundwork, we can now remove the global `cfg' completely from putty.h. It's now static in each of the command-line front ends, shared only between window.c and windlg.c in PuTTY proper (I've tested this by doing #define cfg cfgsillyname in those two files only, and it still links so nobody else is using that symbol!), and part of the `inst' structure in pterm. I think that only leaves the Unicode module as the last stubborn holdout in the anti-global-variables campaign. [originally from svn r2568]
2003-01-12 15:32:31 +00:00
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
static struct sesslist sesslist; /* for saved-session menu */
Further deglobalisation: settings.c now has a more sensible interface. [originally from svn r2162]
2002-10-30 18:12:46 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
#define FONT_NORMAL 0
#define FONT_BOLD 1
#define FONT_UNDERLINE 2
#define FONT_BOLDUND 3
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define FONT_WIDE 0x04
#define FONT_HIGH 0x08
#define FONT_NARROW 0x10
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define FONT_OEM 0x20
#define FONT_OEMBOLD 0x21
#define FONT_OEMUND 0x22
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
#define FONT_OEMBOLDUND 0x23
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define FONT_MAXNO 0x40
#define FONT_SHIFT 5
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
static HFONT fonts[FONT_MAXNO];
Glenn Maynard's other IME fix [originally from svn r1406]
2001-11-24 11:56:24 +00:00
static LOGFONT lfont;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool fontflag[FONT_MAXNO];
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static enum {
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
BOLD_NONE, BOLD_SHADOW, BOLD_FONT
} bold_font_mode;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool bold_colours;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static enum {
UND_LINE, UND_FONT
} und_mode;
static int descent;
Correct number of configurable colours (NCFGCOLOURS) to match reality (leftover from `256-colours', r4917). [originally from svn r5013] [r4917 == e4e10e494b3ee80e68c84882628d84c2791b1344]
2004-12-19 23:15:17 +00:00
#define NCFGCOLOURS 22
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
#define NEXTCOLOURS 240
#define NALLCOLOURS (NCFGCOLOURS + NEXTCOLOURS)
static COLORREF colours[NALLCOLOURS];
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
struct rgb {
int r, g, b;
} colours_rgb[NALLCOLOURS];
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static HPALETTE pal;
static LPLOGPALETTE logpal;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
static RGBTRIPLE defpal[NALLCOLOURS];
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Try to improve the caret usage [originally from svn r651]
2000-09-29 10:32:07 +00:00
static HBITMAP caretbm;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static int dbltime, lasttime, lastact;
static Mouse_Button lastbtn;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
/* this allows xterm-style mouse handling. */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool send_raw_mouse = false;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
static int wheel_accumulator = 0;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static BusyStatus busy_status = BUSY_NOT;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
static char *window_name, *icon_name;
Reset compose state to zero when PuTTY window gains focus [originally from svn r779]
2000-10-30 10:16:32 +00:00
static int compose_state = 0;
A contributor tells me that WM_MOUSEWHEEL is not supported in Win95, and offers a patch that uses RegisterMessage() to acquire the correct dynamic message number to use instead. [originally from svn r1499]
2001-12-15 14:30:58 +00:00
static UINT wm_mousewheel = WM_MOUSEWHEEL;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
#define IS_HIGH_VARSEL(wch1, wch2) \
((wch1) == 0xDB40 && ((wch2) >= 0xDD00 && (wch2) <= 0xDDEF))
#define IS_LOW_VARSEL(wch) \
(((wch) >= 0x180B && (wch) <= 0x180D) || /* MONGOLIAN FREE VARIATION SELECTOR */ \
((wch) >= 0xFE00 && (wch) <= 0xFE0F)) /* VARIATION SELECTOR 1-16 */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool wintw_setup_draw_ctx(TermWin *);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_draw_text(TermWin *, int x, int y, wchar_t *text, int len,
unsigned long attrs, int lattrs, truecolour tc);
static void wintw_draw_cursor(TermWin *, int x, int y, wchar_t *text, int len,
unsigned long attrs, int lattrs, truecolour tc);
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
static void wintw_draw_trust_sigil(TermWin *, int x, int y);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static int wintw_char_width(TermWin *, int uc);
static void wintw_free_draw_ctx(TermWin *);
static void wintw_set_cursor_pos(TermWin *, int x, int y);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_raw_mouse_mode(TermWin *, bool enable);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_set_scrollbar(TermWin *, int total, int start, int page);
static void wintw_bell(TermWin *, int mode);
static void wintw_clip_write(
TermWin *, int clipboard, wchar_t *text, int *attrs,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
truecolour *colours, int len, bool must_deselect);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_clip_request_paste(TermWin *, int clipboard);
static void wintw_refresh(TermWin *);
static void wintw_request_resize(TermWin *, int w, int h);
static void wintw_set_title(TermWin *, const char *title);
static void wintw_set_icon_title(TermWin *, const char *icontitle);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_minimised(TermWin *, bool minimised);
static bool wintw_is_minimised(TermWin *);
static void wintw_set_maximised(TermWin *, bool maximised);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_move(TermWin *, int x, int y);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_zorder(TermWin *, bool top);
static bool wintw_palette_get(TermWin *, int n, int *r, int *g, int *b);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_palette_set(TermWin *, int n, int r, int g, int b);
static void wintw_palette_reset(TermWin *);
static void wintw_get_pos(TermWin *, int *x, int *y);
static void wintw_get_pixels(TermWin *, int *x, int *y);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static const char *wintw_get_title(TermWin *, bool icon);
static bool wintw_is_utf8(TermWin *);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static const TermWinVtable windows_termwin_vt = {
wintw_setup_draw_ctx,
wintw_draw_text,
wintw_draw_cursor,
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
wintw_draw_trust_sigil,
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
wintw_char_width,
wintw_free_draw_ctx,
wintw_set_cursor_pos,
wintw_set_raw_mouse_mode,
wintw_set_scrollbar,
wintw_bell,
wintw_clip_write,
wintw_clip_request_paste,
wintw_refresh,
wintw_request_resize,
wintw_set_title,
wintw_set_icon_title,
wintw_set_minimised,
wintw_is_minimised,
wintw_set_maximised,
wintw_move,
wintw_set_zorder,
wintw_palette_get,
wintw_palette_set,
wintw_palette_reset,
wintw_get_pos,
wintw_get_pixels,
wintw_get_title,
wintw_is_utf8,
};
static TermWin wintw[1];
static HDC wintw_hdc;
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
static HICON trust_icon = INVALID_HANDLE_VALUE;
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool share_can_be_downstream = true;
const bool share_can_be_upstream = true;
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 14:05:41 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool is_utf8(void)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
return ucsdata.line_codepage == CP_UTF8;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
Bug fix: line discipline selection is not enabled until after ssh authentication phase to stop user/password prompts behaving oddly [originally from svn r614]
2000-09-22 13:10:19 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool wintw_is_utf8(TermWin *tw)
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
{
return is_utf8();
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool win_seat_is_utf8(Seat *seat)
Support frontend_is_utf8() in all front ends. Previously only Unix front ends bothered to include it, on the basis that only the pty backend needed it (to set IUTF8 in the pty). We're about to need it everywhere else too.
2016-05-03 07:43:09 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
return is_utf8();
Support frontend_is_utf8() in all front ends. Previously only Unix front ends bothered to include it, on the basis that only the pty backend needed it (to set IUTF8 in the pty). We're about to need it everywhere else too.
2016-05-03 07:43:09 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
char *win_seat_get_ttymode(Seat *seat, const char *mode)
First crack at `terminal-modes' in SSH. PuTTY now sends ERASE by default, Unix Plink sends everything sensible it can find, and it's fully configurable from the GUI. I'm not entirely sure about the precise set of modes that Unix Plink should look at; informed tweaks are welcome. Also the Mac bits are guesses (but trivial). [originally from svn r5653] [this svn revision also touched putty-wishlist]
2005-04-21 13:57:08 +00:00
{
return term_get_ttymode(term, mode);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool win_seat_get_window_pixel_size(Seat *seat, int *x, int *y)
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
win_get_pixels(wintw, x, y);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
}
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
StripCtrlChars *win_seat_stripctrl_new(
Seat *seat, BinarySink *bs_out, SeatInteractionContext sic)
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
{
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
return stripctrl_new_term(bs_out, false, 0, term);
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t win_seat_output(
Seat *seat, bool is_stderr, const void *, size_t);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool win_seat_eof(Seat *seat);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static int win_seat_get_userpass_input(
Seat *seat, prompts_t *p, bufchain *input);
static void win_seat_notify_remote_exit(Seat *seat);
static void win_seat_connection_fatal(Seat *seat, const char *msg);
static void win_seat_update_specials_menu(Seat *seat);
static void win_seat_set_busy_status(Seat *seat, BusyStatus status);
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
static bool win_seat_set_trust_status(Seat *seat, bool trusted);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static const SeatVtable win_seat_vt = {
win_seat_output,
win_seat_eof,
win_seat_get_userpass_input,
win_seat_notify_remote_exit,
win_seat_connection_fatal,
win_seat_update_specials_menu,
win_seat_get_ttymode,
win_seat_set_busy_status,
win_seat_verify_ssh_host_key,
win_seat_confirm_weak_crypto_primitive,
win_seat_confirm_weak_cached_hostkey,
win_seat_is_utf8,
nullseat_echoedit_update,
nullseat_get_x_display,
nullseat_get_windowid,
Change Seat's get_char_cell_size to get_window_pixel_size. That's more directly useful in uxpty.c (which is currently the only actual client of the function), and also matches the data that SSH clients send in "pty-req". Also, it makes that method behave more like the GUI query function get_window_pixels used by terminal.c (with the sole exception that unlike g_w_p it's allowed to return failure), so it becomes even more trivial to implement in the GUI front ends.
2018-10-13 06:37:24 +00:00
win_seat_get_window_pixel_size,
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
win_seat_stripctrl_new,
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
win_seat_set_trust_status,
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
nullseat_verbose_yes,
Remove FLAG_INTERACTIVE. This is simpler than FLAG_VERBOSE: everywhere we need to check it, we have a Seat available, so we can just make it a Seat query method.
2020-01-30 06:40:21 +00:00
nullseat_interactive_yes,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
};
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
static Seat win_seat_impl = { &win_seat_vt };
Seat *const win_seat = &win_seat_impl;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
static void start_backend(void)
{
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
const struct BackendVtable *vt;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
const char *error;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
const char *title;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
char *realhost;
int i;
/*
* Select protocol. This is farmed out into a table in a
* separate file to enable an ssh-free variant.
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
vt = backend_vt_from_proto(conf_get_int(conf, CONF_protocol));
if (!vt) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *str = dupprintf("%s Internal Error", appname);
MessageBox(NULL, "Unsupported protocol number found",
str, MB_OK | MB_ICONEXCLAMATION);
sfree(str);
cleanup_exit(1);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Re-enable trust sigils on Restart Session. In my eagerness to make sure we didn't _accidentally_ change the seat's trust status back to trusted at any point, I forgot to do it on purpose if a second SSH login phase is legitimately run in the same terminal after the first session has ended.
2019-03-20 15:07:32 +00:00
seat_set_trust_status(win_seat, true);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
error = backend_init(vt, win_seat, &backend, logctx, conf,
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
conf_get_str(conf, CONF_host),
conf_get_int(conf, CONF_port),
&realhost,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
conf_get_bool(conf, CONF_tcp_nodelay),
conf_get_bool(conf, CONF_tcp_keepalives));
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
if (error) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *str = dupprintf("%s Error", appname);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *msg = dupprintf("Unable to open connection to\n%s\n%s",
conf_dest(conf), error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MessageBox(NULL, msg, str, MB_ICONERROR | MB_OK);
sfree(str);
sfree(msg);
exit(0);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
window_name = icon_name = NULL;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *title_to_free = NULL;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
title = conf_get_str(conf, CONF_wintitle);
if (!*title) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
title_to_free = dupprintf("%s - %s", realhost, appname);
title = title_to_free;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
sfree(realhost);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
win_set_title(wintw, title);
win_set_icon_title(wintw, title);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
/*
* Connect the terminal to the backend for resize purposes.
*/
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
term_provide_backend(term, backend);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
/*
* Set up a line discipline.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
ldisc = ldisc_create(conf, term, backend, win_seat);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
/*
* Destroy the Restart Session menu item. (This will return
* failure if it's already absent, as it will be the very first
* time we call this function. We ignore that, because as long
* as the menu item ends up not being there, we don't care
* whether it was us who removed it or not!)
*/
for (i = 0; i < lenof(popup_menus); i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DeleteMenu(popup_menus[i].menu, IDM_RESTART, MF_BYCOMMAND);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
session_closed = false;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
sfree(title_to_free);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Revamp Windows's close_session() using toplevel callbacks. Instead of setting a must_close_session flag and having special code in the message loop to check it, we'll schedule the call to close_session using the new top-level callback system. [originally from svn r10021]
2013-08-17 16:06:18 +00:00
static void close_session(void *ignored_context)
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
{
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *newtitle;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
int i;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
session_closed = true;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
newtitle = dupprintf("%s (inactive)", appname);
win_set_icon_title(wintw, newtitle);
win_set_title(wintw, newtitle);
sfree(newtitle);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
if (ldisc) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ldisc_free(ldisc);
ldisc = NULL;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend) {
backend_free(backend);
backend = NULL;
term_provide_backend(term, NULL);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
seat_update_specials_menu(win_seat);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
/*
* Show the Restart Session menu item. Do a precautionary
* delete first to ensure we never end up with more than one.
*/
for (i = 0; i < lenof(popup_menus); i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DeleteMenu(popup_menus[i].menu, IDM_RESTART, MF_BYCOMMAND);
InsertMenu(popup_menus[i].menu, IDM_DUPSESS, MF_BYCOMMAND | MF_ENABLED,
IDM_RESTART, "&Restart Session");
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
}
}
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
extern LogPolicy win_gui_logpolicy[1]; /* defined in windlg.c */
Make cmdline_tooltype a const int. Another ugly mutable global variable gone: now, instead of this variable being defined in cmdline.c and written to by everyone's main(), it's defined _alongside_ everyone's main() as a constant, and cmdline.c just refers to it. A bonus is that now nocmdline.c doesn't have to define it anyway for tools that don't use cmdline.c. But mostly, it didn't need to be mutable, so better for it not to be. While I'm at it, I've also fiddled with the bit flags that go in it, to define their values automatically using a list macro instead of manually specifying each one to be a different power of 2.
2020-01-30 06:40:22 +00:00
const unsigned cmdline_tooltype =
TOOLTYPE_HOST_ARG |
TOOLTYPE_PORT_ARG |
TOOLTYPE_NO_VERBOSE_OPTION;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
int WINAPI WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int show)
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
MSG msg;
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
HRESULT hr;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
int guess_width, guess_height;
Lock down the search path for Windows DLL loading. At least on systems providing SetDefaultDllDirectories, this should stop PuTTY from being willing to load DLLs from its containing directory - which makes no difference when it's been properly installed (in which case the application dir contains no DLLs anyway), but does if it's being run from somewhere uncontrolled like a browser downloads directory. Preliminary testing suggests that this shouldn't break any existing deliberate use of DLLs, including GSSAPI providers.
2016-07-18 19:02:32 +00:00
dll_hijacking_protection();
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
hinst = inst;
Add context help to a couple of message boxes. Unfortunately the ones I wanted to get to -- "software caused connection abort" and friends -- are going to be more involved (probably requiring some cross-platform notion of help contexts), and these ones hardly seem worth the effort. Still, I've done it now. Side-effect: Pageant now uses the same `hinst' and `hwnd' globals as everything else. Tested basic functionality. [originally from svn r5417]
2005-03-01 01:16:57 +00:00
hwnd = NULL;
John Sullivan's sizetip patch - experimental [originally from svn r269]
1999-11-03 14:08:26 +00:00
Created a shiny new abstraction for the socket handling. Has many advantages: - protocol modules can call sk_write() without having to worry about writes blocking, because blocking writes are handled in the abstraction layer and retried later. - `Lost connection while sending' is a thing of the past. - <winsock.h> is no longer needed in most modules, because "putty.h" doesn't have to declare `SOCKET' variables any more, only the abstracted `Socket' type. - select()-equivalent between multiple sockets will now be handled sensibly, which opens the way for things like SSH port forwarding. [originally from svn r744]
2000-10-23 10:32:37 +00:00
sk_init();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Load comctl32.dll (for drag lists) at run time. This too is not in the list of known DLLs on Windows 10. I don't know of any actual viable hijacking attack based on it, which according to my reading of MSDN (specifically, a rather vague hint in https://msdn.microsoft.com/library/ff919712) _may_ be because we mention the common controls assembly in our application manifest; but better safe than sorry. Now the entire list of remaining DLLs that PuTTY links against at load time is a subset of the Win10 known DLLs list, so that _should_ mean that everything we load before we've deployed our own defence (SetDefaultDllDirectories) is defended against for us by Windows itself.
2017-03-13 21:42:44 +00:00
init_common_controls();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
SetCurrentProcessExplicitAppUserModelID to fix jumplist/removable media bug The algorithm Windows uses to generate AppUserModelIDs "hangs on" to removable media (CDs/DVDs) if PuTTY is launched with a CD/DVD in a drive. Set the AppUserModelID explicitly to avoid using this algorithm.
2016-08-29 15:55:42 +00:00
/* Set Explicit App User Model Id so that jump lists don't cause
PuTTY to hang on to removable media. */
set_explicit_app_user_model_id();
Implement a much more visually appealing, but much more internally grotty, hack to get around Explorer maximising the config box. [originally from svn r707]
2000-10-12 12:56:33 +00:00
/* Ensure a Maximize setting in Explorer doesn't maximise the
* config box. */
defuse_showwindow();
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
init_winver();
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
A contributor tells me that WM_MOUSEWHEEL is not supported in Win95, and offers a patch that uses RegisterMessage() to acquire the correct dynamic message number to use instead. [originally from svn r1499]
2001-12-15 14:30:58 +00:00
/*
* If we're running a version of Windows that doesn't support
* WM_MOUSEWHEEL, find out what message number we should be
* using instead.
*/
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
if (osMajorVersion < 4 ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(osMajorVersion == 4 && osPlatformId != VER_PLATFORM_WIN32_NT))
wm_mousewheel = RegisterWindowMessage("MSWHEEL_ROLLMSG");
A contributor tells me that WM_MOUSEWHEEL is not supported in Win95, and offers a patch that uses RegisterMessage() to acquire the correct dynamic message number to use instead. [originally from svn r1499]
2001-12-15 14:30:58 +00:00
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
init_help();
Integrate PuTTY and its help file. Now that's what I call a good lunchtime's work :-) [originally from svn r1458]
2001-12-06 13:28:02 +00:00
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
init_winfuncs();
At least, I have the technology to fix `beepind-win2k'. Tested on Win98, Win2K, and WinXP. [originally from svn r7119] [this svn revision also touched putty-wishlist]
2007-01-16 20:54:58 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf = conf_new();
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/*
* Initialize COM.
*/
hr = CoInitialize(NULL);
if (hr != S_OK && hr != S_FALSE) {
char *str = dupprintf("%s Fatal Error", appname);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MessageBox(NULL, "Failed to initialize COM subsystem",
str, MB_OK | MB_ICONEXCLAMATION);
sfree(str);
return 1;
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Process the command line.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *p;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool special_launchable_argument = false;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Move default_protocol and default_port into settings.c. These global variables are only ever used by load_settings, which uses them to vary the default protocol and port number in the absence of any specification elsewhere. So there's no real need for them to be universally accessible via the awkward GLOBAL mechanism: they can be statics inside settings.c, with accessor functions that can set them. That was the last GLOBAL in putty.h, so I've removed the definition of the macro GLOBAL itself as well. There are still some GLOBALs in the Windows subdirectory, though.
2020-02-02 10:00:42 +00:00
settings_set_default_protocol(be_default_protocol);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Find the appropriate default port. */
{
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
const struct BackendVtable *vt =
Move default_protocol and default_port into settings.c. These global variables are only ever used by load_settings, which uses them to vary the default protocol and port number in the absence of any specification elsewhere. So there's no real need for them to be universally accessible via the awkward GLOBAL mechanism: they can be statics inside settings.c, with accessor functions that can set them. That was the last GLOBAL in putty.h, so I've removed the definition of the macro GLOBAL itself as well. There are still some GLOBALs in the Windows subdirectory, though.
2020-02-02 10:00:42 +00:00
backend_vt_from_proto(be_default_protocol);
settings_set_default_port(0); /* illegal */
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (vt)
Move default_protocol and default_port into settings.c. These global variables are only ever used by load_settings, which uses them to vary the default protocol and port number in the absence of any specification elsewhere. So there's no real need for them to be universally accessible via the awkward GLOBAL mechanism: they can be statics inside settings.c, with accessor functions that can set them. That was the last GLOBAL in putty.h, so I've removed the definition of the macro GLOBAL itself as well. There are still some GLOBALs in the Windows subdirectory, though.
2020-02-02 10:00:42 +00:00
settings_set_default_port(vt->default_port);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
conf_set_int(conf, CONF_logtype, LGTYP_NONE);
do_defaults(NULL, conf);
p = cmdline;
/*
* Process a couple of command-line options which are more
* easily dealt with before the line is broken up into words.
* These are the old-fashioned but convenient @sessionname and
* the internal-use-only &sharedmemoryhandle, plus the &R
* prefix for -restrict-acl, all of which are used by PuTTYs
* auto-launching each other via System-menu options.
*/
while (*p && isspace(*p))
p++;
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
if (*p == '&' && p[1] == 'R' &&
(!p[2] || p[2] == '@' || p[2] == '&')) {
/* &R restrict-acl prefix */
restrict_process_acl();
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
restricted_acl = true;
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
p += 2;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (*p == '@') {
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/*
* An initial @ means that the whole of the rest of the
* command line should be treated as the name of a saved
* session, with _no quoting or escaping_. This makes it a
* very convenient means of automated saved-session
* launching, via IDM_SAVEDSESS or Windows 7 jump lists.
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i = strlen(p);
while (i > 1 && isspace(p[i - 1]))
i--;
p[i] = '\0';
do_defaults(p + 1, conf);
if (!conf_launchable(conf) && !do_config()) {
cleanup_exit(0);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
special_launchable_argument = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (*p == '&') {
/*
* An initial & means we've been given a command line
* containing the hex value of a HANDLE for a file
* mapping object, which we must then interpret as a
* serialised Conf.
*/
HANDLE filemap;
void *cp;
unsigned cpsize;
if (sscanf(p + 1, "%p:%u", &filemap, &cpsize) == 2 &&
(cp = MapViewOfFile(filemap, FILE_MAP_READ,
0, 0, cpsize)) != NULL) {
Rewrite conf deserialisation using BinarySource. Like the corresponding rewrite of conf serialisation, this affects not just conf_deserialise itself but also the per-platform filename and fontspec deserialisers.
2018-05-28 14:36:15 +00:00
BinarySource src[1];
BinarySource_BARE_INIT(src, cp, cpsize);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!conf_deserialise(conf, src))
Rewrite conf deserialisation using BinarySource. Like the corresponding rewrite of conf serialisation, this affects not just conf_deserialise itself but also the per-platform filename and fontspec deserialisers.
2018-05-28 14:36:15 +00:00
modalfatalbox("Serialised configuration data was invalid");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
UnmapViewOfFile(cp);
CloseHandle(filemap);
} else if (!do_config()) {
cleanup_exit(0);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
special_launchable_argument = true;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (!*p) {
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
/* Do-nothing case for an empty command line - or rather,
* for a command line that's empty _after_ we strip off
* the &R prefix. */
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Otherwise, break up the command line and deal with
* it sensibly.
*/
int argc, i;
char **argv;
split_into_argv(cmdline, &argc, &argv, NULL);
for (i = 0; i < argc; i++) {
char *p = argv[i];
int ret;
ret = cmdline_process_param(p, i+1<argc?argv[i+1]:NULL,
1, conf);
if (ret == -2) {
cmdline_error("option \"%s\" requires an argument", p);
} else if (ret == 2) {
i++; /* skip next argument */
} else if (ret == 1) {
continue; /* nothing further needs doing */
} else if (!strcmp(p, "-cleanup")) {
/*
* `putty -cleanup'. Remove all registry
* entries associated with PuTTY, and also find
* and delete the random seed file.
*/
char *s1, *s2;
s1 = dupprintf("This procedure will remove ALL Registry entries\n"
"associated with %s, and will also remove\n"
"the random seed file. (This only affects the\n"
"currently logged-in user.)\n"
"\n"
"THIS PROCESS WILL DESTROY YOUR SAVED SESSIONS.\n"
"Are you really sure you want to continue?",
appname);
s2 = dupprintf("%s Warning", appname);
if (message_box(s1, s2,
MB_YESNO | MB_ICONWARNING | MB_DEFBUTTON2,
HELPCTXID(option_cleanup)) == IDYES) {
cleanup_all();
}
sfree(s1);
sfree(s2);
exit(0);
} else if (!strcmp(p, "-pgpfp")) {
pgp_fingerprints();
exit(1);
} else if (*p != '-') {
cmdline_error("unexpected argument \"%s\"", p);
} else {
cmdline_error("unknown option \"%s\"", p);
}
}
}
cmdline_run_saved(conf);
/*
Centralise PuTTY and Plink's non-option argument handling. This is another piece of long-overdue refactoring similar to the recent commit e3796cb77. But where that one dealt with normalisation of stuff already stored _in_ a Conf by whatever means (including, in particular, handling a user typing 'username@host.name' into the Hostname box of the GUI session dialog box), this one deals with handling argv entries and putting them into the Conf. This isn't exactly a pure no-functional-change-at-all refactoring. On the other hand, it isn't a full-on cleanup that completely rationalises all the user-visible behaviour as well as the code structure. It's somewhere in between: I've preserved all the behaviour quirks that I could imagine a reason for having intended, but taken the opportunity to _not_ faithfully replicate anything I thought was clearly just a bug. So, for example, the following inconsistency is carefully preserved: the command 'plink -load session nextword' treats 'nextword' as a host name if the loaded session hasn't provided a hostname already, and otherwise treats 'nextword' as the remote command to execute on the already-specified remote host, but the same combination of arguments to GUI PuTTY will _always_ treat 'nextword' as a hostname, overriding a hostname (if any) in the saved session. That makes some sense to me because of the different shapes of the overall command lines. On the other hand, there are two behaviour changes I know of as a result of this commit: a third argument to GUI PuTTY (after a hostname and port) now provokes an error message instead of being silently ignored, and in Plink, if you combine a -P option (specifying a port number) with the historical comma-separated protocol selection prefix on the hostname argument (which I'd completely forgotten even existed until this piece of work), then the -P will now override the selected protocol's default port number, whereas previously the default port would win. For example, 'plink -P 12345 telnet,hostname' will now connect via Telnet to port 12345 instead of to port 23. There may be scope for removing or rethinking some of the command- line syntax quirks in the wake of this change. If we do decide to do anything like that, then hopefully having it all in one place will make it easier to remove or change things consistently across the tools.
2017-12-07 19:59:43 +00:00
* Bring up the config dialog if the command line hasn't
* (explicitly) specified a launchable configuration.
*/
if (!(special_launchable_argument || cmdline_host_ok(conf))) {
if (!do_config())
cleanup_exit(0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
Factor out common pre-session-launch preparation. A more or less identical piece of code to sanitise the CONF_host string prior to session launch existed in Windows PuTTY and both Windows and Unix Plink. It's long past time it was centralised. While I'm here, I've added a couple of extra comments in the centralised version, including one that - unfortunately - tries _but fails_ to explain why a string of the form "host.name:1234" doesn't get the suffix moved into CONF_port the way "user@host" moves the prefix into CONF_username. Commit c1c1bc471 is the one I'm referring to in the comment, and unfortunately it has an unexplained one-liner log message from before I got into the habit of being usefully verbose.
2017-12-03 14:35:03 +00:00
prepare_session(conf);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
if (!prev) {
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
WNDCLASSW wndclass;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wndclass.style = 0;
wndclass.lpfnWndProc = WndProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hInstance = inst;
wndclass.hIcon = LoadIcon(inst, MAKEINTRESOURCE(IDI_MAINICON));
wndclass.hCursor = LoadCursor(NULL, IDC_IBEAM);
wndclass.hbrBackground = NULL;
wndclass.lpszMenuName = NULL;
wndclass.lpszClassName = dup_mb_to_wc(DEFAULT_CODEPAGE, 0, appname);
RegisterClassW(&wndclass);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Deglobalise the Unicode module. Despite all my grand plans, I've 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]
2003-01-14 18:28:23 +00:00
memset(&ucsdata, 0, sizeof(ucsdata));
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
conf_cache_data();
conftopalette();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Guess some defaults for the window size. This all gets
* updated later, so we don't really care too much. However, we
* do want the font width/height guesses to correspond to a
* large font rather than a small one...
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
font_width = 10;
font_height = 20;
extra_width = 25;
extra_height = 28;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
guess_width = extra_width + font_width * conf_get_int(conf, CONF_width);
guess_height = extra_height + font_height*conf_get_int(conf, CONF_height);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
RECT r;
get_fullscreen_rect(&r);
if (guess_width > r.right - r.left)
guess_width = r.right - r.left;
if (guess_height > r.bottom - r.top)
guess_height = r.bottom - r.top;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int winmode = WS_OVERLAPPEDWINDOW | WS_VSCROLL;
int exwinmode = 0;
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
wchar_t *uappname = dup_mb_to_wc(DEFAULT_CODEPAGE, 0, appname);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!conf_get_bool(conf, CONF_scrollbar))
winmode &= ~(WS_VSCROLL);
if (conf_get_int(conf, CONF_resize_action) == RESIZE_DISABLED)
winmode &= ~(WS_THICKFRAME | WS_MAXIMIZEBOX);
if (conf_get_bool(conf, CONF_alwaysontop))
exwinmode |= WS_EX_TOPMOST;
if (conf_get_bool(conf, CONF_sunken_edge))
exwinmode |= WS_EX_CLIENTEDGE;
hwnd = CreateWindowExW(exwinmode, uappname, uappname,
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
winmode, CW_USEDEFAULT, CW_USEDEFAULT,
guess_width, guess_height,
NULL, NULL, inst, NULL);
sfree(uappname);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Fix from Robert de Bath which reorders the Windows initialisation sequence: since init_fonts sets up ucsdata based on the available Windows fonts, we should call it before passing ucsdata to term_init. [originally from svn r9527]
2012-05-13 15:59:24 +00:00
/*
* Initialise the fonts, simultaneously correcting the guesses
* for font_{width,height}.
*/
init_fonts(0,0);
Changes in startup order to ensure any subsystem which might attempt to schedule timers is not started until after hwnd is initialised. [originally from svn r4912]
2004-11-27 19:41:24 +00:00
/*
* Initialise the terminal. (We have to do this _after_
* creating the window, since the terminal is the first thing
* which will call schedule_timer(), which will in turn call
Nitpick, close bracket. [originally from svn r4926]
2004-11-29 16:58:02 +00:00
* timer_change_notify() which will expect hwnd to exist.)
Changes in startup order to ensure any subsystem which might attempt to schedule timers is not started until after hwnd is initialised. [originally from svn r4912]
2004-11-27 19:41:24 +00:00
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
wintw->vt = &windows_termwin_vt;
term = term_init(conf, &ucsdata, wintw);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
setup_clipboards(term, conf);
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
logctx = log_init(win_gui_logpolicy, conf);
Changes in startup order to ensure any subsystem which might attempt to schedule timers is not started until after hwnd is initialised. [originally from svn r4912]
2004-11-27 19:41:24 +00:00
term_provide_logctx(term, logctx);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
term_size(term, conf_get_int(conf, CONF_height),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_get_int(conf, CONF_width),
conf_get_int(conf, CONF_savelines));
Changes in startup order to ensure any subsystem which might attempt to schedule timers is not started until after hwnd is initialised. [originally from svn r4912]
2004-11-27 19:41:24 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Correct the guesses for extra_{width,height}.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
RECT cr, wr;
GetWindowRect(hwnd, &wr);
GetClientRect(hwnd, &cr);
offset_width = offset_height = conf_get_int(conf, CONF_window_border);
extra_width = wr.right - wr.left - cr.right + cr.left + offset_width*2;
extra_height = wr.bottom - wr.top - cr.bottom + cr.top +offset_height*2;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
/*
* Resize the window, now we know what size we _really_ want it
* to be.
*/
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
guess_width = extra_width + font_width * term->cols;
guess_height = extra_height + font_height * term->rows;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
SetWindowPos(hwnd, NULL, 0, 0, guess_width, guess_height,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SWP_NOMOVE | SWP_NOREDRAW | SWP_NOZORDER);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Try to improve the caret usage [originally from svn r651]
2000-09-29 10:32:07 +00:00
/*
* Set up a caret bitmap, with no content.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *bits;
int size = (font_width + 15) / 16 * 2 * font_height;
bits = snewn(size, char);
memset(bits, 0, size);
caretbm = CreateBitmap(font_width, font_height, 1, 1, bits);
sfree(bits);
Try to improve the caret usage [originally from svn r651]
2000-09-29 10:32:07 +00:00
}
Fix the System Caret so it really is invisible, and the right size too. [originally from svn r842]
2001-01-07 16:35:44 +00:00
CreateCaret(hwnd, caretbm, font_width, font_height);
Try to improve the caret usage [originally from svn r651]
2000-09-29 10:32:07 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Initialise the scroll bar.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SCROLLINFO si;
si.cbSize = sizeof(si);
si.fMask = SIF_ALL | SIF_DISABLENOSCROLL;
si.nMin = 0;
si.nMax = term->rows - 1;
si.nPage = term->rows;
si.nPos = 0;
SetScrollInfo(hwnd, SB_VERT, &si, false);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
/*
* Prepare the mouse handler.
*/
lastact = MA_NOTHING;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
lastbtn = MBT_NOTHING;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
dbltime = GetDoubleClickTime();
/*
* Set up the session-control options on the system menu.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HMENU m;
int j;
char *str;
popup_menus[SYSMENU].menu = GetSystemMenu(hwnd, false);
popup_menus[CTXMENU].menu = CreatePopupMenu();
AppendMenu(popup_menus[CTXMENU].menu, MF_ENABLED, IDM_COPY, "&Copy");
AppendMenu(popup_menus[CTXMENU].menu, MF_ENABLED, IDM_PASTE, "&Paste");
savedsess_menu = CreateMenu();
get_sesslist(&sesslist, true);
update_savedsess_menu();
for (j = 0; j < lenof(popup_menus); j++) {
m = popup_menus[j].menu;
AppendMenu(m, MF_SEPARATOR, 0, 0);
AppendMenu(m, MF_ENABLED, IDM_SHOWLOG, "&Event Log");
AppendMenu(m, MF_SEPARATOR, 0, 0);
AppendMenu(m, MF_ENABLED, IDM_NEWSESS, "Ne&w Session...");
AppendMenu(m, MF_ENABLED, IDM_DUPSESS, "&Duplicate Session");
AppendMenu(m, MF_POPUP | MF_ENABLED, (UINT_PTR) savedsess_menu,
"Sa&ved Sessions");
AppendMenu(m, MF_ENABLED, IDM_RECONF, "Chan&ge Settings...");
AppendMenu(m, MF_SEPARATOR, 0, 0);
AppendMenu(m, MF_ENABLED, IDM_COPYALL, "C&opy All to Clipboard");
AppendMenu(m, MF_ENABLED, IDM_CLRSB, "C&lear Scrollback");
AppendMenu(m, MF_ENABLED, IDM_RESET, "Rese&t Terminal");
AppendMenu(m, MF_SEPARATOR, 0, 0);
AppendMenu(m, (conf_get_int(conf, CONF_resize_action)
== RESIZE_DISABLED) ? MF_GRAYED : MF_ENABLED,
IDM_FULLSCREEN, "&Full Screen");
AppendMenu(m, MF_SEPARATOR, 0, 0);
if (has_help())
AppendMenu(m, MF_ENABLED, IDM_HELP, "&Help");
str = dupprintf("&About %s", appname);
AppendMenu(m, MF_ENABLED, IDM_ABOUT, str);
sfree(str);
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Log when -restrict-acl is in use. Partly to reassure the user that they got what they asked for, and partly so that's a clue for us in the logs when we get bug reports. This involved repurposing platform_psftp_post_option_setup() (no longer used since e22120fe) as platform_psftp_pre_conn_setup(), and moving it to after logging is set up.
2017-02-11 00:44:00 +00:00
if (restricted_acl) {
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
lp_eventlog(win_gui_logpolicy, "Running with restricted process ACL");
Log when -restrict-acl is in use. Partly to reassure the user that they got what they asked for, and partly so that's a clue for us in the logs when we get bug reports. This involved repurposing platform_psftp_post_option_setup() (no longer used since e22120fe) as platform_psftp_pre_conn_setup(), and moving it to after logging is set up.
2017-02-11 00:44:00 +00:00
}
Centralise implementations of Windows do_select(). Windows Plink and PSFTP had very similar implementations, and now they share one that lives in a new file winselcli.c. I've similarly moved GUI PuTTY's implementation out of window.c into winselgui.c, where other GUI programs wanting to do networking will be able to access that too. In the spirit of centralisation, I've also taken the opportunity to make both functions use the reasonably complete winsock_error_string() rather than (for some historical reason) each inlining a minimal version that reports most errors as 'unknown'.
2020-01-01 11:10:22 +00:00
winselgui_set_hwnd(hwnd);
Telnet specials menu was not being reinstated after a session was restarted in the same window (Windows version only). Policy change: it's now the backend's responsibility to call update_specials_menu() at the start of a session (or whenever it feels ready), if it has any special commands. Otherwise the menu won't be displayed. [originally from svn r4649]
2004-10-17 14:44:27 +00:00
start_backend();
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
Set up kbd_codepage at the start of the program, as well as when the input locale changes. With any luck this should sort out the Polish Unicode problems. [originally from svn r1427]
2001-11-29 21:30:59 +00:00
/*
* Set up the initial input locale.
*/
set_input_locale(GetKeyboardLayout(0));
Improved session logging courtesy of Roman Pompejus [originally from svn r846]
2001-01-07 18:24:59 +00:00
/*
Retired the #ifdef DUMP_PACKETS stuff in ssh.c because I'm utterly sick of recompiling to enable packet dumps. SSH packet dumping is now provided as a logging option, and dumps to putty.log like all the other logging options. While I'm at it I cleaned up the format so that packet types are translated into strings for easy browsing. POSSIBLE SIDE EFFECT: in the course of this work I had to re-enable the SSH1 packet length checks which it turns out hadn't actually been active for some time, so it's possible things might break as a result. If need be I can always disable those checks for the 0.52 release and think about it more carefully later. [originally from svn r1493]
2001-12-14 14:57:50 +00:00
* Finally show the window!
Improved session logging courtesy of Roman Pompejus [originally from svn r846]
2001-01-07 18:24:59 +00:00
*/
Retired the #ifdef DUMP_PACKETS stuff in ssh.c because I'm utterly sick of recompiling to enable packet dumps. SSH packet dumping is now provided as a logging option, and dumps to putty.log like all the other logging options. While I'm at it I cleaned up the format so that packet types are translated into strings for easy browsing. POSSIBLE SIDE EFFECT: in the course of this work I had to re-enable the SSH1 packet length checks which it turns out hadn't actually been active for some time, so it's possible things might break as a result. If need be I can always disable those checks for the 0.52 release and think about it more carefully later. [originally from svn r1493]
2001-12-14 14:57:50 +00:00
ShowWindow(hwnd, show);
SetForegroundWindow(hwnd);
Improved session logging courtesy of Roman Pompejus [originally from svn r846]
2001-01-07 18:24:59 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Set the palette up.
*/
pal = NULL;
logpal = NULL;
init_palette();
Slight improvement to cursor blink timing: since the cursor doesn't blink when the window doesn't have focus, we don't schedule blink timers at that point either. Infrastructure change: term->has_focus should now not be written directly from outside terminal.c. Instead, use the function term_set_focus, which will sort out the blink timers as well. [originally from svn r4911]
2004-11-27 19:34:45 +00:00
term_set_focus(term, GetForegroundWindow() == hwnd);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
UpdateWindow(hwnd);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
while (1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HANDLE *handles;
int nhandles, n;
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
DWORD timeout;
Replace GetQueueStatus with PeekMessage(PM_NOREMOVE). A couple of users report that my recent reworking of the Windows top-level message loop has led to messages occasionally being lost, and MsgWaitForMultipleObjects blocking when it ought to have been called with a zero timeout. I haven't been able to reproduce this myself, but according to one reporter, PeekMessage(PM_NOREMOVE) is effective at checking for a non-empty message queue in a way that GetQueueStatus is not. Switch to using that instead. Thanks to Eric Flumerfelt for debugging and testing help. [originally from svn r10057]
2013-11-11 23:01:47 +00:00
if (toplevel_callback_pending() ||
PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)) {
Avoid leaving unread Windows messages in the queue. Jochen Erwied points out that once you've used PeekMessage to remove _one_ message from the message queue, MsgWaitForMultipleObjects will consider the whole queue to have been 'read', or at least looked at and deemed uninteresting, and so it will block until a further message comes in. Hence, my change in r10040 which stops us from looping on PeekMessage until the queue is empty has the effect of causing the rest of the message queue not to be acted on until a new message comes in to unblock it. Fix by checking if the queue is nonempty in advance of calling MsgWaitForMultipleObjects, and if so, giving it a zero timeout just as we do if there's a pending toplevel callback. [originally from svn r10052] [r10040 == 5c4ce2fadf23bff6f38155df44b5d6040cf80d26]
2013-10-25 17:44:02 +00:00
/*
* If we have anything we'd like to do immediately, set
* the timeout for MsgWaitForMultipleObjects to zero so
* that we'll only do a quick check of our handles and
* then get on with whatever that was.
*
* One such option is a pending toplevel callback. The
* other is a non-empty Windows message queue, which you'd
* think we could leave to MsgWaitForMultipleObjects to
* check for us along with all the handles, but in fact we
* can't because once PeekMessage in one iteration of this
* loop has removed a message from the queue, the whole
* queue is considered uninteresting by the next
* invocation of MWFMO. So we check ourselves whether the
* message queue is non-empty, and if so, set this timeout
* to zero to ensure MWFMO doesn't block.
*/
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
timeout = 0;
} else {
timeout = INFINITE;
/* The messages seem unreliable; especially if we're being tricky */
term_set_focus(term, GetForegroundWindow() == hwnd);
}
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
handles = handle_get_events(&nhandles);
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
n = MsgWaitForMultipleObjects(nhandles, handles, false,
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
timeout, QS_ALLINPUT);
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((unsigned)(n - WAIT_OBJECT_0) < (unsigned)nhandles) {
handle_got_event(handles[n - WAIT_OBJECT_0]);
sfree(handles);
} else
sfree(handles);
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (PeekMessageW(&msg, NULL, 0, 0, PM_REMOVE)) {
if (msg.message == WM_QUIT)
goto finished; /* two-level break */
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!(IsWindow(logbox) && IsDialogMessage(logbox, &msg)))
DispatchMessageW(&msg);
Stop Windows PuTTY becoming unresponsive if server floods us. This was an old bug, fixed around 0.59, which apparently regressed when I rewrote the main event loop using the toplevel_callback mechanism. Investigation just now suggests that it has to do with my faulty assumption that Windows PeekMessage would deliver messages in its message queue in FIFO order (i.e. that the thing calling itself a message queue is actually a _queue_). In fact my WM_NETEVENT seems to like to jump the queue, so that once a steady stream of them starts arriving, we never do anything else in the main event loop (except deal with handles). Worked around in a simple and slightly bodgy way, namely, we don't stop looping on PeekMessage and run our toplevel callbacks until we've either run out of messages completely or else seen at least one that _isn't_ a WM_NETEVENT. That way we should reliably interleave NETEVENT processing with processing of other stuff.
2015-03-07 17:10:36 +00:00
/*
* WM_NETEVENT messages seem to jump ahead of others in
* the message queue. I'm not sure why; the docs for
* PeekMessage mention that messages are prioritised in
* some way, but I'm unclear on which priorities go where.
*
* Anyway, in practice I observe that WM_NETEVENT seems to
* jump to the head of the queue, which means that if we
* were to only process one message every time round this
* loop, we'd get nothing but NETEVENTs if the server
* flooded us with data, and stop responding to any other
* kind of window message. So instead, we keep on round
* this loop until we've consumed at least one message
* that _isn't_ a NETEVENT, or run out of messages
* completely (whichever comes first). And we don't go to
* run_toplevel_callbacks (which is where the netevents
* are actually processed, causing fresh NETEVENT messages
* to appear) until we've done this.
*/
if (msg.message != WM_NETEVENT)
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
RDB's general resizing cleanup. He's put his favourite resize mode back in again, but as long as it's not the default it doesn't bother me too much :-) [originally from svn r1421]
2001-11-25 18:39:57 +00:00
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
run_toplevel_callbacks();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
finished:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cleanup_exit(msg.wParam); /* this doesn't return... */
return msg.wParam; /* ... but optimiser doesn't know */
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
}
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
static void setup_clipboards(Terminal *term, Conf *conf)
{
assert(term->mouse_select_clipboards[0] == CLIP_LOCAL);
term->n_mouse_select_clipboards = 1;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_mouseautocopy)) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
term->mouse_select_clipboards[
term->n_mouse_select_clipboards++] = CLIP_SYSTEM;
}
switch (conf_get_int(conf, CONF_mousepaste)) {
case CLIPUI_IMPLICIT:
term->mouse_paste_clipboard = CLIP_LOCAL;
break;
case CLIPUI_EXPLICIT:
term->mouse_paste_clipboard = CLIP_SYSTEM;
break;
default:
term->mouse_paste_clipboard = CLIP_NULL;
break;
}
}
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
/*
* Clean up and exit.
*/
void cleanup_exit(int code)
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Clean up.
*/
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
deinit_fonts();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
sfree(logpal);
if (pal)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DeleteObject(pal);
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
sk_cleanup();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_protocol) == PROT_SSH) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
random_save_seed();
Peter Schellenbach's patch: re-implement the PuTTY cryptographic functions as calls to the MS Crypto API. Not integrated into the Makefile yet, but should eventually allow building of an SSH-enabled PuTTY which contains no native crypto code, so it can be used everywhere (and anyone who can get the MS encryption pack can still use the SSH parts). [originally from svn r425]
2000-03-24 09:45:49 +00:00
}
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
shutdown_help();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/* Clean up COM. */
CoUninitialize();
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
exit(code);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
/*
* Refresh the saved-session submenu from `sesslist'.
*/
static void update_savedsess_menu(void)
{
int i;
while (DeleteMenu(savedsess_menu, 0, MF_BYPOSITION)) ;
/* skip sesslist.sessions[0] == Default Settings */
for (i = 1;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
i < ((sesslist.nsessions <= MENU_SAVED_MAX+1) ? sesslist.nsessions
: MENU_SAVED_MAX+1);
i++)
AppendMenu(savedsess_menu, MF_ENABLED,
IDM_SAVED_MIN + (i-1)*MENU_SAVED_STEP,
sesslist.sessions[i]);
If there are no saved sessions, put a grayed "(No sessions)" entry on the saved sessions submenu of the terminal window context menu (as Pageant does), rather than an empty menu (which often renders poorly). [originally from svn r8648]
2009-09-13 23:29:11 +00:00
if (sesslist.nsessions <= 1)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
AppendMenu(savedsess_menu, MF_GRAYED, IDM_SAVED_MIN, "(No sessions)");
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
}
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
/*
* Update the Special Commands submenu.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void win_seat_update_specials_menu(Seat *seat)
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
{
Users of Virtual Dimension are reporting that the "Close" menu item and button tend to get disabled on login. After a suggestion by "Tkil", change the way we handle the specials menu to be robust against the window menu being externally modified. [originally from svn r6546] [this svn revision also touched putty-wishlist]
2006-02-09 23:06:57 +00:00
HMENU new_menu;
Introduce a context menu which appears on Ctrl+rightclick. This menu contains all the stuff in the System menu except for the standard System menu bits (move, resize, close etc), and also contains `Paste'. [originally from svn r3555]
2003-11-19 20:48:30 +00:00
int i, j;
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend)
specials = backend_get_specials(backend);
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
specials = NULL;
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
if (specials) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* We can't use Windows to provide a stack for submenus, so
* here's a lame "stack" that will do for now. */
HMENU saved_menu = NULL;
int nesting = 1;
new_menu = CreatePopupMenu();
for (i = 0; nesting > 0; i++) {
assert(IDM_SPECIAL_MIN + 0x10 * i < IDM_SPECIAL_MAX);
switch (specials[i].code) {
case SS_SEP:
AppendMenu(new_menu, MF_SEPARATOR, 0, 0);
break;
case SS_SUBMENU:
assert(nesting < 2);
nesting++;
saved_menu = new_menu; /* XXX lame stacking */
new_menu = CreatePopupMenu();
AppendMenu(saved_menu, MF_POPUP | MF_ENABLED,
(UINT_PTR) new_menu, specials[i].name);
break;
case SS_EXITMENU:
nesting--;
if (nesting) {
new_menu = saved_menu; /* XXX lame stacking */
saved_menu = NULL;
}
break;
default:
AppendMenu(new_menu, MF_ENABLED, IDM_SPECIAL_MIN + 0x10 * i,
specials[i].name);
break;
}
}
/* Squirrel the highest special. */
n_specials = i - 1;
Support the SSH-2 mechanism for sending signals to a running session. Neither of the SSH servers I conveniently have access to (Debian stable OpenSSH -- 3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel requests look fine to me in the packet log. I've included all the signals explicitly defined by draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu of the specials menu; there's therefore been some minor upheaval to support such submenus. [originally from svn r4652]
2004-10-17 21:22:22 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
new_menu = NULL;
n_specials = 0;
Support the SSH-2 mechanism for sending signals to a running session. Neither of the SSH servers I conveniently have access to (Debian stable OpenSSH -- 3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel requests look fine to me in the packet log. I've included all the signals explicitly defined by draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu of the specials menu; there's therefore been some minor upheaval to support such submenus. [originally from svn r4652]
2004-10-17 21:22:22 +00:00
}
Implement `Restart Session', in both Unix and Windows PuTTY. Largely because Owen questioned whether it was really easy enough to be labelled `fun' in the bug database :-) [originally from svn r4453]
2004-08-14 13:04:18 +00:00
for (j = 0; j < lenof(popup_menus); j++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (specials_menu) {
/* XXX does this free up all submenus? */
DeleteMenu(popup_menus[j].menu, (UINT_PTR)specials_menu,
64-bit cleanness: use INT_PTR/UINT_PTR where appropriate. These integer types are correct for the id/handle parameter to AppendMenu / InsertMenu / DeleteMenu, and also for the return type of dialog box procedures.
2016-04-02 13:10:27 +00:00
MF_BYCOMMAND);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DeleteMenu(popup_menus[j].menu, IDM_SPECIALSEP, MF_BYCOMMAND);
}
if (new_menu) {
InsertMenu(popup_menus[j].menu, IDM_SHOWLOG,
MF_BYCOMMAND | MF_POPUP | MF_ENABLED,
(UINT_PTR) new_menu, "S&pecial Command");
InsertMenu(popup_menus[j].menu, IDM_SHOWLOG,
MF_BYCOMMAND | MF_SEPARATOR, IDM_SPECIALSEP, 0);
}
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
}
Oops. Since r6546, old "Special Commands" menus weren't being deleted from the context menu, and they tended to pile up. [originally from svn r6547] [r6546 == 3cdf5b739f00445f7eef721fab6e321c19f2016f]
2006-02-10 20:57:40 +00:00
specials_menu = new_menu;
Turned the old `Telnet Command' System-submenu into a more general `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]
2003-04-04 20:21:05 +00:00
}
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
static void update_mouse_pointer(void)
{
Fix a few compiler warnings from MinGW. A few variables that gcc couldn't tell I'd initialised on all the important paths, a variable that didn't really need to be there anyway, and yet another use of GET_WINDOWS_FUNCTION_NO_TYPECHECK.
2018-06-03 20:48:08 +00:00
LPTSTR curstype = NULL;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool force_visible = false;
static bool forced_visible = false;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
switch (busy_status) {
case BUSY_NOT:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (send_raw_mouse)
curstype = IDC_ARROW;
else
curstype = IDC_IBEAM;
break;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
case BUSY_WAITING:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
curstype = IDC_APPSTARTING; /* this may be an abuse */
force_visible = true;
break;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
case BUSY_CPU:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
curstype = IDC_WAIT;
force_visible = true;
break;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
default:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unreachable("Bad busy_status");
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
}
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HCURSOR cursor = LoadCursor(NULL, curstype);
SetClassLongPtr(hwnd, GCLP_HCURSOR, (LONG_PTR)cursor);
SetCursor(cursor); /* force redraw of cursor at current posn */
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
}
if (force_visible != forced_visible) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* We want some cursor shapes to be visible always.
* Along with show_mouseptr(), this manages the ShowCursor()
* counter such that if we switch back to a non-force_visible
* cursor, the previous visibility state is restored. */
ShowCursor(force_visible);
forced_visible = force_visible;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
}
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void win_seat_set_busy_status(Seat *seat, BusyStatus status)
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
{
busy_status = status;
update_mouse_pointer();
}
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
/*
* set or clear the "raw mouse message" mode
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_raw_mouse_mode(TermWin *tw, bool activate)
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
activate = activate && !conf_get_bool(conf, CONF_no_mouse_rep);
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
send_raw_mouse = activate;
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
update_mouse_pointer();
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
}
Prevent network errors from summarily closing the window when CoE is off [originally from svn r613]
2000-09-22 11:04:57 +00:00
/*
* Print a message box and close the connection.
*/
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void win_seat_connection_fatal(Seat *seat, const char *msg)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *title = dupprintf("%s Fatal Error", appname);
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
MessageBox(hwnd, msg, title, MB_ICONERROR | MB_OK);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
sfree(title);
Colin's and my fixes to connection_fatal(). [originally from svn r3161]
2003-05-04 14:14:10 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_close_on_exit) == FORCE_ON)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
PostQuitMessage(1);
Prevent network errors from summarily closing the window when CoE is off [originally from svn r613]
2000-09-22 11:04:57 +00:00
else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
queue_toplevel_callback(close_session, NULL);
Prevent network errors from summarily closing the window when CoE is off [originally from svn r613]
2000-09-22 11:04:57 +00:00
}
}
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
/*
* Report an error at the command-line parsing stage.
*/
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void cmdline_error(const char *fmt, ...)
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
{
va_list ap;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *message, *title;
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
va_start(ap, fmt);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
message = dupvprintf(fmt, ap);
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
va_end(ap);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
title = dupprintf("%s Command Line Error", appname);
MessageBox(hwnd, message, title, MB_ICONERROR | MB_OK);
sfree(message);
sfree(title);
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
exit(1);
}
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
/*
* Actually do the job requested by a WM_NETEVENT
*/
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
static void wm_netevent_callback(void *vctx)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
struct wm_netevent_params *params = (struct wm_netevent_params *)vctx;
select_result(params->wParam, params->lParam);
sfree(vctx);
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Copy the colour palette from the configuration data into defpal.
* This is non-trivial because the colour indices are different.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
static void conftopalette(void)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
int i;
static const int ww[] = {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
256, 257, 258, 259, 260, 261,
0, 8, 1, 9, 2, 10, 3, 11,
4, 12, 5, 13, 6, 14, 7, 15
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
};
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
for (i = 0; i < 22; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int w = ww[i];
defpal[w].rgbtRed = conf_get_int_int(conf, CONF_colours, i*3+0);
defpal[w].rgbtGreen = conf_get_int_int(conf, CONF_colours, i*3+1);
defpal[w].rgbtBlue = conf_get_int_int(conf, CONF_colours, i*3+2);
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
for (i = 0; i < NEXTCOLOURS; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (i < 216) {
int r = i / 36, g = (i / 6) % 6, b = i % 6;
defpal[i+16].rgbtRed = r ? r * 40 + 55 : 0;
defpal[i+16].rgbtGreen = g ? g * 40 + 55 : 0;
defpal[i+16].rgbtBlue = b ? b * 40 + 55 : 0;
} else {
int shade = i - 216;
shade = shade * 10 + 8;
defpal[i+16].rgbtRed = defpal[i+16].rgbtGreen =
defpal[i+16].rgbtBlue = shade;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Implement `default-colours' on Windows based loosely on Michael Wardle's patch. [originally from svn r3444]
2003-09-03 20:14:38 +00:00
/* Override with system colours if appropriate */
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_system_colour))
Implement `default-colours' on Windows based loosely on Michael Wardle's patch. [originally from svn r3444]
2003-09-03 20:14:38 +00:00
systopalette();
}
/*
* Override bit of defpal with colours from the system.
* (NB that this takes a copy the system colours at the time this is called,
* so subsequent colour scheme changes don't take effect. To fix that we'd
* probably want to be using GetSysColorBrush() and the like.)
*/
static void systopalette(void)
{
int i;
static const struct { int nIndex; int norm; int bold; } or[] =
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{ COLOR_WINDOWTEXT, 256, 257 }, /* Default Foreground */
{ COLOR_WINDOW, 258, 259 }, /* Default Background */
{ COLOR_HIGHLIGHTTEXT, 260, 260 }, /* Cursor Text */
{ COLOR_HIGHLIGHT, 261, 261 }, /* Cursor Colour */
Implement `default-colours' on Windows based loosely on Michael Wardle's patch. [originally from svn r3444]
2003-09-03 20:14:38 +00:00
};
for (i = 0; i < (sizeof(or)/sizeof(or[0])); i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
COLORREF colour = GetSysColor(or[i].nIndex);
defpal[or[i].norm].rgbtRed =
defpal[or[i].bold].rgbtRed = GetRValue(colour);
defpal[or[i].norm].rgbtGreen =
defpal[or[i].bold].rgbtGreen = GetGValue(colour);
defpal[or[i].norm].rgbtBlue =
defpal[or[i].bold].rgbtBlue = GetBValue(colour);
Implement `default-colours' on Windows based loosely on Michael Wardle's patch. [originally from svn r3444]
2003-09-03 20:14:38 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
static void internal_set_colour(int i, int r, int g, int b)
{
assert(i >= 0);
assert(i < NALLCOLOURS);
if (pal)
colours[i] = PALETTERGB(r, g, b);
else
colours[i] = RGB(r, g, b);
colours_rgb[i].r = r;
colours_rgb[i].g = g;
colours_rgb[i].b = b;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Set up the colour palette.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static void init_palette(void)
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
int i;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
HDC hdc = GetDC(hwnd);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (hdc) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (conf_get_bool(conf, CONF_try_palette) &&
GetDeviceCaps(hdc, RASTERCAPS) & RC_PALETTE) {
/*
* This is a genuine case where we must use smalloc
* because the snew macros can't cope.
*/
logpal = smalloc(sizeof(*logpal)
- sizeof(logpal->palPalEntry)
+ NALLCOLOURS * sizeof(PALETTEENTRY));
logpal->palVersion = 0x300;
logpal->palNumEntries = NALLCOLOURS;
for (i = 0; i < NALLCOLOURS; i++) {
logpal->palPalEntry[i].peRed = defpal[i].rgbtRed;
logpal->palPalEntry[i].peGreen = defpal[i].rgbtGreen;
logpal->palPalEntry[i].peBlue = defpal[i].rgbtBlue;
logpal->palPalEntry[i].peFlags = PC_NOCOLLAPSE;
}
pal = CreatePalette(logpal);
if (pal) {
SelectPalette(hdc, pal, false);
RealizePalette(hdc);
SelectPalette(hdc, GetStockObject(DEFAULT_PALETTE), false);
}
}
ReleaseDC(hwnd, hdc);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
for (i = 0; i < NALLCOLOURS; i++)
internal_set_colour(i, defpal[i].rgbtRed,
defpal[i].rgbtGreen, defpal[i].rgbtBlue);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
/*
* This is a wrapper to ExtTextOut() to force Windows to display
* the precise glyphs we give it. Otherwise it would do its own
* bidi and Arabic shaping, and we would end up uncertain which
* characters it had put where.
*/
static void exact_textout(HDC hdc, int x, int y, CONST RECT *lprc,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unsigned short *lpString, UINT cbCount,
CONST INT *lpDx, bool opaque)
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
{
Further fix for lcc-win32. The PuTTY suite now compiles fine for me using lcc-win32 v3.8 (compilation date Mar 2 2005 18:40:17) provided I pass COMPAT="-DNO_IPV6 -DNO_MULTIMON" on the command line. [originally from svn r5573]
2005-03-30 19:33:24 +00:00
#ifdef __LCC__
/*
* The LCC include files apparently don't supply the
* GCP_RESULTSW type, but we can make do with GCP_RESULTS
* proper: the differences aren't important to us (the only
* variable-width string parameter is one we don't use anyway).
*/
GCP_RESULTS gcpr;
#else
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
GCP_RESULTSW gcpr;
Further fix for lcc-win32. The PuTTY suite now compiles fine for me using lcc-win32 v3.8 (compilation date Mar 2 2005 18:40:17) provided I pass COMPAT="-DNO_IPV6 -DNO_MULTIMON" on the command line. [originally from svn r5573]
2005-03-30 19:33:24 +00:00
#endif
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
char *buffer = snewn(cbCount*2+2, char);
char *classbuffer = snewn(cbCount, char);
memset(&gcpr, 0, sizeof(gcpr));
memset(buffer, 0, cbCount*2+2);
memset(classbuffer, GCPCLASS_NEUTRAL, cbCount);
gcpr.lStructSize = sizeof(gcpr);
gcpr.lpGlyphs = (void *)buffer;
According to Frank Dijcks, this cast makes OpenWatcom happier. [originally from svn r7089]
2007-01-10 00:46:45 +00:00
gcpr.lpClass = (void *)classbuffer;
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
gcpr.nGlyphs = cbCount;
GetCharacterPlacementW(hdc, lpString, cbCount, 0, &gcpr,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
FLI_MASK | GCP_CLASSIN | GCP_DIACRITIC);
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
ExtTextOut(hdc, x, y,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ETO_GLYPH_INDEX | ETO_CLIPPED | (opaque ? ETO_OPAQUE : 0),
lprc, buffer, cbCount, lpDx);
At last! After much delay, much faffing back and forth, and much enhancement and fiddling, I have now massaged Arabeyes' first patch into a form I'm happy to check in. Phew. [originally from svn r4236]
2004-05-22 10:36:50 +00:00
}
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
/*
* The exact_textout() wrapper, unfortunately, destroys the useful
* Windows `font linking' behaviour: automatic handling of Unicode
* code points not supported in this font by falling back to a font
* which does contain them. Therefore, we adopt a multi-layered
* approach: for any potentially-bidi text, we use exact_textout(),
* and for everything else we use a simple ExtTextOut as we did
* before exact_textout() was introduced.
*/
static void general_textout(HDC hdc, int x, int y, CONST RECT *lprc,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unsigned short *lpString, UINT cbCount,
CONST INT *lpDx, bool opaque)
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
{
int i, j, xp, xn;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int bkmode = 0;
bool got_bkmode = false;
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
xp = xn = x;
Get rid of all the MSVC warnings. [originally from svn r7086]
2007-01-09 18:24:07 +00:00
for (i = 0; i < (int)cbCount ;) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool rtl = is_rtl(lpString[i]);
xn += lpDx[i];
for (j = i+1; j < (int)cbCount; j++) {
if (rtl != is_rtl(lpString[j]))
break;
xn += lpDx[j];
}
/*
* Now [i,j) indicates a maximal substring of lpString
* which should be displayed using the same textout
* function.
*/
if (rtl) {
exact_textout(hdc, xp, y, lprc, lpString+i, j-i,
Fix segfault in general_textout with variable-pitch fonts: we can't pass null lpDx, because general_textout depends on it being filled in. Instead we null it out in the calls to subroutines _from_ general_textout. [originally from svn r9064]
2010-12-29 16:00:58 +00:00
font_varpitch ? NULL : lpDx+i, opaque);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
ExtTextOutW(hdc, xp, y, ETO_CLIPPED | (opaque ? ETO_OPAQUE : 0),
lprc, lpString+i, j-i,
Fix segfault in general_textout with variable-pitch fonts: we can't pass null lpDx, because general_textout depends on it being filled in. Instead we null it out in the calls to subroutines _from_ general_textout. [originally from svn r9064]
2010-12-29 16:00:58 +00:00
font_varpitch ? NULL : lpDx+i);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
i = j;
xp = xn;
Stop general_textout() from trying to slice up the input clipping rectangle into smaller ones: it doesn't work any more, since the new variable-pitch code can now call general_textout() with a larger clipping rectangle than the text it's meant to be displaying. Instead, general_textout() now uses the same semantics as the next loop up in do_text_internal(): the first piece of text it displays uses the opacity setting passed in, which blanks the entire clipping rectangle if necessary, and then subsequent overlays are non-opaque. And the same clipping rectangle is used throughout. [originally from svn r9067]
2010-12-30 00:06:43 +00:00
bkmode = GetBkMode(hdc);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
got_bkmode = true;
Stop general_textout() from trying to slice up the input clipping rectangle into smaller ones: it doesn't work any more, since the new variable-pitch code can now call general_textout() with a larger clipping rectangle than the text it's meant to be displaying. Instead, general_textout() now uses the same semantics as the next loop up in do_text_internal(): the first piece of text it displays uses the opacity setting passed in, which blanks the entire clipping rectangle if necessary, and then subsequent overlays are non-opaque. And the same clipping rectangle is used throughout. [originally from svn r9067]
2010-12-30 00:06:43 +00:00
SetBkMode(hdc, TRANSPARENT);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
opaque = false;
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
}
Stop general_textout() from trying to slice up the input clipping rectangle into smaller ones: it doesn't work any more, since the new variable-pitch code can now call general_textout() with a larger clipping rectangle than the text it's meant to be displaying. Instead, general_textout() now uses the same semantics as the next loop up in do_text_internal(): the first piece of text it displays uses the opacity setting passed in, which blanks the entire clipping rectangle if necessary, and then subsequent overlays are non-opaque. And the same clipping rectangle is used throughout. [originally from svn r9067]
2010-12-30 00:06:43 +00:00
if (got_bkmode)
SetBkMode(hdc, bkmode);
Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910]
2006-11-18 15:10:48 +00:00
}
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
static int get_font_width(HDC hdc, const TEXTMETRIC *tm)
{
int ret;
/* Note that the TMPF_FIXED_PITCH bit is defined upside down :-( */
if (!(tm->tmPitchAndFamily & TMPF_FIXED_PITCH)) {
ret = tm->tmAveCharWidth;
} else {
#define FIRST '0'
#define LAST '9'
ABCFLOAT widths[LAST-FIRST + 1];
int j;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
font_varpitch = true;
font_dualwidth = true;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
if (GetCharABCWidthsFloat(hdc, FIRST, LAST, widths)) {
ret = 0;
for (j = 0; j < lenof(widths); j++) {
int width = (int)(0.5 + widths[j].abcfA +
widths[j].abcfB + widths[j].abcfC);
if (ret < width)
ret = width;
}
} else {
ret = tm->tmMaxCharWidth;
}
#undef FIRST
#undef LAST
}
return ret;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
* Initialise all the fonts we will need initially. There may be as many as
A comment typo fix I've had lying around for a while. [originally from svn r8974]
2010-07-30 19:45:40 +00:00
* three or as few as one. The other (potentially) twenty-one fonts are done
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
* if/when they are needed.
*
* We also:
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
*
* - check the font width and height, correcting our guesses if
* necessary.
*
* - verify that the bold font is the same width as the ordinary
* one, and engage shadow bolding if not.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
* - verify that the underlined font is the same width as the
* ordinary one (manual underlining by means of line drawing can
* be done in a pinch).
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
*
* - find a trust sigil icon that will look OK with the chosen font.
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
*/
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
static void init_fonts(int pick_width, int pick_height)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
TEXTMETRIC tm;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
CPINFO cpinfo;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
FontSpec *font;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
int fontsize[3];
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
int i;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int quality;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
HDC hdc;
int fw_dontcare, fw_bold;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
for (i = 0; i < FONT_MAXNO; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fonts[i] = NULL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
bold_font_mode = conf_get_int(conf, CONF_bold_style) & 1 ?
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
BOLD_FONT : BOLD_NONE;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
bold_colours = conf_get_int(conf, CONF_bold_style) & 2 ? true : false;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
und_mode = UND_FONT;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
font = conf_get_fontspec(conf, CONF_font);
if (font->isbold) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fw_dontcare = FW_BOLD;
fw_bold = FW_HEAVY;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fw_dontcare = FW_DONTCARE;
fw_bold = FW_BOLD;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
hdc = GetDC(hwnd);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
if (pick_height)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
font_height = pick_height;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
font_height = font->height;
if (font_height > 0) {
font_height =
-MulDiv(font_height, GetDeviceCaps(hdc, LOGPIXELSY), 72);
}
Finally fixed the point/pixel confusion in font handling. Thanks to Roman Surma for pointing me at the relevant bits of documentation. All font sizes should now be measured in points, and everything should be consistent, and (with any luck) old Registry settings should adapt gracefully too. [originally from svn r992]
2001-03-12 12:24:07 +00:00
}
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
font_width = pick_width;
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
quality = conf_get_int(conf, CONF_font_quality);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
#define f(i,c,w,u) \
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
fonts[i] = CreateFont (font_height, font_width, 0, 0, w, false, u, false, \
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
c, OUT_DEFAULT_PRECIS, \
CLIP_DEFAULT_PRECIS, FONT_QUALITY(quality), \
FIXED_PITCH | FF_DONTCARE, font->name)
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
f(FONT_NORMAL, font->charset, fw_dontcare, false);
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
SelectObject(hdc, fonts[FONT_NORMAL]);
GetTextMetrics(hdc, &tm);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Improvement for IME font display from Hung-Te Lin. Not tested, but it appears only to affect Glenn Maynard's r1406 code from <20011006170741.A23470@zewt.org> and nothing else, so seems harmless enough. [originally from svn r5533] [r1406 == d9f7fc44bc177da552a14b879c199cc99f991e19]
2005-03-21 01:05:38 +00:00
GetObject(fonts[FONT_NORMAL], sizeof(LOGFONT), &lfont);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
/* Note that the TMPF_FIXED_PITCH bit is defined upside down :-( */
if (!(tm.tmPitchAndFamily & TMPF_FIXED_PITCH)) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
font_varpitch = false;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
font_dualwidth = (tm.tmAveCharWidth != tm.tmMaxCharWidth);
} else {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
font_varpitch = true;
font_dualwidth = true;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
}
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
if (pick_width == 0 || pick_height == 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
font_height = tm.tmHeight;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
font_width = get_font_width(hdc, &tm);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
#ifdef RDB_DEBUG_PATCH
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug("Primary font H=%d, AW=%d, MW=%d\n",
tm.tmHeight, tm.tmAveCharWidth, tm.tmMaxCharWidth);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
CHARSETINFO info;
DWORD cset = tm.tmCharSet;
memset(&info, 0xFF, sizeof(info));
/* !!! Yes the next line is right */
if (cset == OEM_CHARSET)
ucsdata.font_codepage = GetOEMCP();
else
if (TranslateCharsetInfo ((DWORD *)(ULONG_PTR)cset,
Fix a few more clang-generated warnings. These are benign, I think. clang warns about casting non-pointer-sized integers to pointers, but the Windows API actually does sometimes involve values that are either pointers or _small_ integers, so in the two cases involved I just cast through ULONG_PTR to silence the warning. And clang insists that the integer whose address I give to sk_getxdmdata is still uninitialised afterwards, which is just a lie.
2017-02-05 11:19:12 +00:00
&info, TCI_SRCCHARSET))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ucsdata.font_codepage = info.ciACP;
else
ucsdata.font_codepage = -1;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GetCPInfo(ucsdata.font_codepage, &cpinfo);
ucsdata.dbcs_screenfont = (cpinfo.MaxCharSize > 1);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
f(FONT_UNDERLINE, font->charset, fw_dontcare, true);
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
/*
* Some fonts, e.g. 9-pt Courier, draw their underlines
* outside their character cell. We successfully prevent
* screen corruption by clipping the text output, but then
* we lose the underline completely. Here we try to work
* out whether this is such a font, and if it is, we set a
* flag that causes underlines to be drawn by hand.
*
* Having tried other more sophisticated approaches (such
* as examining the TEXTMETRIC structure or requesting the
* height of a string), I think we'll do this the brute
* force way: we create a small bitmap, draw an underlined
* space on it, and test to see whether any pixels are
* foreground-coloured. (Since we expect the underline to
* go all the way across the character cell, we only search
* down a single column of the bitmap, half way across.)
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HDC und_dc;
HBITMAP und_bm, und_oldbm;
int i;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool gotit;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
COLORREF c;
und_dc = CreateCompatibleDC(hdc);
und_bm = CreateCompatibleBitmap(hdc, font_width, font_height);
und_oldbm = SelectObject(und_dc, und_bm);
SelectObject(und_dc, fonts[FONT_UNDERLINE]);
SetTextAlign(und_dc, TA_TOP | TA_LEFT | TA_NOUPDATECP);
SetTextColor(und_dc, RGB(255, 255, 255));
SetBkColor(und_dc, RGB(0, 0, 0));
SetBkMode(und_dc, OPAQUE);
ExtTextOut(und_dc, 0, 0, ETO_OPAQUE, NULL, " ", 1, NULL);
gotit = false;
for (i = 0; i < font_height; i++) {
c = GetPixel(und_dc, font_width / 2, i);
if (c != RGB(0, 0, 0))
gotit = true;
}
SelectObject(und_dc, und_oldbm);
DeleteObject(und_bm);
DeleteDC(und_dc);
if (!gotit) {
und_mode = UND_LINE;
DeleteObject(fonts[FONT_UNDERLINE]);
fonts[FONT_UNDERLINE] = 0;
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_FONT) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
f(FONT_BOLD, font->charset, fw_bold, false);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
#undef f
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
descent = tm.tmAscent + 1;
if (descent >= font_height)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
descent = font_height - 1;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
for (i = 0; i < 3; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (fonts[i]) {
if (SelectObject(hdc, fonts[i]) && GetTextMetrics(hdc, &tm))
fontsize[i] = get_font_width(hdc, &tm) + 256 * tm.tmHeight;
else
fontsize[i] = -i;
} else
fontsize[i] = -i;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
ReleaseDC(hwnd, hdc);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Don't call DestroyIcon(INVALID_HANDLE_VALUE). The Windows API documentation doesn't explicitly say this is safe, and ea32967044 didn't take care over it.
2019-03-31 22:47:03 +00:00
if (trust_icon != INVALID_HANDLE_VALUE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DestroyIcon(trust_icon);
Don't call DestroyIcon(INVALID_HANDLE_VALUE). The Windows API documentation doesn't explicitly say this is safe, and ea32967044 didn't take care over it.
2019-03-31 22:47:03 +00:00
}
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
trust_icon = LoadImage(hinst, MAKEINTRESOURCE(IDI_MAINICON),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
IMAGE_ICON, font_width*2, font_height,
LR_DEFAULTCOLOR);
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontsize[FONT_UNDERLINE] != fontsize[FONT_NORMAL]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
und_mode = UND_LINE;
DeleteObject(fonts[FONT_UNDERLINE]);
fonts[FONT_UNDERLINE] = 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_FONT &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fontsize[FONT_BOLD] != fontsize[FONT_NORMAL]) {
bold_font_mode = BOLD_SHADOW;
DeleteObject(fonts[FONT_BOLD]);
fonts[FONT_BOLD] = 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
fontflag[0] = true;
fontflag[1] = true;
fontflag[2] = true;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
init_ucs(conf, &ucsdata);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
static void another_font(int fontno)
{
int basefont;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int fw_dontcare, fw_bold, quality;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int c, w, x;
bool u;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
char *s;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
FontSpec *font;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontno < 0 || fontno >= FONT_MAXNO || fontflag[fontno])
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
basefont = (fontno & ~(FONT_BOLDUND));
if (basefont != fontno && !fontflag[basefont])
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
another_font(basefont);
Robert de Bath's patch: be much more careful about font heights and widths, including underline mode and OEM/ANSI size mismatch. [originally from svn r405]
2000-03-11 14:15:24 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
font = conf_get_fontspec(conf, CONF_font);
if (font->isbold) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fw_dontcare = FW_BOLD;
fw_bold = FW_HEAVY;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fw_dontcare = FW_DONTCARE;
fw_bold = FW_BOLD;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
c = font->charset;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
w = fw_dontcare;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
u = false;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
s = font->name;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
x = font_width;
if (fontno & FONT_WIDE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x *= 2;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontno & FONT_NARROW)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
x = (x+1)/2;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontno & FONT_OEM)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
c = OEM_CHARSET;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontno & FONT_BOLD)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
w = fw_bold;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (fontno & FONT_UNDERLINE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
u = true;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
quality = conf_get_int(conf, CONF_font_quality);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
fonts[fontno] =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
CreateFont(font_height * (1 + !!(fontno & FONT_HIGH)), x, 0, 0, w,
false, u, false, c, OUT_DEFAULT_PRECIS,
CLIP_DEFAULT_PRECIS, FONT_QUALITY(quality),
DEFAULT_PITCH | FF_DONTCARE, s);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
fontflag[fontno] = true;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
static void deinit_fonts(void)
{
int i;
for (i = 0; i < FONT_MAXNO; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (fonts[i])
DeleteObject(fonts[i]);
fonts[i] = 0;
fontflag[i] = false;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
Don't call DestroyIcon(INVALID_HANDLE_VALUE). The Windows API documentation doesn't explicitly say this is safe, and ea32967044 didn't take care over it.
2019-03-31 22:47:03 +00:00
if (trust_icon != INVALID_HANDLE_VALUE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DestroyIcon(trust_icon);
Don't call DestroyIcon(INVALID_HANDLE_VALUE). The Windows API documentation doesn't explicitly say this is safe, and ea32967044 didn't take care over it.
2019-03-31 22:47:03 +00:00
}
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
trust_icon = INVALID_HANDLE_VALUE;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_request_resize(TermWin *tw, int w, int h)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
int width, height;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Spelling fixes (just in comments). As found by a bot ( http://www.misfix.org, https://github.com/ka7/misspell_fixer ).
2017-04-15 08:06:22 +00:00
/* If the window is maximized suppress resizing attempts */
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
if (IsZoomed(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (conf_get_int(conf, CONF_resize_action) == RESIZE_TERM)
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_resize_action) == RESIZE_DISABLED) return;
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (h == term->rows && w == term->cols) return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Sanity checks ... */
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
static int first_time = 1;
static RECT ss;
switch (first_time) {
case 1:
/* Get the size of the screen */
if (get_fullscreen_rect(&ss))
/* first_time = 0 */ ;
else {
first_time = 2;
break;
}
case 0:
/* Make sure the values are sane */
width = (ss.right - ss.left - extra_width) / 4;
height = (ss.bottom - ss.top - extra_height) / 6;
if (w > width || h > height)
return;
if (w < 15)
w = 15;
if (h < 1)
h = 1;
}
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
}
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
term_size(term, h, w, conf_get_int(conf, CONF_savelines));
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_resize_action) != RESIZE_FONT &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
!IsZoomed(hwnd)) {
width = extra_width + font_width * w;
height = extra_height + font_height * h;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetWindowPos(hwnd, NULL, 0, 0, width, height,
SWP_NOACTIVATE | SWP_NOCOPYBITS |
SWP_NOMOVE | SWP_NOZORDER);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
reset_window(0);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
static void reset_window(int reinit) {
/*
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* This function decides how to resize or redraw when the
* user changes something.
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
*
* This function doesn't like to change the terminal size but if the
* font size is locked that may be it's only soluion.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int win_width, win_height, resize_action, window_border;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
RECT cr, wr;
#ifdef RDB_DEBUG_PATCH
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
debug("reset_window()\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
/* Current window sizes ... */
GetWindowRect(hwnd, &wr);
GetClientRect(hwnd, &cr);
win_width = cr.right - cr.left;
win_height = cr.bottom - cr.top;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
resize_action = conf_get_int(conf, CONF_resize_action);
window_border = conf_get_int(conf, CONF_window_border);
if (resize_action == RESIZE_DISABLED)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
reinit = 2;
RDB's general resizing cleanup. He's put his favourite resize mode back in again, but as long as it's not the default it doesn't bother me too much :-) [originally from svn r1421]
2001-11-25 18:39:57 +00:00
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Are we being forced to reload the fonts ? */
if (reinit>1) {
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -- Forced deinit\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
deinit_fonts();
init_fonts(0,0);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
/* Oh, looks like we're minimised */
if (win_width == 0 || win_height == 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Is the window out of position ? */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ( !reinit &&
(offset_width != (win_width-font_width*term->cols)/2 ||
offset_height != (win_height-font_height*term->rows)/2) ){
offset_width = (win_width-font_width*term->cols)/2;
offset_height = (win_height-font_height*term->rows)/2;
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> Reposition terminal\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
}
RDB's fix to full-screen mode. Apparently sorts out most of the fullscreen/maximised confusions, by treating fullscreen as a special case of maximised (fair enough). Removes dependency on multimon.h, but Wez thinks (though he was unable to test) that this version should naturally do the Right Thing on multi-monitor systems anyway. [originally from svn r1365]
2001-11-04 16:41:26 +00:00
if (IsZoomed(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* We're fullscreen, this means we must not change the size of
* the window so it's the font size or the terminal itself.
*/
extra_width = wr.right - wr.left - cr.right + cr.left;
extra_height = wr.bottom - wr.top - cr.bottom + cr.top;
if (resize_action != RESIZE_TERM) {
if (font_width != win_width/term->cols ||
font_height != win_height/term->rows) {
deinit_fonts();
init_fonts(win_width/term->cols, win_height/term->rows);
offset_width = (win_width-font_width*term->cols)/2;
offset_height = (win_height-font_height*term->rows)/2;
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> Z font resize to (%d, %d)\n",
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
font_width, font_height);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
} else {
if (font_width * term->cols != win_width ||
font_height * term->rows != win_height) {
/* Our only choice at this point is to change the
* size of the terminal; Oh well.
*/
term_size(term, win_height/font_height, win_width/font_width,
conf_get_int(conf, CONF_savelines));
offset_width = (win_width-font_width*term->cols)/2;
offset_height = (win_height-font_height*term->rows)/2;
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> Zoomed term_size\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
/* Hmm, a force re-init means we should ignore the current window
* so we resize to the default font size.
*/
if (reinit>0) {
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> Forced re-init\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
offset_width = offset_height = window_border;
extra_width = wr.right - wr.left - cr.right + cr.left + offset_width*2;
extra_height = wr.bottom - wr.top - cr.bottom + cr.top +offset_height*2;
if (win_width != font_width*term->cols + offset_width*2 ||
win_height != font_height*term->rows + offset_height*2) {
/* If this is too large windows will resize it to the maximum
* allowed window size, we will then be back in here and resize
* the font or terminal to fit.
*/
SetWindowPos(hwnd, NULL, 0, 0,
font_width*term->cols + extra_width,
font_height*term->rows + extra_height,
SWP_NOMOVE | SWP_NOZORDER);
}
InvalidateRect(hwnd, NULL, true);
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Okay the user doesn't want us to change the font so we try the
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
* window. But that may be too big for the screen which forces us
* to change the terminal.
*/
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if ((resize_action == RESIZE_TERM && reinit<=0) ||
(resize_action == RESIZE_EITHER && reinit<0) ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
reinit>0) {
offset_width = offset_height = window_border;
extra_width = wr.right - wr.left - cr.right + cr.left + offset_width*2;
extra_height = wr.bottom - wr.top - cr.bottom + cr.top +offset_height*2;
if (win_width != font_width*term->cols + offset_width*2 ||
win_height != font_height*term->rows + offset_height*2) {
static RECT ss;
int width, height;
get_fullscreen_rect(&ss);
width = (ss.right - ss.left - extra_width) / font_width;
height = (ss.bottom - ss.top - extra_height) / font_height;
/* Grrr too big */
if ( term->rows > height || term->cols > width ) {
if (resize_action == RESIZE_EITHER) {
/* Make the font the biggest we can */
if (term->cols > width)
font_width = (ss.right - ss.left - extra_width)
/ term->cols;
if (term->rows > height)
font_height = (ss.bottom - ss.top - extra_height)
/ term->rows;
deinit_fonts();
init_fonts(font_width, font_height);
width = (ss.right - ss.left - extra_width) / font_width;
height = (ss.bottom - ss.top - extra_height) / font_height;
} else {
if ( height > term->rows ) height = term->rows;
if ( width > term->cols ) width = term->cols;
term_size(term, height, width,
conf_get_int(conf, CONF_savelines));
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> term resize to (%d,%d)\n",
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
height, width);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
SetWindowPos(hwnd, NULL, 0, 0,
font_width*term->cols + extra_width,
font_height*term->rows + extra_height,
SWP_NOMOVE | SWP_NOZORDER);
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> window resize to (%d,%d)\n",
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
font_width*term->cols + extra_width,
font_height*term->rows + extra_height);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
/* We're allowed to or must change the font but do we want to ? */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (font_width != (win_width-window_border*2)/term->cols ||
font_height != (win_height-window_border*2)/term->rows) {
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
deinit_fonts();
init_fonts((win_width-window_border*2)/term->cols,
(win_height-window_border*2)/term->rows);
offset_width = (win_width-font_width*term->cols)/2;
offset_height = (win_height-font_height*term->rows)/2;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
extra_width = wr.right - wr.left - cr.right + cr.left +offset_width*2;
extra_height = wr.bottom - wr.top - cr.bottom + cr.top+offset_height*2;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
InvalidateRect(hwnd, NULL, true);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("reset_window() -> font resize to (%d,%d)\n",
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
font_width, font_height);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Set up kbd_codepage at the start of the program, as well as when the input locale changes. With any luck this should sort out the Polish Unicode problems. [originally from svn r1427]
2001-11-29 21:30:59 +00:00
static void set_input_locale(HKL kl)
{
char lbuf[20];
GetLocaleInfo(LOWORD(kl), LOCALE_IDEFAULTANSICODEPAGE,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lbuf, sizeof(lbuf));
Set up kbd_codepage at the start of the program, as well as when the input locale changes. With any luck this should sort out the Polish Unicode problems. [originally from svn r1427]
2001-11-29 21:30:59 +00:00
kbd_codepage = atoi(lbuf);
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void click(Mouse_Button b, int x, int y,
bool shift, bool ctrl, bool alt)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Fix double/triple click, and improve drag select [originally from svn r19]
1999-01-22 09:35:08 +00:00
int thistime = GetMessageTime();
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (send_raw_mouse &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
!(shift && conf_get_bool(conf, CONF_mouse_override))) {
lastbtn = MBT_NOTHING;
term_mouse(term, b, translate_button(b), MA_CLICK,
x, y, shift, ctrl, alt);
return;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
}
Fix double/triple click, and improve drag select [originally from svn r19]
1999-01-22 09:35:08 +00:00
if (lastbtn == b && thistime - lasttime < dbltime) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lastact = (lastact == MA_CLICK ? MA_2CLK :
lastact == MA_2CLK ? MA_3CLK :
lastact == MA_3CLK ? MA_CLICK : MA_NOTHING);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lastbtn = b;
lastact = MA_CLICK;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
if (lastact != MA_NOTHING)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_mouse(term, b, translate_button(b), lastact,
x, y, shift, ctrl, alt);
Fix double/triple click, and improve drag select [originally from svn r19]
1999-01-22 09:35:08 +00:00
lasttime = thistime;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
/*
* Translate a raw mouse button designation (LEFT, MIDDLE, RIGHT)
* into a cooked one (SELECT, EXTEND, PASTE).
*/
Fix minor breakage on Windows as a result of term_mouse revamp. [originally from svn r2722]
2003-01-25 16:22:49 +00:00
static Mouse_Button translate_button(Mouse_Button button)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
if (button == MBT_LEFT)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return MBT_SELECT;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
if (button == MBT_MIDDLE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return conf_get_int(conf, CONF_mouse_is_xterm) == 1 ?
MBT_PASTE : MBT_EXTEND;
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
if (button == MBT_RIGHT)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return conf_get_int(conf, CONF_mouse_is_xterm) == 1 ?
MBT_EXTEND : MBT_PASTE;
return 0; /* shouldn't happen */
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void show_mouseptr(bool show)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
The terminal window can now indicate that PuTTY is busy in various ways, by changing its mouse pointer. Currently this is only used in the (slightly- arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer hiding while PuTTY is busy, but preserve pointer-hiding state. Not yet implemented on the Mac. Also switch to frobbing window-class cursor in Windows rather than relying on SetCursor(). [originally from svn r5303]
2005-02-15 17:05:58 +00:00
/* NB that the counter in ShowCursor() is also frobbed by
* update_mouse_pointer() */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool cursor_visible = true;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(conf, CONF_hide_mouseptr))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
show = true; /* override if this feature disabled */
Ability to hide the mouse pointer on a keypress a la Word [originally from svn r883]
2001-01-22 16:38:43 +00:00
if (cursor_visible && !show)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ShowCursor(false);
Ability to hide the mouse pointer on a keypress a la Word [originally from svn r883]
2001-01-22 16:38:43 +00:00
else if (!cursor_visible && show)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ShowCursor(true);
Ability to hide the mouse pointer on a keypress a la Word [originally from svn r883]
2001-01-22 16:38:43 +00:00
cursor_visible = show;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool is_alt_pressed(void)
Rectangular-block selection. Enabled by Alt+drag, unless you configure it to be the default in which case it's _dis_abled by Alt+drag. [originally from svn r1350]
2001-10-31 18:50:09 +00:00
{
BYTE keystate[256];
int r = GetKeyboardState(keystate);
if (!r)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Rectangular-block selection. Enabled by Alt+drag, unless you configure it to be the default in which case it's _dis_abled by Alt+drag. [originally from svn r1350]
2001-10-31 18:50:09 +00:00
if (keystate[VK_MENU] & 0x80)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true;
Rectangular-block selection. Enabled by Alt+drag, unless you configure it to be the default in which case it's _dis_abled by Alt+drag. [originally from svn r1350]
2001-10-31 18:50:09 +00:00
if (keystate[VK_RMENU] & 0x80)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return true;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Rectangular-block selection. Enabled by Alt+drag, unless you configure it to be the default in which case it's _dis_abled by Alt+drag. [originally from svn r1350]
2001-10-31 18:50:09 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool resizing;
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static void win_seat_notify_remote_exit(Seat *seat)
Start using notify_remote_exit() in the Windows front end, in place of the previous ad-hockery which depended on the return value from select_result() and hence which will not adapt sensibly to a world in which the primary session is something local rather than a network connection. [originally from svn r6802]
2006-08-26 10:04:46 +00:00
{
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int exitcode, close_on_exit;
Start using notify_remote_exit() in the Windows front end, in place of the previous ad-hockery which depended on the return value from select_result() and hence which will not adapt sensibly to a world in which the primary session is something local rather than a network connection. [originally from svn r6802]
2006-08-26 10:04:46 +00:00
if (!session_closed &&
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
(exitcode = backend_exitcode(backend)) >= 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
close_on_exit = conf_get_int(conf, CONF_close_on_exit);
/* Abnormal exits will already have set session_closed and taken
* appropriate action. */
if (close_on_exit == FORCE_ON ||
(close_on_exit == AUTO && exitcode != INT_MAX)) {
PostQuitMessage(0);
} else {
Revamp Windows's close_session() using toplevel callbacks. Instead of setting a must_close_session flag and having special code in the message loop to check it, we'll schedule the call to close_session using the new top-level callback system. [originally from svn r10021]
2013-08-17 16:06:18 +00:00
queue_toplevel_callback(close_session, NULL);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
session_closed = true;
/* exitcode == INT_MAX indicates that the connection was closed
* by a fatal error, so an error box will be coming our way and
* we should not generate this informational one. */
if (exitcode != INT_MAX)
MessageBox(hwnd, "Connection closed by remote host",
appname, MB_OK | MB_ICONINFORMATION);
}
Start using notify_remote_exit() in the Windows front end, in place of the previous ad-hockery which depended on the return value from select_result() and hence which will not adapt sensibly to a world in which the primary session is something local rather than a network connection. [originally from svn r6802]
2006-08-26 10:04:46 +00:00
}
}
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-18 21:42:48 +00:00
void timer_change_notify(unsigned long next)
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
{
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-18 21:42:48 +00:00
unsigned long now = GETTICKCOUNT();
long ticks;
if (now - next < INT_MAX)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ticks = 0;
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-18 21:42:48 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ticks = next - now;
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
KillTimer(hwnd, TIMING_TIMER_ID);
SetTimer(hwnd, TIMING_TIMER_ID, ticks, NULL);
timing_next_time = next;
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
static void conf_cache_data(void)
{
/* Cache some items from conf to speed lookups in very hot code */
cursor_type = conf_get_int(conf, CONF_cursor_type);
vtmode = conf_get_int(conf, CONF_vtmode);
}
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
static const int clips_system[] = { CLIP_SYSTEM };
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static HDC make_hdc(void)
{
HDC hdc;
if (!hwnd)
return NULL;
hdc = GetDC(hwnd);
if (!hdc)
return NULL;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
SelectPalette(hdc, pal, false);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
return hdc;
}
static void free_hdc(HDC hdc)
{
assert(hwnd);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
SelectPalette(hdc, GetStockObject(DEFAULT_PALETTE), false);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
ReleaseDC(hwnd, hdc);
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static LRESULT CALLBACK WndProc(HWND hwnd, UINT message,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
WPARAM wParam, LPARAM lParam)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
HDC hdc;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool ignore_clip = false;
static bool need_backend_resize = false;
static bool fullscr_on_max = false;
static bool processed_resize = false;
Attempt to make Windows pointer hiding more robust by ignoring MOUSEMOVE and NCMOUSEMOVE messages where nothing actually changes. It seems Windows likes to send such messages occasionally when other stuff is going on (e.g., in other windows). (Also spotted by Franco Barber <20040122055232.GA8168@febsun.cmhnet.org>.) [originally from svn r4358]
2004-07-25 19:52:07 +00:00
static UINT last_mousemove = 0;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int resize_action;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
switch (message) {
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
case WM_TIMER:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((UINT_PTR)wParam == TIMING_TIMER_ID) {
unsigned long next;
KillTimer(hwnd, TIMING_TIMER_ID);
if (run_timers(timing_next_time, &next)) {
timer_change_notify(next);
} else {
}
}
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_CREATE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Prompt before summarily closing a session [originally from svn r272]
1999-11-04 13:44:21 +00:00
case WM_CLOSE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
char *str;
show_mouseptr(true);
str = dupprintf("%s Exit Confirmation", appname);
if (session_closed || !conf_get_bool(conf, CONF_warn_on_close) ||
MessageBox(hwnd,
"Are you sure you want to close this session?",
str, MB_ICONWARNING | MB_OKCANCEL | MB_DEFBUTTON1)
== IDOK)
DestroyWindow(hwnd);
sfree(str);
}
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_DESTROY:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
show_mouseptr(true);
PostQuitMessage(0);
return 0;
If a new session was saved from Change Settings, a side-effect on Windows was that the global `sesslist' got out of sync with the saved-sessions submenu, causing the latter to launch the wrong sessions. Also, Change Settings wasn't getting a fresh session list, so if the set of sessions had changed since session startup it wouldn't reflect that (at least until a session was saved). Fixed (on all platforms). Therefore, since the global sesslist didn't seem to be useful, I've got rid of it; config.c creates one as needed, as do the frontends. (Not tried compiling Mac changes.) Also, we now build the saved-sessions submenu on demand on Windows and Unix. (This should probably also be done on the Mac.) [originally from svn r5609]
2005-04-07 01:36:28 +00:00
case WM_INITMENUPOPUP:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((HMENU)wParam == savedsess_menu) {
/* About to pop up Saved Sessions sub-menu.
* Refresh the session list. */
get_sesslist(&sesslist, false); /* free */
get_sesslist(&sesslist, true);
update_savedsess_menu();
return 0;
}
break;
Introduce a context menu which appears on Ctrl+rightclick. This menu contains all the stuff in the System menu except for the standard System menu bits (move, resize, close etc), and also contains `Paste'. [originally from svn r3555]
2003-11-19 20:48:30 +00:00
case WM_COMMAND:
Stop putting meaning in bottom four bits of WM_SYSCOMMAND wParam [originally from svn r265]
1999-10-28 16:29:06 +00:00
case WM_SYSCOMMAND:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (wParam & ~0xF) { /* low 4 bits reserved to Windows */
case IDM_SHOWLOG:
showeventlog(hwnd);
break;
case IDM_NEWSESS:
case IDM_DUPSESS:
case IDM_SAVEDSESS:
{
char b[2048];
char *cl;
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
const char *argprefix;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool inherit_handles;
STARTUPINFO si;
PROCESS_INFORMATION pi;
HANDLE filemap = NULL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
if (restricted_acl)
argprefix = "&R";
else
argprefix = "";
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (wParam == IDM_DUPSESS) {
/*
* Allocate a file-mapping memory chunk for the
* config structure.
*/
SECURITY_ATTRIBUTES sa;
Use the BinarySink system for conf serialisation. Now instead of iterating through conf twice in separate functions, once to count up the size of the serialised data and once to write it out, I just go through once and dump it all in a strbuf. (Of course, I could still do a two-pass count-then-allocate approach easily enough in this system; nothing would stop me writing a BinarySink implementation that didn't actually store any data and just counted its size, and then I could choose at each call site whether I preferred to do it that way.)
2018-05-24 09:48:20 +00:00
strbuf *serbuf;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *p;
int size;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
Use the BinarySink system for conf serialisation. Now instead of iterating through conf twice in separate functions, once to count up the size of the serialised data and once to write it out, I just go through once and dump it all in a strbuf. (Of course, I could still do a two-pass count-then-allocate approach easily enough in this system; nothing would stop me writing a BinarySink implementation that didn't actually store any data and just counted its size, and then I could choose at each call site whether I preferred to do it that way.)
2018-05-24 09:48:20 +00:00
serbuf = strbuf_new();
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_serialise(BinarySink_UPCAST(serbuf), conf);
Use the BinarySink system for conf serialisation. Now instead of iterating through conf twice in separate functions, once to count up the size of the serialised data and once to write it out, I just go through once and dump it all in a strbuf. (Of course, I could still do a two-pass count-then-allocate approach easily enough in this system; nothing would stop me writing a BinarySink implementation that didn't actually store any data and just counted its size, and then I could choose at each call site whether I preferred to do it that way.)
2018-05-24 09:48:20 +00:00
size = serbuf->len;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = NULL;
sa.bInheritHandle = true;
filemap = CreateFileMapping(INVALID_HANDLE_VALUE,
&sa,
PAGE_READWRITE,
0, size, NULL);
if (filemap && filemap != INVALID_HANDLE_VALUE) {
p = MapViewOfFile(filemap, FILE_MAP_WRITE, 0, 0, size);
if (p) {
memcpy(p, serbuf->s, size);
UnmapViewOfFile(p);
}
}
Use the BinarySink system for conf serialisation. Now instead of iterating through conf twice in separate functions, once to count up the size of the serialised data and once to write it out, I just go through once and dump it all in a strbuf. (Of course, I could still do a two-pass count-then-allocate approach easily enough in this system; nothing would stop me writing a BinarySink implementation that didn't actually store any data and just counted its size, and then I could choose at each call site whether I preferred to do it that way.)
2018-05-24 09:48:20 +00:00
strbuf_free(serbuf);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inherit_handles = true;
cl = dupprintf("putty %s&%p:%u", argprefix,
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
filemap, (unsigned)size);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (wParam == IDM_SAVEDSESS) {
unsigned int sessno = ((lParam - IDM_SAVED_MIN)
/ MENU_SAVED_STEP) + 1;
if (sessno < (unsigned)sesslist.nsessions) {
const char *session = sesslist.sessions[sessno];
cl = dupprintf("putty %s@%s", argprefix, session);
inherit_handles = false;
} else
break;
} else /* IDM_NEWSESS */ {
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
cl = dupprintf("putty%s%s",
*argprefix ? " " : "",
argprefix);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
inherit_handles = false;
}
GetModuleFileName(NULL, b, sizeof(b) - 1);
si.cb = sizeof(si);
si.lpReserved = NULL;
si.lpDesktop = NULL;
si.lpTitle = NULL;
si.dwFlags = 0;
si.cbReserved2 = 0;
si.lpReserved2 = NULL;
CreateProcess(b, cl, NULL, NULL, inherit_handles,
NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi);
A user points out that we should free the 'hProcess' and 'hThread' handles returned in the PROCESS_INFORMATION structure after we call CreateProcess. [originally from svn r9686]
2012-10-10 18:29:16 +00:00
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (filemap)
CloseHandle(filemap);
Pass -restrict-acl, if given, through to sub-PuTTYs. This change applies to every situation when GUI PuTTY knowingly spawns another GUI PuTTY, to wit, the System menu options 'New Session', 'Duplicate Session' and the 'Saved Sessions' submenu. (Literally speaking, what we actually pass through to the sub-PuTTY's command line is not the "-restrict-acl" option itself, but a special prefix "&R", which has the same meaning but which lives in the special pre-argv-splitting command-line namespace like the magic options used for Duplicate Session and the old '@sessionname' prefix which the Saved Sessions submenu still uses. Otherwise, by the time we split up argv and recognised -restrict-acl, it would be too late to parse those other options.) One case in which PuTTY spawns a subprocess and this change _doesn't_ apply is when the subprocess is a proxy command which happens to be a Plink. Recognising Plink commands in that situation would be fragile and unreliable, and in any case if the user wants a proxy Plink to be ACL-restricted, they are in control of its exact command line so they can add -restrict-acl themselves.
2017-02-04 07:57:36 +00:00
sfree(cl);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
break;
case IDM_RESTART:
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (!backend) {
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
lp_eventlog(win_gui_logpolicy,
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
"----- Session restarted -----");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_pwron(term, false);
start_backend();
}
break;
case IDM_RECONF:
{
Conf *prev_conf;
int init_lvl = 1;
bool reconfig_result;
if (reconfiguring)
break;
else
reconfiguring = true;
/*
* Copy the current window title into the stored
* previous configuration, so that doing nothing to
* the window title field in the config box doesn't
* reset the title to its startup state.
*/
conf_set_str(conf, CONF_wintitle, window_name);
prev_conf = conf_copy(conf);
reconfig_result =
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
do_reconfig(hwnd, backend ? backend_cfg_info(backend) : 0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
reconfiguring = false;
if (!reconfig_result) {
Another big batch of memory leak fixes, again mostly on error paths. The most interesting one is printer_add_enum, which I've modified to take a char ** rather than a char * so that it can both realloc its input buffer _and_ return NULL to indicate error. [originally from svn r9959]
2013-07-22 07:11:54 +00:00
conf_free(prev_conf);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
conf_cache_data();
resize_action = conf_get_int(conf, CONF_resize_action);
{
/* Disable full-screen if resizing forbidden */
int i;
for (i = 0; i < lenof(popup_menus); i++)
EnableMenuItem(popup_menus[i].menu, IDM_FULLSCREEN,
MF_BYCOMMAND |
Fix misplaced parens in window.c. This was pointed out as a compiler warning when I test-built with up-to-date clang-cl. It looks as if it would cause the IDM_FULLSCREEN item on the system menu to be wrongly greyed/ungreyed, but in fact I think it's benign, because MF_BYCOMMAND == 0. So it's _just_ a warning fix, luckily!
2020-01-26 14:39:40 +00:00
(resize_action == RESIZE_DISABLED
? MF_GRAYED : MF_ENABLED));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Gracefully unzoom if necessary */
if (IsZoomed(hwnd) && (resize_action == RESIZE_DISABLED))
ShowWindow(hwnd, SW_RESTORE);
Another big batch of memory leak fixes, again mostly on error paths. The most interesting one is printer_add_enum, which I've modified to take a char ** rather than a char * so that it can both realloc its input buffer _and_ return NULL to indicate error. [originally from svn r9959]
2013-07-22 07:11:54 +00:00
}
Improved session logging courtesy of Roman Pompejus [originally from svn r846]
2001-01-07 18:24:59 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Pass new config data to the logging module */
log_reconfig(logctx, conf);
sfree(logpal);
/*
* Flush the line discipline's edit buffer in the
* case where local editing has just been disabled.
*/
if (ldisc) {
Fix null dereference in ldisc_configure. The IDM_RECONF handler unconditionally calls ldisc_configure to reconfigure the line discipline for the new echo/edit settings, but in fact ldisc can be NULL if no session is currently active. (Indeed, the very next line acknowledges this, by testing it for NULL before calling ldisc_send!) Thanks to Alexander Wong for the report. [originally from svn r10214]
2014-08-27 22:25:37 +00:00
ldisc_configure(ldisc, conf);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ldisc_echoedit_update(ldisc);
Fix null dereference in ldisc_configure. The IDM_RECONF handler unconditionally calls ldisc_configure to reconfigure the line discipline for the new echo/edit settings, but in fact ldisc can be NULL if no session is currently active. (Indeed, the very next line acknowledges this, by testing it for NULL before calling ldisc_send!) Thanks to Alexander Wong for the report. [originally from svn r10214]
2014-08-27 22:25:37 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (pal)
DeleteObject(pal);
logpal = NULL;
pal = NULL;
conftopalette();
init_palette();
/* Pass new config data to the terminal */
term_reconfig(term, conf);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
setup_clipboards(term, conf);
Add the Features panel, allowing you to disable a bunch of the more controversial terminal features. [originally from svn r1576]
2002-03-06 23:04:20 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Pass new config data to the back end */
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend)
backend_reconfig(backend, conf);
The back ends now contain their own copies of the Config structure, 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]
2003-01-12 14:48:29 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Screen size changed ? */
if (conf_get_int(conf, CONF_height) !=
conf_get_int(prev_conf, CONF_height) ||
conf_get_int(conf, CONF_width) !=
conf_get_int(prev_conf, CONF_width) ||
conf_get_int(conf, CONF_savelines) !=
conf_get_int(prev_conf, CONF_savelines) ||
resize_action == RESIZE_FONT ||
(resize_action == RESIZE_EITHER && IsZoomed(hwnd)) ||
resize_action == RESIZE_DISABLED)
term_size(term, conf_get_int(conf, CONF_height),
conf_get_int(conf, CONF_width),
conf_get_int(conf, CONF_savelines));
/* Enable or disable the scroll bar, etc */
{
LONG nflg, flag = GetWindowLongPtr(hwnd, GWL_STYLE);
LONG nexflag, exflag =
GetWindowLongPtr(hwnd, GWL_EXSTYLE);
nexflag = exflag;
if (conf_get_bool(conf, CONF_alwaysontop) !=
conf_get_bool(prev_conf, CONF_alwaysontop)) {
if (conf_get_bool(conf, CONF_alwaysontop)) {
nexflag |= WS_EX_TOPMOST;
SetWindowPos(hwnd, HWND_TOPMOST, 0, 0, 0, 0,
SWP_NOMOVE | SWP_NOSIZE);
} else {
nexflag &= ~(WS_EX_TOPMOST);
SetWindowPos(hwnd, HWND_NOTOPMOST, 0, 0, 0, 0,
SWP_NOMOVE | SWP_NOSIZE);
}
}
if (conf_get_bool(conf, CONF_sunken_edge))
nexflag |= WS_EX_CLIENTEDGE;
else
nexflag &= ~(WS_EX_CLIENTEDGE);
nflg = flag;
if (conf_get_bool(conf, is_full_screen() ?
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
CONF_scrollbar_in_fullscreen :
CONF_scrollbar))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nflg |= WS_VSCROLL;
else
nflg &= ~WS_VSCROLL;
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (resize_action == RESIZE_DISABLED ||
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
is_full_screen())
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nflg &= ~WS_THICKFRAME;
else
nflg |= WS_THICKFRAME;
if (resize_action == RESIZE_DISABLED)
nflg &= ~WS_MAXIMIZEBOX;
else
nflg |= WS_MAXIMIZEBOX;
if (nflg != flag || nexflag != exflag) {
if (nflg != flag)
SetWindowLongPtr(hwnd, GWL_STYLE, nflg);
if (nexflag != exflag)
SetWindowLongPtr(hwnd, GWL_EXSTYLE, nexflag);
SetWindowPos(hwnd, NULL, 0, 0, 0, 0,
SWP_NOACTIVATE | SWP_NOCOPYBITS |
SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER |
SWP_FRAMECHANGED);
init_lvl = 2;
}
}
/* Oops */
if (resize_action == RESIZE_DISABLED && IsZoomed(hwnd)) {
force_normal(hwnd);
init_lvl = 2;
}
win_set_title(wintw, conf_get_str(conf, CONF_wintitle));
if (IsIconic(hwnd)) {
SetWindowText(hwnd,
conf_get_bool(conf, CONF_win_name_always) ?
window_name : icon_name);
}
{
FontSpec *font = conf_get_fontspec(conf, CONF_font);
FontSpec *prev_font = conf_get_fontspec(prev_conf,
Change the semantics of 'FontSpec' so that it's a dynamically allocated type. The main reason for this is to stop it from taking up a fixed large amount of space in every 'struct value' subunion in conf.c, although that makes little difference so far because Filename is still doing the same thing (and is therefore next on my list). However, the removal of its arbitrary length limit is not to be sneezed at. [originally from svn r9314]
2011-10-01 17:38:59 +00:00
CONF_font);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!strcmp(font->name, prev_font->name) ||
!strcmp(conf_get_str(conf, CONF_line_codepage),
conf_get_str(prev_conf, CONF_line_codepage)) ||
font->isbold != prev_font->isbold ||
font->height != prev_font->height ||
font->charset != prev_font->charset ||
conf_get_int(conf, CONF_font_quality) !=
conf_get_int(prev_conf, CONF_font_quality) ||
conf_get_int(conf, CONF_vtmode) !=
conf_get_int(prev_conf, CONF_vtmode) ||
conf_get_int(conf, CONF_bold_style) !=
conf_get_int(prev_conf, CONF_bold_style) ||
resize_action == RESIZE_DISABLED ||
resize_action == RESIZE_EITHER ||
resize_action != conf_get_int(prev_conf,
CONF_resize_action))
init_lvl = 2;
}
InvalidateRect(hwnd, NULL, true);
reset_window(init_lvl);
conf_free(prev_conf);
}
break;
case IDM_COPYALL:
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
term_copyall(term, clips_system, lenof(clips_system));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
case IDM_COPY:
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
term_request_copy(term, clips_system, lenof(clips_system));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
case IDM_PASTE:
term_request_paste(term, CLIP_SYSTEM);
break;
case IDM_CLRSB:
term_clrsb(term);
break;
case IDM_RESET:
term_pwron(term, true);
if (ldisc)
ldisc_echoedit_update(ldisc);
break;
case IDM_ABOUT:
showabout(hwnd);
break;
case IDM_HELP:
launch_help(hwnd, NULL);
break;
case SC_MOUSEMENU:
/*
* We get this if the System menu has been activated
* using the mouse.
*/
show_mouseptr(true);
break;
Robert de Bath's `Patch.a_alt_key': clean up the handling of Alt-Space, Alt-only and the System menu. It lets Windows do more of the work, and also saves a static variable, so it must be good :-) [originally from svn r1237]
2001-09-07 21:39:03 +00:00
case SC_KEYMENU:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* We get this if the System menu has been activated
* using the keyboard. This might happen from within
* TranslateKey, in which case it really wants to be
* followed by a `space' character to actually _bring
* the menu up_ rather than just sitting there in
* `ready to appear' state.
*/
show_mouseptr(true); /* make sure pointer is visible */
if( lParam == 0 )
PostMessage(hwnd, WM_CHAR, ' ', 0);
break;
case IDM_FULLSCREEN:
flip_full_screen();
break;
default:
if (wParam >= IDM_SAVED_MIN && wParam < IDM_SAVED_MAX) {
SendMessage(hwnd, WM_SYSCOMMAND, IDM_SAVEDSESS, wParam);
}
if (wParam >= IDM_SPECIAL_MIN && wParam <= IDM_SPECIAL_MAX) {
int i = (wParam - IDM_SPECIAL_MIN) / 0x10;
/*
* Ensure we haven't been sent a bogus SYSCOMMAND
* which would cause us to reference invalid memory
* and crash. Perhaps I'm just too paranoid here.
*/
if (i >= n_specials)
break;
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend)
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(
backend, specials[i].code, specials[i].arg);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
break;
John Sullivan's patches plus more fixes: - Stop using the identifier `environ' as some platforms make it a macro - Fix silly error box at end of connection in FWHACK mode - Fix GPF on maximise-then-restore - Use SetCapture to allow drag-selecting outside the window - Correctly update window title when iconic and in win_name_always mode [originally from svn r12]
1999-01-08 13:10:19 +00:00
#define X_POS(l) ((int)(short)LOWORD(l))
#define Y_POS(l) ((int)(short)HIWORD(l))
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#define TO_CHR_X(x) ((((x)<0 ? (x)-font_width+1 : (x))-offset_width) / font_width)
#define TO_CHR_Y(y) ((((y)<0 ? (y)-font_height+1: (y))-offset_height) / font_height)
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_LBUTTONDOWN:
case WM_MBUTTONDOWN:
case WM_RBUTTONDOWN:
Wez Furlong's patch to add xterm mouse reporting and proper mouse wheel support. [originally from svn r1097]
2001-05-06 14:20:41 +00:00
case WM_LBUTTONUP:
case WM_MBUTTONUP:
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_RBUTTONUP:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (message == WM_RBUTTONDOWN &&
((wParam & MK_CONTROL) ||
(conf_get_int(conf, CONF_mouse_is_xterm) == 2))) {
POINT cursorpos;
show_mouseptr(true); /* make sure pointer is visible */
GetCursorPos(&cursorpos);
TrackPopupMenu(popup_menus[CTXMENU].menu,
TPM_LEFTALIGN | TPM_TOPALIGN | TPM_RIGHTBUTTON,
cursorpos.x, cursorpos.y,
0, hwnd, NULL);
break;
}
{
int button;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool press;
Rectangular-block selection. Enabled by Alt+drag, unless you configure it to be the default in which case it's _dis_abled by Alt+drag. [originally from svn r1350]
2001-10-31 18:50:09 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (message) {
case WM_LBUTTONDOWN:
button = MBT_LEFT;
wParam |= MK_LBUTTON;
press = true;
break;
case WM_MBUTTONDOWN:
button = MBT_MIDDLE;
wParam |= MK_MBUTTON;
press = true;
break;
case WM_RBUTTONDOWN:
button = MBT_RIGHT;
wParam |= MK_RBUTTON;
press = true;
break;
case WM_LBUTTONUP:
button = MBT_LEFT;
wParam &= ~MK_LBUTTON;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
press = false;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
case WM_MBUTTONUP:
button = MBT_MIDDLE;
wParam &= ~MK_MBUTTON;
press = false;
break;
case WM_RBUTTONUP:
button = MBT_RIGHT;
wParam &= ~MK_RBUTTON;
press = false;
break;
default: /* shouldn't happen */
button = 0;
press = false;
}
show_mouseptr(true);
/*
* Special case: in full-screen mode, if the left
* button is clicked in the very top left corner of the
* window, we put up the System menu instead of doing
* selection.
*/
{
bool mouse_on_hotspot = false;
POINT pt;
GetCursorPos(&pt);
Josh Hill's patch for full-screen mode on a multi-monitor system: clicks in the top left of the window should not be detected by comparing the coordinates with (0,0) since this won't work on secondary monitors. [originally from svn r3742]
2004-01-20 19:41:43 +00:00
#ifndef NO_MULTIMON
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
HMONITOR mon;
MONITORINFO mi;
mon = MonitorFromPoint(pt, MONITOR_DEFAULTTONULL);
if (mon != NULL) {
mi.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(mon, &mi);
if (mi.rcMonitor.left == pt.x &&
mi.rcMonitor.top == pt.y) {
mouse_on_hotspot = true;
}
}
}
Josh Hill's patch for full-screen mode on a multi-monitor system: clicks in the top left of the window should not be detected by comparing the coordinates with (0,0) since this won't work on secondary monitors. [originally from svn r3742]
2004-01-20 19:41:43 +00:00
#else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (pt.x == 0 && pt.y == 0) {
mouse_on_hotspot = true;
}
Josh Hill's patch for full-screen mode on a multi-monitor system: clicks in the top left of the window should not be detected by comparing the coordinates with (0,0) since this won't work on secondary monitors. [originally from svn r3742]
2004-01-20 19:41:43 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (is_full_screen() && press &&
button == MBT_LEFT && mouse_on_hotspot) {
SendMessage(hwnd, WM_SYSCOMMAND, SC_MOUSEMENU,
MAKELPARAM(pt.x, pt.y));
return 0;
}
}
if (press) {
click(button,
TO_CHR_X(X_POS(lParam)), TO_CHR_Y(Y_POS(lParam)),
wParam & MK_SHIFT, wParam & MK_CONTROL,
is_alt_pressed());
SetCapture(hwnd);
} else {
term_mouse(term, button, translate_button(button), MA_RELEASE,
TO_CHR_X(X_POS(lParam)),
TO_CHR_Y(Y_POS(lParam)), wParam & MK_SHIFT,
wParam & MK_CONTROL, is_alt_pressed());
if (!(wParam & (MK_LBUTTON | MK_MBUTTON | MK_RBUTTON)))
ReleaseCapture();
}
}
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_MOUSEMOVE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
/*
* Windows seems to like to occasionally send MOUSEMOVE
* events even if the mouse hasn't moved. Don't unhide
* the mouse pointer in this case.
*/
static WPARAM wp = 0;
static LPARAM lp = 0;
if (wParam != wp || lParam != lp ||
last_mousemove != WM_MOUSEMOVE) {
show_mouseptr(true);
wp = wParam; lp = lParam;
last_mousemove = WM_MOUSEMOVE;
}
}
/*
* Add the mouse position and message time to the random
* number noise.
*/
noise_ultralight(NOISE_SOURCE_MOUSEPOS, lParam);
if (wParam & (MK_LBUTTON | MK_MBUTTON | MK_RBUTTON) &&
GetCapture() == hwnd) {
Mouse_Button b;
if (wParam & MK_LBUTTON)
b = MBT_LEFT;
else if (wParam & MK_MBUTTON)
b = MBT_MIDDLE;
else
b = MBT_RIGHT;
term_mouse(term, b, translate_button(b), MA_DRAG,
TO_CHR_X(X_POS(lParam)),
TO_CHR_Y(Y_POS(lParam)), wParam & MK_SHIFT,
wParam & MK_CONTROL, is_alt_pressed());
}
return 0;
Fix problem with pointer hiding [originally from svn r964]
2001-03-02 09:25:14 +00:00
case WM_NCMOUSEMOVE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
static WPARAM wp = 0;
static LPARAM lp = 0;
if (wParam != wp || lParam != lp ||
last_mousemove != WM_NCMOUSEMOVE) {
show_mouseptr(true);
wp = wParam; lp = lParam;
last_mousemove = WM_NCMOUSEMOVE;
}
}
noise_ultralight(NOISE_SOURCE_MOUSEPOS, lParam);
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_IGNORE_CLIP:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ignore_clip = wParam; /* don't panic on DESTROYCLIPBOARD */
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_DESTROYCLIPBOARD:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!ignore_clip)
term_lost_clipboard_ownership(term, CLIP_SYSTEM);
ignore_clip = false;
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_PAINT:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
PAINTSTRUCT p;
HideCaret(hwnd);
hdc = BeginPaint(hwnd, &p);
if (pal) {
SelectPalette(hdc, pal, true);
RealizePalette(hdc);
}
/*
* We have to be careful about term_paint(). It will
* set a bunch of character cells to INVALID and then
* call do_paint(), which will redraw those cells and
* _then mark them as done_. This may not be accurate:
* when painting in WM_PAINT context we are restricted
* to the rectangle which has just been exposed - so if
* that only covers _part_ of a character cell and the
* rest of it was already visible, that remainder will
* not be redrawn at all. Accordingly, we must not
* paint any character cell in a WM_PAINT context which
* already has a pending update due to terminal output.
* The simplest solution to this - and many, many
* thanks to Hung-Te Lin for working all this out - is
* not to do any actual painting at _all_ if there's a
* pending terminal update: just mark the relevant
* character cells as INVALID and wait for the
* scheduled full update to sort it out.
*
* I have a suspicion this isn't the _right_ solution.
* An alternative approach would be to have terminal.c
* separately track what _should_ be on the terminal
* screen and what _is_ on the terminal screen, and
* have two completely different types of redraw (one
* for full updates, which syncs the former with the
* terminal itself, and one for WM_PAINT which syncs
* the latter with the former); yet another possibility
* would be to have the Windows front end do what the
* GTK one already does, and maintain a bitmap of the
* current terminal appearance so that WM_PAINT becomes
* completely trivial. However, this should do for now.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
assert(!wintw_hdc);
wintw_hdc = hdc;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_paint(term,
(p.rcPaint.left-offset_width)/font_width,
(p.rcPaint.top-offset_height)/font_height,
(p.rcPaint.right-offset_width-1)/font_width,
(p.rcPaint.bottom-offset_height-1)/font_height,
!term->window_update_pending);
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
wintw_hdc = NULL;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (p.fErase ||
p.rcPaint.left < offset_width ||
p.rcPaint.top < offset_height ||
p.rcPaint.right >= offset_width + font_width*term->cols ||
p.rcPaint.bottom>= offset_height + font_height*term->rows)
{
HBRUSH fillcolour, oldbrush;
HPEN edge, oldpen;
fillcolour = CreateSolidBrush (
colours[ATTR_DEFBG>>ATTR_BGSHIFT]);
oldbrush = SelectObject(hdc, fillcolour);
edge = CreatePen(PS_SOLID, 0,
colours[ATTR_DEFBG>>ATTR_BGSHIFT]);
oldpen = SelectObject(hdc, edge);
/*
* Jordan Russell reports that this apparently
* ineffectual IntersectClipRect() call masks a
* Windows NT/2K bug causing strange display
* problems when the PuTTY window is taller than
* the primary monitor. It seems harmless enough...
*/
IntersectClipRect(hdc,
p.rcPaint.left, p.rcPaint.top,
p.rcPaint.right, p.rcPaint.bottom);
ExcludeClipRect(hdc,
offset_width, offset_height,
offset_width+font_width*term->cols,
offset_height+font_height*term->rows);
Rectangle(hdc, p.rcPaint.left, p.rcPaint.top,
p.rcPaint.right, p.rcPaint.bottom);
/* SelectClipRgn(hdc, NULL); */
SelectObject(hdc, oldbrush);
DeleteObject(fillcolour);
SelectObject(hdc, oldpen);
DeleteObject(edge);
}
SelectObject(hdc, GetStockObject(SYSTEM_FONT));
SelectObject(hdc, GetStockObject(WHITE_PEN));
EndPaint(hwnd, &p);
ShowCaret(hwnd);
}
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_NETEVENT:
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
{
/*
* To protect against re-entrancy when Windows's recv()
* immediately triggers a new WSAAsyncSelect window
* message, we don't call select_result directly from this
* handler but instead wait until we're back out at the
* top level of the message loop.
*/
struct wm_netevent_params *params =
snew(struct wm_netevent_params);
params->wParam = wParam;
params->lParam = lParam;
queue_toplevel_callback(wm_netevent_callback, params);
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_SETFOCUS:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
term_set_focus(term, true);
CreateCaret(hwnd, caretbm, font_width, font_height);
ShowCaret(hwnd);
flash_window(0); /* stop */
compose_state = 0;
term_update(term);
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_KILLFOCUS:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
show_mouseptr(true);
term_set_focus(term, false);
DestroyCaret();
caret_x = caret_y = -1; /* ensure caret is replaced next time */
term_update(term);
break;
John Sullivan's sizetip patch - experimental [originally from svn r269]
1999-11-03 14:08:26 +00:00
case WM_ENTERSIZEMOVE:
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("WM_ENTERSIZEMOVE\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
EnableSizeTip(true);
resizing = true;
need_backend_resize = false;
break;
John Sullivan's sizetip patch - experimental [originally from svn r269]
1999-11-03 14:08:26 +00:00
case WM_EXITSIZEMOVE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
EnableSizeTip(false);
resizing = false;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("WM_EXITSIZEMOVE\n");
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (need_backend_resize) {
term_size(term, conf_get_int(conf, CONF_height),
conf_get_int(conf, CONF_width),
conf_get_int(conf, CONF_savelines));
InvalidateRect(hwnd, NULL, true);
}
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_SIZING:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* This does two jobs:
* 1) Keep the sizetip uptodate
* 2) Make sure the window size is _stepped_ in units of the font size.
*/
resize_action = conf_get_int(conf, CONF_resize_action);
if (resize_action == RESIZE_TERM ||
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
(resize_action == RESIZE_EITHER && !is_alt_pressed())) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int width, height, w, h, ew, eh;
LPRECT r = (LPRECT) lParam;
if (!need_backend_resize && resize_action == RESIZE_EITHER &&
(conf_get_int(conf, CONF_height) != term->rows ||
conf_get_int(conf, CONF_width) != term->cols)) {
/*
* Great! It seems that both the terminal size and the
* font size have been changed and the user is now dragging.
*
* It will now be difficult to get back to the configured
* font size!
*
* This would be easier but it seems to be too confusing.
*/
conf_set_int(conf, CONF_height, term->rows);
conf_set_int(conf, CONF_width, term->cols);
InvalidateRect(hwnd, NULL, true);
need_backend_resize = true;
}
width = r->right - r->left - extra_width;
height = r->bottom - r->top - extra_height;
w = (width + font_width / 2) / font_width;
if (w < 1)
w = 1;
h = (height + font_height / 2) / font_height;
if (h < 1)
h = 1;
UpdateSizeTip(hwnd, w, h);
ew = width - w * font_width;
eh = height - h * font_height;
if (ew != 0) {
if (wParam == WMSZ_LEFT ||
wParam == WMSZ_BOTTOMLEFT || wParam == WMSZ_TOPLEFT)
r->left += ew;
else
r->right -= ew;
}
if (eh != 0) {
if (wParam == WMSZ_TOP ||
wParam == WMSZ_TOPRIGHT || wParam == WMSZ_TOPLEFT)
r->top += eh;
else
r->bottom -= eh;
}
if (ew || eh)
return 1;
else
return 0;
} else {
int width, height, w, h, rv = 0;
int window_border = conf_get_int(conf, CONF_window_border);
int ex_width = extra_width + (window_border - offset_width) * 2;
int ex_height = extra_height + (window_border - offset_height) * 2;
LPRECT r = (LPRECT) lParam;
width = r->right - r->left - ex_width;
height = r->bottom - r->top - ex_height;
w = (width + term->cols/2)/term->cols;
h = (height + term->rows/2)/term->rows;
if ( r->right != r->left + w*term->cols + ex_width)
rv = 1;
if (wParam == WMSZ_LEFT ||
wParam == WMSZ_BOTTOMLEFT || wParam == WMSZ_TOPLEFT)
r->left = r->right - w*term->cols - ex_width;
else
r->right = r->left + w*term->cols + ex_width;
if (r->bottom != r->top + h*term->rows + ex_height)
rv = 1;
if (wParam == WMSZ_TOP ||
wParam == WMSZ_TOPRIGHT || wParam == WMSZ_TOPLEFT)
r->top = r->bottom - h*term->rows - ex_height;
else
r->bottom = r->top + h*term->rows + ex_height;
return rv;
}
/* break; (never reached) */
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
case WM_FULLSCR_ON_MAX:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fullscr_on_max = true;
break;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
case WM_MOVE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sys_cursor_update();
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_SIZE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
resize_action = conf_get_int(conf, CONF_resize_action);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#ifdef RDB_DEBUG_PATCH
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
debug("WM_SIZE %s (%d,%d)\n",
Start using C99 variadic macros. In the past, I've had a lot of macros which you call with double parentheses, along the lines of debug(("format string", params)), so that the inner parens protect the commas and permit the macro to treat the whole printf-style argument list as one macro argument. That's all very well, but it's a bit inconvenient (it doesn't leave you any way to implement such a macro by prepending another argument to the list), and now this code base's rules allow C99isms, I can switch all those macros to using a single pair of parens, using the C99 ability to say '...' in the parameter list of the #define and get at the corresponding suffix of the arguments as __VA_ARGS__. So I'm doing it. I've made the following printf-style macros variadic: bpp_logevent, ppl_logevent, ppl_printf and debug. While I'm here, I've also fixed up a collection of conditioned-out calls to debug() in the Windows front end which were clearly expecting a macro with a different calling syntax, because they had an integer parameter first. If I ever have a need to condition those back in, they should actually work now.
2018-12-08 20:32:31 +00:00
(wParam == SIZE_MINIMIZED) ? "SIZE_MINIMIZED":
(wParam == SIZE_MAXIMIZED) ? "SIZE_MAXIMIZED":
(wParam == SIZE_RESTORED && resizing) ? "to":
(wParam == SIZE_RESTORED) ? "SIZE_RESTORED":
"...",
LOWORD(lParam), HIWORD(lParam));
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (wParam == SIZE_MINIMIZED)
SetWindowText(hwnd,
conf_get_bool(conf, CONF_win_name_always) ?
window_name : icon_name);
if (wParam == SIZE_RESTORED || wParam == SIZE_MAXIMIZED)
SetWindowText(hwnd, window_name);
Fix resize handling when enabling and disabling full-screen mode. I'm not sure whether I broke this in the recent revamp or whether it was always broken, but: transitions in and out of full-screen mode work by first maximising or restoring the window, which triggers a WM_SIZE, whose handler then fiddles with the window style to disable or re-enable all the furniture, which in turn triggers a recursive WM_SIZE. The trouble is, after returning from the handler for the inner WM_SIZE, the rest of the outer handler runs, and its client area size is now out of date. So I've added a flag which is set when a resize is handled 'properly', so that after returning from the inner WM_SIZE handler the outer one knows not to try to redo badly work that's already been done well. [originally from svn r9056]
2010-12-27 12:58:39 +00:00
if (wParam == SIZE_RESTORED) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
processed_resize = false;
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
clear_full_screen();
Fix resize handling when enabling and disabling full-screen mode. I'm not sure whether I broke this in the recent revamp or whether it was always broken, but: transitions in and out of full-screen mode work by first maximising or restoring the window, which triggers a WM_SIZE, whose handler then fiddles with the window style to disable or re-enable all the furniture, which in turn triggers a recursive WM_SIZE. The trouble is, after returning from the handler for the inner WM_SIZE, the rest of the outer handler runs, and its client area size is now out of date. So I've added a flag which is set when a resize is handled 'properly', so that after returning from the inner WM_SIZE handler the outer one knows not to try to redo badly work that's already been done well. [originally from svn r9056]
2010-12-27 12:58:39 +00:00
if (processed_resize) {
/*
* Inhibit normal processing of this WM_SIZE; a
* secondary one was triggered just now by
* clear_full_screen which contained the correct
* client area size.
*/
return 0;
}
}
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
if (wParam == SIZE_MAXIMIZED && fullscr_on_max) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
fullscr_on_max = false;
processed_resize = false;
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
make_full_screen();
Fix resize handling when enabling and disabling full-screen mode. I'm not sure whether I broke this in the recent revamp or whether it was always broken, but: transitions in and out of full-screen mode work by first maximising or restoring the window, which triggers a WM_SIZE, whose handler then fiddles with the window style to disable or re-enable all the furniture, which in turn triggers a recursive WM_SIZE. The trouble is, after returning from the handler for the inner WM_SIZE, the rest of the outer handler runs, and its client area size is now out of date. So I've added a flag which is set when a resize is handled 'properly', so that after returning from the inner WM_SIZE handler the outer one knows not to try to redo badly work that's already been done well. [originally from svn r9056]
2010-12-27 12:58:39 +00:00
if (processed_resize) {
/*
* Inhibit normal processing of this WM_SIZE; a
* secondary one was triggered just now by
* make_full_screen which contained the correct client
* area size.
*/
return 0;
}
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
}
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
processed_resize = true;
Fix resize handling when enabling and disabling full-screen mode. I'm not sure whether I broke this in the recent revamp or whether it was always broken, but: transitions in and out of full-screen mode work by first maximising or restoring the window, which triggers a WM_SIZE, whose handler then fiddles with the window style to disable or re-enable all the furniture, which in turn triggers a recursive WM_SIZE. The trouble is, after returning from the handler for the inner WM_SIZE, the rest of the outer handler runs, and its client area size is now out of date. So I've added a flag which is set when a resize is handled 'properly', so that after returning from the inner WM_SIZE handler the outer one knows not to try to redo badly work that's already been done well. [originally from svn r9056]
2010-12-27 12:58:39 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (resize_action == RESIZE_DISABLED) {
/* A resize, well it better be a minimize. */
reset_window(-1);
} else {
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int width, height, w, h;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int window_border = conf_get_int(conf, CONF_window_border);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
width = LOWORD(lParam);
height = HIWORD(lParam);
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Windows: fix resizing of a maximised window. The RESIZE_EITHER resizing mode responds to a window resize by changing the logical terminal size if the window is shown normally, or by changing the font size to keep the terminal size the same if the resize is a transition between normal and maximised state. But a user pointed out that it's also possible for a window to receive a WM_SIZE message while _remaining_ in maximised state, and that PuTTY's resize logic didn't allow for that possibility. It occurs when there's a change in the amount of available screen space for the window to be maximised _in_: e.g. when the video resolution is reconfigured, or when you reconnect to a Remote Desktop session using a client window of a different size, or even when you toggle the 'Automatically hide the taskbar' option in the Windows taskbar settings. In that situation, the right thing seems to be for PuTTY to continue to go with the policy of changing the font size rather than the logical terminal size. In other words, we prefer to change the font size when the resize is _from_ maximised state, _to_ maximised state, _or both_. That's easily implemented by removing the check of the 'was_zoomed' flag, in the case where we've received a WM_SIZE message with the state SIZE_MAXIMIZED: once we know the transition is _to_ maximised state, it doesn't matter whether or not it was also _from_ it. (But we still set the was_zoomed flag to the most recent maximised status, so that we can recognise transitions _out_ of maximised mode.)
2019-09-08 12:40:14 +00:00
if (wParam == SIZE_MAXIMIZED) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
was_zoomed = true;
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
prev_rows = term->rows;
prev_cols = term->cols;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (resize_action == RESIZE_TERM) {
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
w = width / font_width;
if (w < 1) w = 1;
h = height / font_height;
if (h < 1) h = 1;
WM_SIZE/SIZE_MAXIMIZED can show up even during an interactive resize, so we should ensure we treat it the same way as other WM_SIZEs that show up during that time: set the width and height in conf, and set the flag to have that width and height enacted on WM_EXITSIZEMOVE. Fixes a bug in which dragging a PuTTY window directly from the Win7 snapped-to-half-screen position to the snapped-to-maximised state would leave the terminal in the pre-snapped size. [originally from svn r9404]
2012-02-05 10:08:20 +00:00
if (resizing) {
/*
* As below, if we're in the middle of an
* interactive resize we don't call
* back->size. In Windows 7, this case can
* arise in maximisation as well via the Aero
* snap UI.
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
need_backend_resize = true;
WM_SIZE/SIZE_MAXIMIZED can show up even during an interactive resize, so we should ensure we treat it the same way as other WM_SIZEs that show up during that time: set the width and height in conf, and set the flag to have that width and height enacted on WM_EXITSIZEMOVE. Fixes a bug in which dragging a PuTTY window directly from the Win7 snapped-to-half-screen position to the snapped-to-maximised state would leave the terminal in the pre-snapped size. [originally from svn r9404]
2012-02-05 10:08:20 +00:00
conf_set_int(conf, CONF_height, h);
conf_set_int(conf, CONF_width, w);
} else {
term_size(term, h, w,
conf_get_int(conf, CONF_savelines));
}
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
}
reset_window(0);
} else if (wParam == SIZE_RESTORED && was_zoomed) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
was_zoomed = false;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (resize_action == RESIZE_TERM) {
w = (width-window_border*2) / font_width;
Pay attention to the width and height provided in WM_SIZE even when restoring a maximised window. Failure to do this was noticeable in the following scenario (again using Aero UI enhancements): 1. resize window using topmost resize handle, and move pointer to top of screen which 'maximises' the window vertically 2. now maximise the window properly using the maximise button in top right 3. now restore. Notepad restores to its position before step 1, because Aero remembers that position for the purpose, but PuTTY thinks it knows better. Only now it doesn't any more. [originally from svn r9041]
2010-12-22 16:14:11 +00:00
if (w < 1) w = 1;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
h = (height-window_border*2) / font_height;
Pay attention to the width and height provided in WM_SIZE even when restoring a maximised window. Failure to do this was noticeable in the following scenario (again using Aero UI enhancements): 1. resize window using topmost resize handle, and move pointer to top of screen which 'maximises' the window vertically 2. now maximise the window properly using the maximise button in top right 3. now restore. Notepad restores to its position before step 1, because Aero remembers that position for the purpose, but PuTTY thinks it knows better. Only now it doesn't any more. [originally from svn r9041]
2010-12-22 16:14:11 +00:00
if (h < 1) h = 1;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
term_size(term, h, w, conf_get_int(conf, CONF_savelines));
Another fix to yesterday's window-resizing revamp: when restoring from maximised state, we must be sure to disable the window offset used to centre the terminal in cases where the window is non-negotiably the wrong size (e.g. maximised). Hence we must call reset_window after our terminal resize. [originally from svn r9044]
2010-12-23 15:44:20 +00:00
reset_window(2);
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
} else if (resize_action != RESIZE_FONT)
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
reset_window(2);
else
reset_window(0);
} else if (wParam == SIZE_MINIMIZED) {
/* do nothing */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (resize_action == RESIZE_TERM ||
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
(resize_action == RESIZE_EITHER &&
The special treatment of Alt-resize (to cause resizing to affect the font instead of the terminal size) should only be active in RESIZE_EITHER mode - in RESIZE_TERM it is worse than useless. [originally from svn r9045]
2010-12-23 17:16:19 +00:00
!is_alt_pressed())) {
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
w = (width-window_border*2) / font_width;
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
if (w < 1) w = 1;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
h = (height-window_border*2) / font_height;
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
if (h < 1) h = 1;
if (resizing) {
/*
* Don't call back->size in mid-resize. (To
* prevent massive numbers of resize events
* getting sent down the connection during an NT
* opaque drag.)
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
need_backend_resize = true;
conf_set_int(conf, CONF_height, h);
conf_set_int(conf, CONF_width, w);
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
} else {
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
term_size(term, h, w, conf_get_int(conf, CONF_savelines));
Reorganise handling of WM_SIZE to fix two generality problems. Firstly, maximise and restore events were expected never to occur during an interactive resize process (i.e. between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE), but in fact Aero now allows this to happen if you move the pointer to the top of the screen while dragging the window. Secondly, plain old WM_SIZE events were expected never to occur _outside_ interactive resizes, but Aero permits that too (e.g. Windows-left and Windows-right), and also third-party window repositioning tools will send these. [originally from svn r9040]
2010-12-22 15:49:33 +00:00
}
} else {
reset_window(0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
sys_cursor_update();
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_VSCROLL:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (LOWORD(wParam)) {
case SB_BOTTOM:
term_scroll(term, -1, 0);
break;
case SB_TOP:
term_scroll(term, +1, 0);
break;
case SB_LINEDOWN:
term_scroll(term, 0, +1);
break;
case SB_LINEUP:
term_scroll(term, 0, -1);
break;
case SB_PAGEDOWN:
term_scroll(term, 0, +term->rows / 2);
break;
case SB_PAGEUP:
term_scroll(term, 0, -term->rows / 2);
break;
case SB_THUMBPOSITION:
case SB_THUMBTRACK:
/*
* Use GetScrollInfo instead of HIWORD(wParam) to get
* 32-bit scroll position.
*/
{
SCROLLINFO si;
si.cbSize = sizeof(si);
si.fMask = SIF_TRACKPOS;
if (GetScrollInfo(hwnd, SB_VERT, &si) == 0)
si.nTrackPos = HIWORD(wParam);
term_scroll(term, 1, si.nTrackPos);
}
break;
}
break;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
case WM_PALETTECHANGED:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((HWND) wParam != hwnd && pal != NULL) {
HDC hdc = make_hdc();
if (hdc) {
if (RealizePalette(hdc) > 0)
UpdateColors(hdc);
free_hdc(hdc);
}
}
break;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_QUERYNEWPALETTE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (pal != NULL) {
HDC hdc = make_hdc();
if (hdc) {
if (RealizePalette(hdc) > 0)
UpdateColors(hdc);
free_hdc(hdc);
return true;
}
}
return false;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_KEYDOWN:
case WM_SYSKEYDOWN:
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
case WM_KEYUP:
case WM_SYSKEYUP:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Add the scan code and keypress timing to the random
* number noise.
*/
noise_ultralight(NOISE_SOURCE_KEY, lParam);
/*
* We don't do TranslateMessage since it disassociates the
* resulting CHAR message from the KEYDOWN that sparked it,
* which we occasionally don't want. Instead, we process
* KEYDOWN, and call the Win32 translator functions so that
* we get the translations under _our_ control.
*/
{
unsigned char buf[20];
int len;
if (wParam == VK_PROCESSKEY || /* IME PROCESS key */
wParam == VK_PACKET) { /* 'this key is a Unicode char' */
if (message == WM_KEYDOWN) {
MSG m;
m.hwnd = hwnd;
m.message = WM_KEYDOWN;
m.wParam = wParam;
m.lParam = lParam & 0xdfff;
TranslateMessage(&m);
} else break; /* pass to Windows for default processing */
} else {
len = TranslateKey(message, wParam, lParam, buf);
if (len == -1)
return DefWindowProcW(hwnd, message, wParam, lParam);
if (len != 0) {
/*
* We need not bother about stdin backlogs
* here, because in GUI PuTTY we can't do
* anything about it anyway; there's no means
* of asking Windows to hold off on KEYDOWN
* messages. We _have_ to buffer everything
* we're sent.
*/
term_keyinput(term, -1, buf, len);
show_mouseptr(false);
}
}
}
return 0;
case WM_INPUTLANGCHANGE:
/* wParam == Font number */
/* lParam == Locale */
set_input_locale((HKL)lParam);
sys_cursor_update();
break;
case WM_IME_STARTCOMPOSITION:
{
HIMC hImc = ImmGetContext(hwnd);
ImmSetCompositionFont(hImc, &lfont);
ImmReleaseContext(hwnd, hImc);
}
break;
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
case WM_IME_COMPOSITION:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{
HIMC hIMC;
int n;
char *buff;
Jaeyoun Chung's mysterious patch that apparently makes Korean input work properly: call luni_send() one character at a time rather than all together after WM_IME_COMPOSITION. [originally from svn r1494]
2001-12-15 11:10:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (osPlatformId == VER_PLATFORM_WIN32_WINDOWS ||
osPlatformId == VER_PLATFORM_WIN32s)
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
break; /* no Unicode */
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((lParam & GCS_RESULTSTR) == 0) /* Composition unfinished. */
break; /* fall back to DefWindowProc */
hIMC = ImmGetContext(hwnd);
n = ImmGetCompositionStringW(hIMC, GCS_RESULTSTR, NULL, 0);
if (n > 0) {
int i;
buff = snewn(n, char);
ImmGetCompositionStringW(hIMC, GCS_RESULTSTR, buff, n);
/*
* Jaeyoun Chung reports that Korean character
* input doesn't work correctly if we do a single
* term_keyinputw covering the whole of buff. So
* instead we send the characters one by one.
*/
/* don't divide SURROGATE PAIR */
if (ldisc) {
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
for (i = 0; i < n; i += 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
WCHAR hs = *(unsigned short *)(buff+i);
if (IS_HIGH_SURROGATE(hs) && i+2 < n) {
WCHAR ls = *(unsigned short *)(buff+i+2);
if (IS_LOW_SURROGATE(ls)) {
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(
term, (unsigned short *)(buff+i), 2);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
i += 2;
continue;
}
}
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(
term, (unsigned short *)(buff+i), 1);
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
free(buff);
}
ImmReleaseContext(hwnd, hIMC);
return 1;
}
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
case WM_IME_CHAR:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (wParam & 0xFF00) {
char buf[2];
Chinese support patch from zmx@cdpa.nsysu.edu.tw [originally from svn r740]
2000-10-20 18:36:15 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
buf[1] = wParam;
buf[0] = wParam >> 8;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(term, kbd_codepage, buf, 2);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
char c = (unsigned char) wParam;
term_seen_key_event(term);
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinput(term, kbd_codepage, &c, 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
return (0);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
case WM_CHAR:
case WM_SYSCHAR:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Nevertheless, we are prepared to deal with WM_CHAR
* messages, should they crop up. So if someone wants to
* post the things to us as part of a macro manoeuvre,
* we're ready to cope.
*/
{
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
static wchar_t pending_surrogate = 0;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wchar_t c = wParam;
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
if (IS_HIGH_SURROGATE(c)) {
pending_surrogate = c;
} else if (IS_SURROGATE_PAIR(pending_surrogate, c)) {
wchar_t pair[2];
pair[0] = pending_surrogate;
pair[1] = c;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(term, pair, 2);
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
} else if (!IS_SURROGATE(c)) {
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(term, &c, 1);
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
return 0;
Handle WM_SYSCOLORCHANGE if using system colours. (Resets the whole palette, whereas ideally it would restrict itself to the affected colour slots.) [originally from svn r4505]
2004-08-27 12:24:08 +00:00
case WM_SYSCOLORCHANGE:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (conf_get_bool(conf, CONF_system_colour)) {
/* Refresh palette from system colours. */
/* XXX actually this zaps the entire palette. */
systopalette();
init_palette();
/* Force a repaint of the terminal window. */
term_invalidate(term);
}
break;
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
case WM_GOT_CLIPDATA:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
process_clipdata((HGLOBAL)lParam, wParam);
return 0;
A contributor tells me that WM_MOUSEWHEEL is not supported in Win95, and offers a patch that uses RegisterMessage() to acquire the correct dynamic message number to use instead. [originally from svn r1499]
2001-12-15 14:30:58 +00:00
default:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (message == wm_mousewheel || message == WM_MOUSEWHEEL) {
bool shift_pressed = false, control_pressed = false;
if (message == WM_MOUSEWHEEL) {
wheel_accumulator += (short)HIWORD(wParam);
shift_pressed=LOWORD(wParam) & MK_SHIFT;
control_pressed=LOWORD(wParam) & MK_CONTROL;
} else {
BYTE keys[256];
wheel_accumulator += (int)wParam;
if (GetKeyboardState(keys)!=0) {
shift_pressed=keys[VK_SHIFT]&0x80;
control_pressed=keys[VK_CONTROL]&0x80;
}
}
/* process events when the threshold is reached */
while (abs(wheel_accumulator) >= WHEEL_DELTA) {
int b;
/* reduce amount for next time */
if (wheel_accumulator > 0) {
b = MBT_WHEEL_UP;
wheel_accumulator -= WHEEL_DELTA;
} else if (wheel_accumulator < 0) {
b = MBT_WHEEL_DOWN;
wheel_accumulator += WHEEL_DELTA;
} else
break;
if (send_raw_mouse &&
!(conf_get_bool(conf, CONF_mouse_override) &&
Sumudu Fernando points out that in the big r9214 destabilisation I mistakenly rearranged the logic in an if statement in window.c, with the effect that scroll-wheel events are no longer sent via xterm mouse tracking. Put it back to the way it was. [originally from svn r9679] [r9214 == a1f3b7a358adaa7c2a98359cd0373aa823eeb14b]
2012-10-02 19:31:33 +00:00
shift_pressed)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Mouse wheel position is in screen coordinates for
* some reason */
POINT p;
p.x = X_POS(lParam); p.y = Y_POS(lParam);
if (ScreenToClient(hwnd, &p)) {
/* send a mouse-down followed by a mouse up */
term_mouse(term, b, translate_button(b),
MA_CLICK,
TO_CHR_X(p.x),
TO_CHR_Y(p.y), shift_pressed,
control_pressed, is_alt_pressed());
} /* else: not sure when this can fail */
} else {
/* trigger a scroll */
term_scroll(term, 0,
b == MBT_WHEEL_UP ?
-term->rows / 2 : term->rows / 2);
}
}
return 0;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Add comments about default processing in DialogProc/WindowProc, since I often forget the rules. [originally from svn r5532]
2005-03-20 22:28:13 +00:00
/*
* Any messages we don't process completely above are passed through to
* DefWindowProc() for default processing.
*/
Turn the Windows PuTTY main window into a Unicode window. This causes WM_CHAR messages sent to us to have a wParam containing a 16-bit value encoded in UTF-16, rather than an 8-bit value encoded in the system code page. As far as I can tell, there aren't many other knock-on effects - e.g. you can still interact with the window using ordinary char-based API functions such as SetWindowText, and the Windows API will do the necessary conversions behind the scenes. However, even so, I'm half expecting some sort of unforeseen bug to show up as a result of this.
2015-07-27 19:06:02 +00:00
return DefWindowProcW(hwnd, message, wParam, lParam);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Add an invisible System Caret for blind-helper-software to track [originally from svn r627]
2000-09-25 16:17:53 +00:00
/*
* Move the system caret. (We maintain one, even though it's
* invisible, for the benefit of blind people: apparently some
* helper software tracks the system caret, so we should arrange to
* have one.)
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_set_cursor_pos(TermWin *tw, int x, int y)
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
{
int cx, cy;
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (!term->has_focus) return;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
/*
* Avoid gratuitously re-updating the cursor position and IMM
* window if there's no actual change required.
*/
cx = x * font_width + offset_width;
cy = y * font_height + offset_height;
if (cx == caret_x && cy == caret_y)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
caret_x = cx;
caret_y = cy;
sys_cursor_update();
}
static void sys_cursor_update(void)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
COMPOSITIONFORM cf;
HIMC hIMC;
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (!term->has_focus) return;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
if (caret_x < 0 || caret_y < 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
SetCaretPos(caret_x, caret_y);
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
/* IMM calls on Win98 and beyond only */
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
if (osPlatformId == VER_PLATFORM_WIN32s) return; /* 3.11 */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
if (osPlatformId == VER_PLATFORM_WIN32_WINDOWS &&
osMinorVersion == 0) return; /* 95 */
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
/* we should have the IMM functions */
hIMC = ImmGetContext(hwnd);
cf.dwStyle = CFS_POINT;
This should fix the busy-wait problem with the IME. [originally from svn r1512]
2001-12-20 14:18:01 +00:00
cf.ptCurrentPos.x = caret_x;
cf.ptCurrentPos.y = caret_y;
Glenn Maynard's IME patch [originally from svn r1172]
2001-08-04 15:15:07 +00:00
ImmSetCompositionWindow(hIMC, &cf);
ImmReleaseContext(hwnd, hIMC);
Add an invisible System Caret for blind-helper-software to track [originally from svn r627]
2000-09-25 16:17:53 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Draw a line of text in the window, at given character
* coordinates, in given attributes.
*
* We are allowed to fiddle with the contents of `text'.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void do_text_internal(
int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
COLORREF fg, bg, t;
int nfg, nbg, nfont;
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
RECT line_box;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool force_manual_underline = false;
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
int fnt_width, char_width;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
int text_adjust = 0;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
int xoffset = 0;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int maxlen, remaining;
bool opaque;
bool is_cursor = false;
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
static int *lpDx = NULL;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
static size_t lpDx_len = 0;
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
int *lpDx_maybe;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
int len2; /* for SURROGATE PAIR */
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
lattr &= LATTR_MODE;
char_width = fnt_width = font_width * (1 + (lattr != LATTR_NORM));
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (attr & ATTR_WIDE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char_width *= 2;
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Only want the left half of double width lines */
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (lattr != LATTR_NORM && x*2 >= term->cols)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
x *= fnt_width;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
y *= font_height;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
x += offset_width;
y += offset_height;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if ((attr & TATTR_ACTCURS) && (cursor_type == 0 || term->big_cursor)) {
Make the cursor colour override true colour. Otherwise, moving the cursor (at least in active, filled-cell mode) on to a true-coloured character cell causes it to vanish completely because the cell's colours override the thing that differentiates the cursor.
2017-10-05 19:30:04 +00:00
truecolour.fg = truecolour.bg = optionalrgb_none;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
attr &= ~(ATTR_REVERSE|ATTR_BLINK|ATTR_COLOURS|ATTR_DIM);
/* cursor fg and bg */
attr |= (260 << ATTR_FGSHIFT) | (261 << ATTR_BGSHIFT);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
is_cursor = true;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
nfont = 0;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (vtmode == VT_POORMAN && lattr != LATTR_NORM) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Assume a poorman font is borken in other ways too. */
lattr = LATTR_WIDE;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (lattr) {
case LATTR_NORM:
break;
case LATTR_WIDE:
nfont |= FONT_WIDE;
break;
default:
nfont |= FONT_WIDE + FONT_HIGH;
break;
}
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
if (attr & ATTR_NARROW)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont |= FONT_NARROW;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Patch from Robert de Bath to ifdef out the Windows-specific hack for the offset horizontal line characters in the VT100 line-drawing set (o,p,r,s), so that no trace of it - and hence no pointless performance hit - is compiled into the cross-platform modules on non-Windows platforms. [originally from svn r9467]
2012-04-22 14:22:10 +00:00
#ifdef USES_VTLINE_HACK
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
/* Special hack for the VT100 linedraw glyphs. */
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if (text[0] >= 0x23BA && text[0] <= 0x23BD) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch ((unsigned char) (text[0])) {
case 0xBA:
text_adjust = -2 * font_height / 5;
break;
case 0xBB:
text_adjust = -1 * font_height / 5;
break;
case 0xBC:
text_adjust = font_height / 5;
break;
case 0xBD:
text_adjust = 2 * font_height / 5;
break;
}
if (lattr == LATTR_TOP || lattr == LATTR_BOT)
text_adjust *= 2;
text[0] = ucsdata.unitab_xterm['q'];
if (attr & ATTR_UNDER) {
attr &= ~ATTR_UNDER;
force_manual_underline = true;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Patch from Robert de Bath to ifdef out the Windows-specific hack for the offset horizontal line characters in the VT100 line-drawing set (o,p,r,s), so that no trace of it - and hence no pointless performance hit - is compiled into the cross-platform modules on non-Windows platforms. [originally from svn r9467]
2012-04-22 14:22:10 +00:00
#endif
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
/* Anything left as an original character set is unprintable. */
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
if (DIRECT_CHAR(text[0]) &&
(len < 2 || !IS_SURROGATE_PAIR(text[0], text[1]))) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
for (i = 0; i < len; i++)
text[i] = 0xFFFD;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
/* OEM CP */
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
if ((text[0] & CSET_MASK) == CSET_OEMCP)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont |= FONT_OEM;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
xterm apparently supports ESC[90m through ESC[97m to set bright foreground colours, and ESC[100m through ESC[107m to set bright background colours. Hence, so do we. Bright-foreground is distinguishable from bold, and bright-background distinguishable from blink, when it leaves terminal.c; the front end may then choose to display them in the same way if it's configured to do so. This change makes the xterm backend for Turbo Vision (!!!) work properly. Untested on Mac. [originally from svn r2734]
2003-01-27 23:03:31 +00:00
nfg = ((attr & ATTR_FGMASK) >> ATTR_FGSHIFT);
nbg = ((attr & ATTR_BGMASK) >> ATTR_BGSHIFT);
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_FONT && (attr & ATTR_BOLD))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont |= FONT_BOLD;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (und_mode == UND_FONT && (attr & ATTR_UNDER))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont |= FONT_UNDERLINE;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
another_font(nfont);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (!fonts[nfont]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (nfont & FONT_UNDERLINE)
force_manual_underline = true;
/* Don't do the same for manual bold, it could be bad news. */
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont &= ~(FONT_BOLD | FONT_UNDERLINE);
RDB's patch: - use WM_TIMER for various things (blinking cursor; updates while moving/sizing; coping with overloading influx of netevents) - clip text output to avoid underlines outside character cell - even more careful font selection (we can now do OEMANSI by default) - a few extra keyboard mappings from the VTxxx terminals [originally from svn r418]
2000-03-17 10:34:41 +00:00
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
another_font(nfont);
if (!fonts[nfont])
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
nfont = FONT_NORMAL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (attr & ATTR_REVERSE) {
Make reverse video interact correctly with true colour. ATTR_REVERSE was being handled in the front ends, and was causing the foreground and background colours to be switched. (I'm not completely sure why I made that design decision; it might be purely historical, but then again, it might also be because reverse video is one effect on the fg and bg colours that must still be performed even in unusual frontend-specific situations like display-driven monochrome mode.) This affected both explicit reverse video enabled using SGR 7, and also the transient reverse video arising from mouse selection. Thanks to Markus Gans for reporting the bug in the latter, which when I investigated it turned out to affect the former as well.
2017-10-08 12:49:54 +00:00
struct optionalrgb trgb;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
t = nfg;
nfg = nbg;
nbg = t;
Make reverse video interact correctly with true colour. ATTR_REVERSE was being handled in the front ends, and was causing the foreground and background colours to be switched. (I'm not completely sure why I made that design decision; it might be purely historical, but then again, it might also be because reverse video is one effect on the fg and bg colours that must still be performed even in unusual frontend-specific situations like display-driven monochrome mode.) This affected both explicit reverse video enabled using SGR 7, and also the transient reverse video arising from mouse selection. Thanks to Markus Gans for reporting the bug in the latter, which when I investigated it turned out to affect the former as well.
2017-10-08 12:49:54 +00:00
trgb = truecolour.fg;
truecolour.fg = truecolour.bg;
truecolour.bg = trgb;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_colours && (attr & ATTR_BOLD) && !is_cursor) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (nfg < 16) nfg |= 8;
else if (nfg >= 256) nfg |= 1;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_colours && (attr & ATTR_BLINK)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (nbg < 16) nbg |= 8;
else if (nbg >= 256) nbg |= 1;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
}
Disable true colour on monochrome or paletted displays. I'm not sure if any X11 monochrome visuals or Windows paletted display modes are still around, but just in case they are, we shouldn't attempt true colour on either kind of display.
2017-10-05 19:30:09 +00:00
if (!pal && truecolour.fg.enabled)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fg = RGB(truecolour.fg.r, truecolour.fg.g, truecolour.fg.b);
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fg = colours[nfg];
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
Disable true colour on monochrome or paletted displays. I'm not sure if any X11 monochrome visuals or Windows paletted display modes are still around, but just in case they are, we shouldn't attempt true colour on either kind of display.
2017-10-05 19:30:09 +00:00
if (!pal && truecolour.bg.enabled)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bg = RGB(truecolour.bg.r, truecolour.bg.g, truecolour.bg.b);
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bg = colours[nbg];
Support ESC[38;2;R;G;Bm for 24-bit true colour. This is a heavily rewritten version of a patch originally by Lorenz Diener; it was tidied up somewhat by Christian Brabandt, and then tidied up more by me. The basic idea is to add to the termchar structure a pair of small structs encoding 24-bit RGB values, each with a flag indicating whether it's turned on; if it is, it overrides any other specification of fg or bg colour for that character cell. I've added a test line to colours.txt containing a few example colours from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run the whole of rgb.txt through this treatment, with a command such as perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
2017-09-30 16:32:32 +00:00
Support SGR 2 to dim the foreground colour. I've done this on a 'where possible' basis: in Windows paletted mode (in case anyone is still using an old enough graphics card to need that!) I simply haven't bothered, and will completely ignore the dim flag.
2017-10-05 20:02:56 +00:00
if (!pal && (attr & ATTR_DIM)) {
fg = RGB(GetRValue(fg) * 2 / 3,
GetGValue(fg) * 2 / 3,
GetBValue(fg) * 2 / 3);
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SelectObject(wintw_hdc, fonts[nfont]);
SetTextColor(wintw_hdc, fg);
SetBkColor(wintw_hdc, bg);
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
if (attr & TATTR_COMBINING)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetBkMode(wintw_hdc, TRANSPARENT);
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetBkMode(wintw_hdc, OPAQUE);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
line_box.left = x;
line_box.top = y;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
line_box.right = x + char_width * len;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
line_box.bottom = y + font_height;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
/* adjust line_box.right for SURROGATE PAIR & VARIATION SELECTOR */
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
int rc_width = 0;
for (i = 0; i < len ; i++) {
if (i+1 < len && IS_HIGH_VARSEL(text[i], text[i+1])) {
i++;
} else if (i+1 < len && IS_SURROGATE_PAIR(text[i], text[i+1])) {
rc_width += char_width;
i++;
} else if (IS_LOW_VARSEL(text[i])) {
/* do nothing */
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
rc_width += char_width;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
line_box.right = line_box.left + rc_width;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* Only want the left half of double width lines */
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (line_box.right > font_width*term->cols+offset_width)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
line_box.right = font_width*term->cols+offset_width;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
if (font_varpitch) {
/*
* If we're using a variable-pitch font, we unconditionally
* draw the glyphs one at a time and centre them in their
* character cells (which means in particular that we must
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
* disable the lpDx mechanism). This gives slightly odd but
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
* generally reasonable results.
*/
xoffset = char_width / 2;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetTextAlign(wintw_hdc, TA_TOP | TA_CENTER | TA_NOUPDATECP);
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx_maybe = NULL;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
maxlen = 1;
} else {
/*
* In a fixed-pitch font, we draw the whole string in one go
* in the normal way.
*/
xoffset = 0;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetTextAlign(wintw_hdc, TA_TOP | TA_LEFT | TA_NOUPDATECP);
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx_maybe = lpDx;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
maxlen = len;
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
opaque = true; /* start by erasing the rectangle */
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
for (remaining = len; remaining > 0;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
text += len, remaining -= len, x += char_width * len2) {
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
len = (maxlen < remaining ? maxlen : remaining);
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
/* don't divide SURROGATE PAIR and VARIATION SELECTOR */
len2 = len;
if (maxlen == 1) {
if (remaining >= 1 && IS_SURROGATE_PAIR(text[0], text[1]))
len++;
if (remaining-len >= 1 && IS_LOW_VARSEL(text[len]))
len++;
else if (remaining-len >= 2 &&
IS_HIGH_VARSEL(text[len], text[len+1]))
len += 2;
}
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (len > lpDx_len) {
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarray(lpDx, lpDx_len, len);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (lpDx_maybe) lpDx_maybe = lpDx;
}
Bug fix from Robert de Bath: since lpDx_maybe is always supposed to equal either lpDx or NULL, we mustn't forget to update it when we realloc lpDx. [originally from svn r9526]
2012-05-13 15:59:22 +00:00
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
{
int i;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
/* only last char has dx width in SURROGATE PAIR and
* VARIATION sequence */
for (i = 0; i < len; i++) {
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx[i] = char_width;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
if (i+1 < len && IS_HIGH_VARSEL(text[i], text[i+1])) {
if (i > 0) lpDx[i-1] = 0;
lpDx[i] = 0;
i++;
lpDx[i] = char_width;
} else if (i+1 < len && IS_SURROGATE_PAIR(text[i],text[i+1])) {
lpDx[i] = 0;
i++;
lpDx[i] = char_width;
} else if (IS_LOW_VARSEL(text[i])) {
if (i > 0) lpDx[i-1] = 0;
lpDx[i] = char_width;
}
}
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
}
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
/* We're using a private area for direct to font. (512 chars.) */
if (ucsdata.dbcs_screenfont && (text[0] & CSET_MASK) == CSET_ACP) {
/* Ho Hum, dbcs fonts are a PITA! */
/* To display on W9x I have to convert to UCS */
static wchar_t *uni_buf = 0;
static int uni_len = 0;
int nlen, mptr;
if (len > uni_len) {
sfree(uni_buf);
uni_len = len;
uni_buf = snewn(uni_len, wchar_t);
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
for(nlen = mptr = 0; mptr<len; mptr++) {
uni_buf[nlen] = 0xFFFD;
if (IsDBCSLeadByteEx(ucsdata.font_codepage,
(BYTE) text[mptr])) {
char dbcstext[2];
dbcstext[0] = text[mptr] & 0xFF;
dbcstext[1] = text[mptr+1] & 0xFF;
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx[nlen] += char_width;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
MultiByteToWideChar(ucsdata.font_codepage, MB_USEGLYPHCHARS,
dbcstext, 2, uni_buf+nlen, 1);
mptr++;
}
else
{
char dbcstext[1];
dbcstext[0] = text[mptr] & 0xFF;
MultiByteToWideChar(ucsdata.font_codepage, MB_USEGLYPHCHARS,
dbcstext, 1, uni_buf+nlen, 1);
}
nlen++;
}
if (nlen <= 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return; /* Eeek! */
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
ExtTextOutW(wintw_hdc, x + xoffset,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr == LATTR_BOT) + text_adjust,
ETO_CLIPPED | (opaque ? ETO_OPAQUE : 0),
&line_box, uni_buf, nlen,
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx_maybe);
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_SHADOW && (attr & ATTR_BOLD)) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetBkMode(wintw_hdc, TRANSPARENT);
ExtTextOutW(wintw_hdc, x + xoffset - 1,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr ==
LATTR_BOT) + text_adjust,
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
ETO_CLIPPED, &line_box, uni_buf, nlen, lpDx_maybe);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
}
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
lpDx[0] = -1;
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
} else if (DIRECT_FONT(text[0])) {
static char *directbuf = NULL;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
static size_t directlen = 0;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 20:07:30 +00:00
sgrowarray(directbuf, directlen, len);
for (size_t i = 0; i < len; i++)
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
directbuf[i] = text[i] & 0xFF;
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
ExtTextOut(wintw_hdc, x + xoffset,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr == LATTR_BOT) + text_adjust,
ETO_CLIPPED | (opaque ? ETO_OPAQUE : 0),
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
&line_box, directbuf, len, lpDx_maybe);
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_SHADOW && (attr & ATTR_BOLD)) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetBkMode(wintw_hdc, TRANSPARENT);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
/* GRR: This draws the character outside its box and
* can leave 'droppings' even with the clip box! I
* suppose I could loop it one character at a time ...
* yuk.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
* Or ... I could do a test print with "W", and use +1
* or -1 for this shift depending on if the leftmost
* column is blank...
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
ExtTextOut(wintw_hdc, x + xoffset - 1,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr ==
LATTR_BOT) + text_adjust,
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
ETO_CLIPPED, &line_box, directbuf, len, lpDx_maybe);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
}
} else {
/* And 'normal' unicode characters */
static WCHAR *wbuf = NULL;
static int wlen = 0;
int i;
if (wlen < len) {
sfree(wbuf);
wlen = len;
wbuf = snewn(wlen, WCHAR);
}
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
for (i = 0; i < len; i++)
wbuf[i] = text[i];
/* print Glyphs as they are, without Windows' Shaping*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
general_textout(wintw_hdc, x + xoffset,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr==LATTR_BOT) + text_adjust,
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
&line_box, wbuf, len, lpDx,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
opaque && !(attr & TATTR_COMBINING));
/* And the shadow bold hack. */
Introduce a third setting for the 'bold as colour' mode, which lets you both brighten the colour _and_ bold the font at the same time. (Fixes 'bold-font-colour' and Debian #193352.) [originally from svn r9559]
2012-06-09 15:09:22 +00:00
if (bold_font_mode == BOLD_SHADOW && (attr & ATTR_BOLD)) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetBkMode(wintw_hdc, TRANSPARENT);
ExtTextOutW(wintw_hdc, x + xoffset - 1,
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
y - font_height * (lattr ==
LATTR_BOT) + text_adjust,
Rationalise the mechanism in do_text_internal for providing the 'lpDx' array to ExtTextOut: - move it inside the new big loop (this should fix a potential bug whereby the DBCS handling altered some elements of it but the loop did not actually step along it) - initialise it more sensibly - rename it to lpDx rather than IpDx, since as far as I can tell the latter name was derived from a misreading of the former in the Windows API docs. [originally from svn r9066]
2010-12-29 23:48:54 +00:00
ETO_CLIPPED, &line_box, wbuf, len, lpDx_maybe);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
}
}
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
/*
* If we're looping round again, stop erasing the background
* rectangle.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
SetBkMode(wintw_hdc, TRANSPARENT);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
opaque = false;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (lattr != LATTR_TOP && (force_manual_underline ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(und_mode == UND_LINE
&& (attr & ATTR_UNDER)))) {
HPEN oldpen;
int dec = descent;
if (lattr == LATTR_BOT)
dec = dec * 2 - font_height;
oldpen = SelectObject(wintw_hdc, CreatePen(PS_SOLID, 0, fg));
MoveToEx(wintw_hdc, line_box.left, line_box.top + dec, NULL);
LineTo(wintw_hdc, line_box.right, line_box.top + dec);
oldpen = SelectObject(wintw_hdc, oldpen);
DeleteObject(oldpen);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
/*
* Wrapper that handles combining characters.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_draw_text(
TermWin *tw, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
{
if (attr & TATTR_COMBINING) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unsigned long a = 0;
int len0 = 1;
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
/* don't divide SURROGATE PAIR and VARIATION SELECTOR */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (len >= 2 && IS_SURROGATE_PAIR(text[0], text[1]))
len0 = 2;
if (len-len0 >= 1 && IS_LOW_VARSEL(text[len0])) {
attr &= ~TATTR_COMBINING;
do_text_internal(x, y, text, len0+1, attr, lattr, truecolour);
text += len0+1;
len -= len0+1;
a = TATTR_COMBINING;
} else if (len-len0 >= 2 && IS_HIGH_VARSEL(text[len0], text[len0+1])) {
attr &= ~TATTR_COMBINING;
do_text_internal(x, y, text, len0+2, attr, lattr, truecolour);
text += len0+2;
len -= len0+2;
a = TATTR_COMBINING;
} else {
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
attr &= ~TATTR_COMBINING;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (len--) {
if (len >= 1 && IS_SURROGATE_PAIR(text[0], text[1])) {
do_text_internal(x, y, text, 2, attr | a, lattr, truecolour);
len--;
text++;
} else
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
do_text_internal(x, y, text, 1, attr | a, lattr, truecolour);
Patch from Yoshida Masato to fill in the missing pieces of Windows UTF-16 support. High Unicode characters in the terminal are now converted back into surrogates during copy and draw operations, and the Windows drawing code takes account of that when splitting up the UTF-16 string for display. Meanwhile, accidental uses of wchar_t have been replaced with 32-bit integers in parts of the cross-platform code which were expecting not to have to deal with UTF-16. [originally from svn r9409]
2012-02-17 19:28:55 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
text++;
a = TATTR_COMBINING;
}
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
do_text_internal(x, y, text, len, attr, lattr, truecolour);
First-stage support for Unicode combining characters. The `chars' array of each `termline' structure now contains optional additional entries after the normal number of columns, which are used to chain a linked list of combining characters off any primary termchar that needs it. This means we support arbitrarily many combining characters per cell (unlike xterm's hard limit of 2). Cut and paste works correctly (selecting a character cell containing multiple code points causes all those code points to be cut and pasted). Display works by simply overlaying all the relevant characters on top of one another; this is good enough for Unix (xterm does the same thing), and mostly seems OK for Windows except that the Windows Unicode fonts have a nasty habit of not containing most of the combining characters and thus overlaying an unknown-code-point box on your perfectly good base glyph. I had no idea how to add support in the Mac do_text(), so I've simply stuck in an assertion that will trigger the first time a combining character is displayed, and hopefully this will bite someone with the clue to fix it. [originally from svn r4622]
2004-10-14 16:42:43 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_draw_cursor(
TermWin *tw, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr, truecolour truecolour)
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
{
int fnt_width;
int char_width;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int ctype = cursor_type;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
I masked off LATTR_WRAPPED et al in do_text_internal(), but forgot to do the same in do_cursor(). Bet that's the cause of Andrey Borzenkov's cursor positioning bug. [originally from svn r4770]
2004-11-11 09:40:50 +00:00
lattr &= LATTR_MODE;
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if ((attr & TATTR_ACTCURS) && (ctype == 0 || term->big_cursor)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (*text != UCSWIDE) {
win_draw_text(tw, x, y, text, len, attr, lattr, truecolour);
return;
}
ctype = 2;
attr |= TATTR_RIGHTCURS;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
fnt_width = char_width = font_width * (1 + (lattr != LATTR_NORM));
if (attr & ATTR_WIDE)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char_width *= 2;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
x *= fnt_width;
y *= font_height;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
x += offset_width;
y += offset_height;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if ((attr & TATTR_PASCURS) && (ctype == 0 || term->big_cursor)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
POINT pts[5];
HPEN oldpen;
pts[0].x = pts[1].x = pts[4].x = x;
pts[2].x = pts[3].x = x + char_width - 1;
pts[0].y = pts[3].y = pts[4].y = y;
pts[1].y = pts[2].y = y + font_height - 1;
oldpen = SelectObject(wintw_hdc, CreatePen(PS_SOLID, 0, colours[261]));
Polyline(wintw_hdc, pts, 5);
oldpen = SelectObject(wintw_hdc, oldpen);
DeleteObject(oldpen);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
} else if ((attr & (TATTR_ACTCURS | TATTR_PASCURS)) && ctype != 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int startx, starty, dx, dy, length, i;
if (ctype == 1) {
startx = x;
starty = y + descent;
dx = 1;
dy = 0;
length = char_width;
} else {
int xadjust = 0;
if (attr & TATTR_RIGHTCURS)
xadjust = char_width - 1;
startx = x + xadjust;
starty = y;
dx = 0;
dy = 1;
length = font_height;
}
if (attr & TATTR_ACTCURS) {
HPEN oldpen;
oldpen =
SelectObject(wintw_hdc, CreatePen(PS_SOLID, 0, colours[261]));
MoveToEx(wintw_hdc, startx, starty, NULL);
LineTo(wintw_hdc, startx + dx * length, starty + dy * length);
oldpen = SelectObject(wintw_hdc, oldpen);
DeleteObject(oldpen);
} else {
for (i = 0; i < length; i++) {
if (i % 2 == 0) {
SetPixel(wintw_hdc, startx, starty, colours[261]);
}
startx += dx;
starty += dy;
}
}
Introduce alternative cursor shapes: underline, vertical line [originally from svn r870]
2001-01-17 16:57:33 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
static void wintw_draw_trust_sigil(TermWin *tw, int x, int y)
{
x *= font_width;
y *= font_height;
x += offset_width;
y += offset_height;
Slightly nicer trust sigil on Windows. Re-consider the icon in light of the font size, so that we pick the icon whose size mostly closely matches the terminal font, rather than always scaling the default icon.
2019-03-30 15:44:01 +00:00
DrawIconEx(wintw_hdc, x, y, trust_icon, font_width * 2, font_height,
Add a TermWin method to draw a 'trust sigil'. This is not yet used by anything, but the idea is that it'll be a graphic in the terminal window that can't be replicated by a server sending escape sequences, and hence can be used as a reliable indication that the text on a particular terminal line is generated by PuTTY itself and not passed through from the server. This will make it possible to detect a malicious server trying to mimic local prompts to trick you out of information that shouldn't be sent over the wire (such as private-key passphrases). The trust sigil I've picked is a small copy of the PuTTY icon, which is thematically nice (it can be read as if the PuTTY icon is the name of the speaker in a dialogue) and also convenient because we had that graphic available already on all platforms. (Though the contortions I had to go through to make the GTK 1 code draw it were quite annoying.) The trust sigil has the same dimensions as a CJK double-width character, i.e. it's 2 character cells wide by 1 high.
2019-03-10 14:37:11 +00:00
0, NULL, DI_NORMAL);
}
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
/* This function gets the actual width of a character in the normal font.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static int wintw_char_width(TermWin *tw, int uc)
{
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
int ibuf = 0;
/* If the font max is the same as the font ave width then this
* function is a no-op.
*/
if (!font_dualwidth) return 1;
switch (uc & CSET_MASK) {
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
case CSET_ASCII:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc = ucsdata.unitab_line[uc & 0xFF];
break;
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
case CSET_LINEDRW:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc = ucsdata.unitab_xterm[uc & 0xFF];
break;
Re-engineering of terminal emulator, phase 1. The active terminal screen is no longer an array of `unsigned long' encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of `termchar' structures, which currently have 32-bit Unicode and 32 attribute bits but which will probably expand further in future. To prevent bloat of the memory footprint, I've introduced a mostly RLE-like compression scheme for storing scrollback: each line is compressed into a compact (but hard to modify) form when it moves into the term->scrollback tree, and is temporarily decompressed when the user wants to scroll back over it. My initial tests suggest that this compression averages about 1/4 of the previous (32 bits per character cell) data size in typical output, which means this is an improvement even without counting the new ability to extend the information stored in each character cell. Another beneficial side effect is that the insane format in which Unicode was passed to front ends through do_text() has now been rendered sane. Testing is incomplete; this _may_ still have instabilities. Windows and Unix front ends both seem to work as far as I've looked, but I haven't yet looked very hard. The Mac front end I've edited (it seemed obvious how to change it) but I can't compile or test it. As an immediate functional effect, the terminal emulator now supports full 32-bit Unicode to whatever extent the host platform allows it to. For example, if you output a 4-or-more-byte UTF-8 character in Unix pterm, it will not display it properly, but it will correctly paste it back out in a UTF8_STRING selection. Windows is more restricted, sadly. [originally from svn r4609]
2004-10-13 11:50:16 +00:00
case CSET_SCOACS:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
uc = ucsdata.unitab_scoacs[uc & 0xFF];
break;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
if (DIRECT_FONT(uc)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ucsdata.dbcs_screenfont) return 1;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Speedup, I know of no font where ascii is the wrong width */
if ((uc&~CSET_MASK) >= ' ' && (uc&~CSET_MASK)<= '~')
return 1;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ( (uc & CSET_MASK) == CSET_ACP ) {
SelectObject(wintw_hdc, fonts[FONT_NORMAL]);
} else if ( (uc & CSET_MASK) == CSET_OEMCP ) {
another_font(FONT_OEM);
if (!fonts[FONT_OEM]) return 0;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SelectObject(wintw_hdc, fonts[FONT_OEM]);
} else
return 0;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (GetCharWidth32(wintw_hdc, uc & ~CSET_MASK,
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
uc & ~CSET_MASK, &ibuf) != 1 &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GetCharWidth(wintw_hdc, uc & ~CSET_MASK,
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
uc & ~CSET_MASK, &ibuf) != 1)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Speedup, I know of no font where ascii is the wrong width */
if (uc >= ' ' && uc <= '~') return 1;
SelectObject(wintw_hdc, fonts[FONT_NORMAL]);
if (GetCharWidth32W(wintw_hdc, uc, uc, &ibuf) == 1)
/* Okay that one worked */ ;
else if (GetCharWidthW(wintw_hdc, uc, uc, &ibuf) == 1)
/* This should work on 9x too, but it's "less accurate" */ ;
else
return 0;
Three more patches from RDB: one to make Atomica work right, one to fiddle with the widths of characters in DBCS screen fonts, and (the big one) one to enable a mode in which resizing the window locks the terminal size and lets the font change, instead of vice versa. That should shut up a few feature requests! [originally from svn r1269]
2001-09-15 15:54:24 +00:00
}
ibuf += font_width / 2 -1;
ibuf /= font_width;
return ibuf;
}
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
DECL_WINDOWS_FUNCTION(static, BOOL, FlashWindowEx, (PFLASHWINFO));
DECL_WINDOWS_FUNCTION(static, BOOL, ToUnicodeEx,
(UINT, UINT, const BYTE *, LPWSTR, int, UINT, HKL));
Load winmm.dll (for PlaySound()) at run time. It's not on the default list of important system 'known DLLs' stored at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs (see https://isc.sans.edu/forums/diary/DLL+hijacking+vulnerabilities/9445/ ) which apparently makes it exempt from Windows's standard DLL hijacking defence, i.e. if an executable links against it in the normal way then that executable will be vulnerable to DLL hijacking from a file called winmm.dll in the same directory as it. The solution is to load it dynamically _after_ we've locked down our DLL search path, which fortunately PuTTY's code base is well used to doing already for other DLLs.
2017-03-13 21:24:06 +00:00
DECL_WINDOWS_FUNCTION(static, BOOL, PlaySound, (LPCTSTR, HMODULE, DWORD));
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
static void init_winfuncs(void)
{
HMODULE user32_module = load_system32_dll("user32.dll");
Load winmm.dll (for PlaySound()) at run time. It's not on the default list of important system 'known DLLs' stored at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs (see https://isc.sans.edu/forums/diary/DLL+hijacking+vulnerabilities/9445/ ) which apparently makes it exempt from Windows's standard DLL hijacking defence, i.e. if an executable links against it in the normal way then that executable will be vulnerable to DLL hijacking from a file called winmm.dll in the same directory as it. The solution is to load it dynamically _after_ we've locked down our DLL search path, which fortunately PuTTY's code base is well used to doing already for other DLLs.
2017-03-13 21:24:06 +00:00
HMODULE winmm_module = load_system32_dll("winmm.dll");
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
GET_WINDOWS_FUNCTION(user32_module, FlashWindowEx);
Reinstate use of ToUnicodeEx(). This was accidentally disabled by 73039b783, causing a regression in ability to type characters outside of the current Windows code page.
2017-04-29 11:07:37 +00:00
GET_WINDOWS_FUNCTION(user32_module, ToUnicodeEx);
Load winmm.dll (for PlaySound()) at run time. It's not on the default list of important system 'known DLLs' stored at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs (see https://isc.sans.edu/forums/diary/DLL+hijacking+vulnerabilities/9445/ ) which apparently makes it exempt from Windows's standard DLL hijacking defence, i.e. if an executable links against it in the normal way then that executable will be vulnerable to DLL hijacking from a file called winmm.dll in the same directory as it. The solution is to load it dynamically _after_ we've locked down our DLL search path, which fortunately PuTTY's code base is well used to doing already for other DLLs.
2017-03-13 21:24:06 +00:00
GET_WINDOWS_FUNCTION_PP(winmm_module, PlaySound);
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
* Translate a WM_(SYS)?KEY(UP|DOWN) message into a string of ASCII
Ctrl-Break now sends a Break signal (previously it was equivalent to Ctrl-C). [originally from svn r7295] [this svn revision also touched putty-wishlist]
2007-02-18 14:02:39 +00:00
* codes. Returns number of bytes used, zero to drop the message,
* -1 to forward the message to Windows, or another negative number
* to indicate a NUL-terminated "special" string.
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
*/
Chinese support patch from zmx@cdpa.nsysu.edu.tw [originally from svn r740]
2000-10-20 18:36:15 +00:00
static int TranslateKey(UINT message, WPARAM wParam, LPARAM lParam,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
unsigned char *output)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
BYTE keystate[256];
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
int scan, shift_state;
bool left_alt = false, key_down;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
int r, i;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
unsigned char *p = output;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
static int alt_sum = 0;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int funky_type = conf_get_int(conf, CONF_funky_type);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
bool no_applic_k = conf_get_bool(conf, CONF_no_applic_k);
bool ctrlaltkeys = conf_get_bool(conf, CONF_ctrlaltkeys);
bool nethack_keypad = conf_get_bool(conf, CONF_nethack_keypad);
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
char keypad_key = '\0';
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Kestutis Kupciunas's Lithuanian-friendliness patch to TranslateKey [originally from svn r847]
2001-01-07 18:28:01 +00:00
HKL kbd_layout = GetKeyboardLayout(0);
Switch to translating keystrokes using ToUnicodeEx rather than ToAsciiEx, where possible. This enables support for keys which generate Unicode characters that aren't in the system code page, which seems to me like a perverse way for Windows to have set up the system code page but apparently does happen, e.g. (I'm told) U+0219 and U+021B on Romanian keyboards. Patch mostly due to Andrei Damian-Fekete. [originally from svn r9942]
2013-07-20 11:31:24 +00:00
static wchar_t keys_unicode[3];
Alt-Enter was fouling up on Win95; added explicit handler [originally from svn r687]
2000-10-07 08:10:32 +00:00
static int compose_char = 0;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
static WPARAM compose_keycode = 0;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
r = GetKeyboardState(keystate);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (!r)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
memset(keystate, 0, sizeof(keystate));
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
else {
Robert de Bath's big patch: - cope with strange WinSock wrappers not supporting SIOCATMARK - define yet more terminal compatibility modes - support UK-ASCII (just like US-ASCII but # is a sterling sign) - support connection keepalives at a configurable interval [originally from svn r692]
2000-10-09 12:53:32 +00:00
#if 0
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
#define SHOW_TOASCII_RESULT
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
{ /* Tell us all about key events */
static BYTE oldstate[256];
static int first = 1;
static int scan;
int ch;
if (first)
memcpy(oldstate, keystate, sizeof(oldstate));
first = 0;
if ((HIWORD(lParam) & (KF_UP | KF_REPEAT)) == KF_REPEAT) {
debug("+");
} else if ((HIWORD(lParam) & KF_UP)
&& scan == (HIWORD(lParam) & 0xFF)) {
debug(". U");
} else {
debug(".\n");
if (wParam >= VK_F1 && wParam <= VK_F20)
debug("K_F%d", wParam + 1 - VK_F1);
else
switch (wParam) {
case VK_SHIFT:
debug("SHIFT");
break;
case VK_CONTROL:
debug("CTRL");
break;
case VK_MENU:
debug("ALT");
break;
default:
debug("VK_%02x", wParam);
}
if (message == WM_SYSKEYDOWN || message == WM_SYSKEYUP)
debug("*");
debug(", S%02x", scan = (HIWORD(lParam) & 0xFF));
ch = MapVirtualKeyEx(wParam, 2, kbd_layout);
if (ch >= ' ' && ch <= '~')
debug(", '%c'", ch);
else if (ch)
debug(", $%02x", ch);
if (keys_unicode[0])
debug(", KB0=%04x", keys_unicode[0]);
if (keys_unicode[1])
debug(", KB1=%04x", keys_unicode[1]);
if (keys_unicode[2])
debug(", KB2=%04x", keys_unicode[2]);
if ((keystate[VK_SHIFT] & 0x80) != 0)
debug(", S");
if ((keystate[VK_CONTROL] & 0x80) != 0)
debug(", C");
if ((HIWORD(lParam) & KF_EXTENDED))
debug(", E");
if ((HIWORD(lParam) & KF_UP))
debug(", U");
}
if ((HIWORD(lParam) & (KF_UP | KF_REPEAT)) == KF_REPEAT);
else if ((HIWORD(lParam) & KF_UP))
oldstate[wParam & 0xFF] ^= 0x80;
else
oldstate[wParam & 0xFF] ^= 0x81;
for (ch = 0; ch < 256; ch++)
if (oldstate[ch] != keystate[ch])
debug(", M%02x=%02x", ch, keystate[ch]);
memcpy(oldstate, keystate, sizeof(oldstate));
}
Robert de Bath's big patch: - cope with strange WinSock wrappers not supporting SIOCATMARK - define yet more terminal compatibility modes - support UK-ASCII (just like US-ASCII but # is a sterling sign) - support connection keepalives at a configurable interval [originally from svn r692]
2000-10-09 12:53:32 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (wParam == VK_MENU && (HIWORD(lParam) & KF_EXTENDED)) {
keystate[VK_RMENU] = keystate[VK_MENU];
}
AltGr should now work again even when Compose key disabled [originally from svn r838]
2001-01-07 14:30:00 +00:00
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Nastyness with NUMLock - Shift-NUMLock is left alone though */
if ((funky_type == FUNKY_VT400 ||
(funky_type <= FUNKY_LINUX && term->app_keypad_keys &&
!no_applic_k))
&& wParam == VK_NUMLOCK && !(keystate[VK_SHIFT] & 0x80)) {
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wParam = VK_EXECUTE;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* UnToggle NUMLock */
if ((HIWORD(lParam) & (KF_UP | KF_REPEAT)) == 0)
keystate[VK_NUMLOCK] ^= 1;
}
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* And write back the 'adjusted' state */
SetKeyboardState(keystate);
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
}
/* Disable Auto repeat if required */
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (term->repeat_off &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(HIWORD(lParam) & (KF_UP | KF_REPEAT)) == KF_REPEAT)
return 0;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if ((HIWORD(lParam) & KF_ALTDOWN) && (keystate[VK_RMENU] & 0x80) == 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
left_alt = true;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
key_down = ((HIWORD(lParam) & KF_UP) == 0);
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Keyboard handling patch from RDB: the Windows Application key is now always Compose (we have no better use for it), and Ctrl-Alt can be made to act like AltGr (but it's never Compose even when AltGr is). [originally from svn r1033]
2001-04-09 12:52:43 +00:00
/* Make sure Ctrl-ALT is not the same as AltGr for ToAscii unless told. */
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (left_alt && (keystate[VK_CONTROL] & 0x80)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ctrlaltkeys)
keystate[VK_MENU] = 0;
else {
keystate[VK_RMENU] = 0x80;
left_alt = false;
}
Keyboard handling patch from RDB: the Windows Application key is now always Compose (we have no better use for it), and Ctrl-Alt can be made to act like AltGr (but it's never Compose even when AltGr is). [originally from svn r1033]
2001-04-09 12:52:43 +00:00
}
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
scan = (HIWORD(lParam) & (KF_UP | KF_EXTENDED | 0xFF));
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
shift_state = ((keystate[VK_SHIFT] & 0x80) != 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
+ ((keystate[VK_CONTROL] & 0x80) != 0) * 2;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Keyboard handling patch from RDB: the Windows Application key is now always Compose (we have no better use for it), and Ctrl-Alt can be made to act like AltGr (but it's never Compose even when AltGr is). [originally from svn r1033]
2001-04-09 12:52:43 +00:00
/* Note if AltGr was pressed and if it was used as a compose key */
if (!compose_state) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
compose_keycode = 0x100;
if (conf_get_bool(conf, CONF_compose_key)) {
if (wParam == VK_MENU && (HIWORD(lParam) & KF_EXTENDED))
compose_keycode = wParam;
}
if (wParam == VK_APPS)
compose_keycode = wParam;
Keyboard handling patch from RDB: the Windows Application key is now always Compose (we have no better use for it), and Ctrl-Alt can be made to act like AltGr (but it's never Compose even when AltGr is). [originally from svn r1033]
2001-04-09 12:52:43 +00:00
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (wParam == compose_keycode) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (compose_state == 0
&& (HIWORD(lParam) & (KF_UP | KF_REPEAT)) == 0) compose_state =
1;
else if (compose_state == 1 && (HIWORD(lParam) & KF_UP))
compose_state = 2;
else
compose_state = 0;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
} else if (compose_state == 1 && wParam != VK_CONTROL)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
compose_state = 0;
Keyboard handling patch from RDB: the Windows Application key is now always Compose (we have no better use for it), and Ctrl-Alt can be made to act like AltGr (but it's never Compose even when AltGr is). [originally from svn r1033]
2001-04-09 12:52:43 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (compose_state > 1 && left_alt)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
compose_state = 0;
Add AltGr support at last! Thanks to <andre@via.ecp.fr> for the technique if not all of the details. [originally from svn r92]
1999-03-12 17:14:06 +00:00
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
/* Sanitize the number pad if not using a PC NumPad */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (left_alt || (term->app_keypad_keys && !no_applic_k
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
&& funky_type != FUNKY_XTERM)
|| funky_type == FUNKY_VT400 || nethack_keypad || compose_state) {
if ((HIWORD(lParam) & KF_EXTENDED) == 0) {
int nParam = 0;
switch (wParam) {
case VK_INSERT:
nParam = VK_NUMPAD0;
break;
case VK_END:
nParam = VK_NUMPAD1;
break;
case VK_DOWN:
nParam = VK_NUMPAD2;
break;
case VK_NEXT:
nParam = VK_NUMPAD3;
break;
case VK_LEFT:
nParam = VK_NUMPAD4;
break;
case VK_CLEAR:
nParam = VK_NUMPAD5;
break;
case VK_RIGHT:
nParam = VK_NUMPAD6;
break;
case VK_HOME:
nParam = VK_NUMPAD7;
break;
case VK_UP:
nParam = VK_NUMPAD8;
break;
case VK_PRIOR:
nParam = VK_NUMPAD9;
break;
case VK_DELETE:
nParam = VK_DECIMAL;
break;
}
if (nParam) {
if (keystate[VK_NUMLOCK] & 1)
shift_state |= 1;
wParam = nParam;
}
}
Oops - Shift-PgUp/PgDn conflicted with NetHack mode [originally from svn r285]
1999-11-09 11:19:34 +00:00
}
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
/* If a key is pressed and AltGr is not active */
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (key_down && (keystate[VK_RMENU] & 0x80) == 0 && !compose_state) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Okay, prepare for most alts then ... */
if (left_alt)
*p++ = '\033';
/* Lets see if it's a pattern we know all about ... */
if (wParam == VK_PRIOR && shift_state == 1) {
SendMessage(hwnd, WM_VSCROLL, SB_PAGEUP, 0);
return 0;
}
ctrl-shift-page-up/down to top or bottom of scrollback Just a small patch, that I find really useful.
2017-11-03 14:31:10 +00:00
if (wParam == VK_PRIOR && shift_state == 3) { /* ctrl-shift-pageup */
SendMessage(hwnd, WM_VSCROLL, SB_TOP, 0);
return 0;
}
if (wParam == VK_NEXT && shift_state == 3) { /* ctrl-shift-pagedown */
SendMessage(hwnd, WM_VSCROLL, SB_BOTTOM, 0);
return 0;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (wParam == VK_PRIOR && shift_state == 2) {
SendMessage(hwnd, WM_VSCROLL, SB_LINEUP, 0);
return 0;
}
if (wParam == VK_NEXT && shift_state == 1) {
SendMessage(hwnd, WM_VSCROLL, SB_PAGEDOWN, 0);
return 0;
}
if (wParam == VK_NEXT && shift_state == 2) {
SendMessage(hwnd, WM_VSCROLL, SB_LINEDOWN, 0);
return 0;
}
if ((wParam == VK_PRIOR || wParam == VK_NEXT) && shift_state == 3) {
term_scroll_to_selection(term, (wParam == VK_PRIOR ? 0 : 1));
return 0;
}
if (wParam == VK_INSERT && shift_state == 2) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (conf_get_int(conf, CONF_ctrlshiftins)) {
case CLIPUI_IMPLICIT:
break; /* no need to re-copy to CLIP_LOCAL */
case CLIPUI_EXPLICIT:
term_request_copy(term, clips_system, lenof(clips_system));
break;
default:
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
}
if (wParam == VK_INSERT && shift_state == 1) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (conf_get_int(conf, CONF_ctrlshiftins)) {
case CLIPUI_IMPLICIT:
term_request_paste(term, CLIP_LOCAL);
break;
case CLIPUI_EXPLICIT:
term_request_paste(term, CLIP_SYSTEM);
break;
default:
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
}
if (wParam == 'C' && shift_state == 3) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (conf_get_int(conf, CONF_ctrlshiftcv)) {
case CLIPUI_IMPLICIT:
break; /* no need to re-copy to CLIP_LOCAL */
case CLIPUI_EXPLICIT:
term_request_copy(term, clips_system, lenof(clips_system));
break;
default:
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
}
if (wParam == 'V' && shift_state == 3) {
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
switch (conf_get_int(conf, CONF_ctrlshiftcv)) {
case CLIPUI_IMPLICIT:
term_request_paste(term, CLIP_LOCAL);
break;
case CLIPUI_EXPLICIT:
term_request_paste(term, CLIP_SYSTEM);
break;
default:
break;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
}
if (left_alt && wParam == VK_F4 && conf_get_bool(conf, CONF_alt_f4)) {
return -1;
}
if (left_alt && wParam == VK_SPACE && conf_get_bool(conf,
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
CONF_alt_space)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_SYSCOMMAND, SC_KEYMENU, 0);
return -1;
}
if (left_alt && wParam == VK_RETURN &&
conf_get_bool(conf, CONF_fullscreenonaltenter) &&
(conf_get_int(conf, CONF_resize_action) != RESIZE_DISABLED)) {
if ((HIWORD(lParam) & (KF_UP | KF_REPEAT)) != KF_REPEAT)
flip_full_screen();
return -1;
}
/* Control-Numlock for app-keypad mode switch */
if (wParam == VK_PAUSE && shift_state == 2) {
term->app_keypad_keys = !term->app_keypad_keys;
return 0;
}
if (wParam == VK_BACK && shift_state == 0) { /* Backspace */
*p++ = (conf_get_bool(conf, CONF_bksp_is_delete) ? 0x7F : 0x08);
*p++ = 0;
return -2;
}
if (wParam == VK_BACK && shift_state == 1) { /* Shift Backspace */
/* We do the opposite of what is configured */
*p++ = (conf_get_bool(conf, CONF_bksp_is_delete) ? 0x08 : 0x7F);
*p++ = 0;
return -2;
}
if (wParam == VK_TAB && shift_state == 1) { /* Shift tab */
*p++ = 0x1B;
*p++ = '[';
*p++ = 'Z';
return p - output;
}
if (wParam == VK_SPACE && shift_state == 2) { /* Ctrl-Space */
*p++ = 0;
return p - output;
}
if (wParam == VK_SPACE && shift_state == 3) { /* Ctrl-Shift-Space */
*p++ = 160;
return p - output;
}
if (wParam == VK_CANCEL && shift_state == 2) { /* Ctrl-Break */
Turn Backend into a sensible classoid. Nearly every part of the code that ever handles a full backend structure has historically done it using a pair of pointer variables, one pointing at a constant struct full of function pointers, and the other pointing to a 'void *' state object that's passed to each of those. While I'm modernising the rest of the code, this seems like a good time to turn that into the same more or less type-safe and less cumbersome system as I'm using for other parts of the code, such as Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure contains a vtable pointer, and a system of macro wrappers handles dispatching through that vtable.
2018-09-11 15:23:38 +00:00
if (backend)
Rework special-commands system to add an integer argument. In order to list cross-certifiable host keys in the GUI specials menu, the SSH backend has been inventing new values on the end of the Telnet_Special enumeration, starting from the value TS_LOCALSTART. This is inelegant, and also makes it awkward to break up special handlers (e.g. to dispatch different specials to different SSH layers), since if all you know about a special is that it's somewhere in the TS_LOCALSTART+n space, you can't tell what _general kind_ of thing it is. Also, if I ever need another open-ended set of specials in future, I'll have to remember which TS_LOCALSTART+n codes are in which set. So here's a revamp that causes every special to take an extra integer argument. For all previously numbered specials, this argument is passed as zero and ignored, but there's a new main special code for SSH host key cross-certification, in which the integer argument is an index into the backend's list of available keys. TS_LOCALSTART is now a thing of the past: if I need any other open-ended sets of specials in future, I can add a new top-level code with a nicely separated space of arguments. While I'm at it, I've removed the legacy misnomer 'Telnet_Special' from the code completely; the enum is now SessionSpecialCode, the struct containing full details of a menu entry is SessionSpecial, and the enum values now start SS_ rather than TS_.
2018-09-24 08:35:52 +00:00
backend_special(backend, SS_BRK, 0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
}
if (wParam == VK_PAUSE) { /* Break/Pause */
*p++ = 26;
*p++ = 0;
return -2;
}
/* Control-2 to Control-8 are special */
if (shift_state == 2 && wParam >= '2' && wParam <= '8') {
*p++ = "\000\033\034\035\036\037\177"[wParam - '2'];
return p - output;
}
if (shift_state == 2 && (wParam == 0xBD || wParam == 0xBF)) {
*p++ = 0x1F;
return p - output;
}
if (shift_state == 2 && (wParam == 0xDF || wParam == 0xDC)) {
*p++ = 0x1C;
return p - output;
}
if (shift_state == 3 && wParam == 0xDE) {
*p++ = 0x1E; /* Ctrl-~ == Ctrl-^ in xterm at least */
return p - output;
}
switch (wParam) {
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
case VK_NUMPAD0: keypad_key = '0'; goto numeric_keypad;
case VK_NUMPAD1: keypad_key = '1'; goto numeric_keypad;
case VK_NUMPAD2: keypad_key = '2'; goto numeric_keypad;
case VK_NUMPAD3: keypad_key = '3'; goto numeric_keypad;
case VK_NUMPAD4: keypad_key = '4'; goto numeric_keypad;
case VK_NUMPAD5: keypad_key = '5'; goto numeric_keypad;
case VK_NUMPAD6: keypad_key = '6'; goto numeric_keypad;
case VK_NUMPAD7: keypad_key = '7'; goto numeric_keypad;
case VK_NUMPAD8: keypad_key = '8'; goto numeric_keypad;
case VK_NUMPAD9: keypad_key = '9'; goto numeric_keypad;
case VK_DECIMAL: keypad_key = '.'; goto numeric_keypad;
case VK_ADD: keypad_key = '+'; goto numeric_keypad;
case VK_SUBTRACT: keypad_key = '-'; goto numeric_keypad;
case VK_MULTIPLY: keypad_key = '*'; goto numeric_keypad;
case VK_DIVIDE: keypad_key = '/'; goto numeric_keypad;
case VK_EXECUTE: keypad_key = 'G'; goto numeric_keypad;
/* also the case for VK_RETURN below can sometimes come here */
numeric_keypad:
/* Left Alt overrides all numeric keypad usage to act as
* numeric character code input */
if (left_alt) {
if (keypad_key >= '0' && keypad_key <= '9')
alt_sum = alt_sum * 10 + keypad_key - '0';
else
alt_sum = 0;
break;
}
Shift-Tab now sends ESC [ Z [originally from svn r408]
2000-03-13 14:45:32 +00:00
Remove ASCII fallback in format_numeric_keypad_key(). TranslateKey() on Windows passed all numeric-keypad key events to this function in terminal.c, and accepted whatever it gave back. That included the handling for the trivial case of the numeric keypad, when Num Lock is on and application keypad mode hasn't overridden it, so that the keypad should be returning actual digits. In that case, format_numeric_keypad_key() itself was returning the same ASCII character I had passed in to it as a keypad identifier, and TranslateKey was returning that in turn as the final translation. Unfortunately, that means that with Num Lock on, the numeric keypad translates into what _I_ used as the logical keypad codes inside the source code, not what the local keyboard layout thinks are the right codes. In particular, the key I identified as keypad '.' would render as '.' even on a German keyboard where it ought to produce ','. Fixed by removing the fallback case in format_numeric_keypad_key() itself, so now it returns the empty string if it didn't produce an escape sequence as its translation. Instead, the special case is in window.c, which checks for a zero-length output string and handles it by falling through to the keyboard-layout specific ToUnicode code further down TranslateKey(). On the GTK side, no change is needed here: the GTK keyboard handler does things in the opposite order, by trying the local input method _first_ (unless it can see a reason up front to override it), and only calling format_numeric_keypad_key() if that didn't provide a translation. So the fallback ASCII translation in the latter was already not used.
2019-04-06 09:45:40 +00:00
{
int nchars = format_numeric_keypad_key(
(char *)p, term, keypad_key,
shift_state & 1, shift_state & 2);
if (!nchars) {
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
/*
* If we didn't get an escape sequence out of the
Remove ASCII fallback in format_numeric_keypad_key(). TranslateKey() on Windows passed all numeric-keypad key events to this function in terminal.c, and accepted whatever it gave back. That included the handling for the trivial case of the numeric keypad, when Num Lock is on and application keypad mode hasn't overridden it, so that the keypad should be returning actual digits. In that case, format_numeric_keypad_key() itself was returning the same ASCII character I had passed in to it as a keypad identifier, and TranslateKey was returning that in turn as the final translation. Unfortunately, that means that with Num Lock on, the numeric keypad translates into what _I_ used as the logical keypad codes inside the source code, not what the local keyboard layout thinks are the right codes. In particular, the key I identified as keypad '.' would render as '.' even on a German keyboard where it ought to produce ','. Fixed by removing the fallback case in format_numeric_keypad_key() itself, so now it returns the empty string if it didn't produce an escape sequence as its translation. Instead, the special case is in window.c, which checks for a zero-length output string and handles it by falling through to the keyboard-layout specific ToUnicode code further down TranslateKey(). On the GTK side, no change is needed here: the GTK keyboard handler does things in the opposite order, by trying the local input method _first_ (unless it can see a reason up front to override it), and only calling format_numeric_keypad_key() if that didn't provide a translation. So the fallback ASCII translation in the latter was already not used.
2019-04-06 09:45:40 +00:00
* numeric keypad key, then that must be because
* we're in Num Lock mode without application
* keypad enabled. In that situation we leave this
* keypress to the ToUnicode/ToAsciiEx handler
* below, which will translate it according to the
* appropriate keypad layout (e.g. so that what a
* Brit thinks of as keypad '.' can become ',' in
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
* the German layout).
*
* An exception is the keypad Return key: if we
* didn't get an escape sequence for that, we
* treat it like ordinary Return, taking into
* account Telnet special new line codes and
* config options.
*/
if (keypad_key == '\r')
goto ordinary_return_key;
Remove ASCII fallback in format_numeric_keypad_key(). TranslateKey() on Windows passed all numeric-keypad key events to this function in terminal.c, and accepted whatever it gave back. That included the handling for the trivial case of the numeric keypad, when Num Lock is on and application keypad mode hasn't overridden it, so that the keypad should be returning actual digits. In that case, format_numeric_keypad_key() itself was returning the same ASCII character I had passed in to it as a keypad identifier, and TranslateKey was returning that in turn as the final translation. Unfortunately, that means that with Num Lock on, the numeric keypad translates into what _I_ used as the logical keypad codes inside the source code, not what the local keyboard layout thinks are the right codes. In particular, the key I identified as keypad '.' would render as '.' even on a German keyboard where it ought to produce ','. Fixed by removing the fallback case in format_numeric_keypad_key() itself, so now it returns the empty string if it didn't produce an escape sequence as its translation. Instead, the special case is in window.c, which checks for a zero-length output string and handles it by falling through to the keyboard-layout specific ToUnicode code further down TranslateKey(). On the GTK side, no change is needed here: the GTK keyboard handler does things in the opposite order, by trying the local input method _first_ (unless it can see a reason up front to override it), and only calling format_numeric_keypad_key() if that didn't provide a translation. So the fallback ASCII translation in the latter was already not used.
2019-04-06 09:45:40 +00:00
break;
}
p += nchars;
return p - output;
}
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
int fkey_number;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case VK_F1: fkey_number = 1; goto numbered_function_key;
case VK_F2: fkey_number = 2; goto numbered_function_key;
case VK_F3: fkey_number = 3; goto numbered_function_key;
case VK_F4: fkey_number = 4; goto numbered_function_key;
case VK_F5: fkey_number = 5; goto numbered_function_key;
case VK_F6: fkey_number = 6; goto numbered_function_key;
case VK_F7: fkey_number = 7; goto numbered_function_key;
case VK_F8: fkey_number = 8; goto numbered_function_key;
case VK_F9: fkey_number = 9; goto numbered_function_key;
case VK_F10: fkey_number = 10; goto numbered_function_key;
case VK_F11: fkey_number = 11; goto numbered_function_key;
case VK_F12: fkey_number = 12; goto numbered_function_key;
case VK_F13: fkey_number = 13; goto numbered_function_key;
case VK_F14: fkey_number = 14; goto numbered_function_key;
case VK_F15: fkey_number = 15; goto numbered_function_key;
case VK_F16: fkey_number = 16; goto numbered_function_key;
case VK_F17: fkey_number = 17; goto numbered_function_key;
case VK_F18: fkey_number = 18; goto numbered_function_key;
case VK_F19: fkey_number = 19; goto numbered_function_key;
case VK_F20: fkey_number = 20; goto numbered_function_key;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
numbered_function_key:
p += format_function_key((char *)p, term, fkey_number,
shift_state & 1, shift_state & 2);
return p - output;
SmallKeypadKey sk_key;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case VK_HOME: sk_key = SKK_HOME; goto small_keypad_key;
case VK_END: sk_key = SKK_END; goto small_keypad_key;
case VK_INSERT: sk_key = SKK_INSERT; goto small_keypad_key;
case VK_DELETE: sk_key = SKK_DELETE; goto small_keypad_key;
case VK_PRIOR: sk_key = SKK_PGUP; goto small_keypad_key;
case VK_NEXT: sk_key = SKK_PGDN; goto small_keypad_key;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
small_keypad_key:
/* These keys don't generate terminal input with Ctrl */
if (shift_state & 2)
break;
Alt-Enter was fouling up on Win95; added explicit handler [originally from svn r687]
2000-10-07 08:10:32 +00:00
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
p += format_small_keypad_key((char *)p, term, sk_key);
return p - output;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char xkey;
Centralise key escape sequences into terminal.c. A long time ago, in commit 4d77b6567, I moved the generation of the arrow-key escape sequences into a function format_arrow_key(). Mostly the reason for that was a special purpose I had in mind at the time which involved auto-generating the same sequences in response to things other than a keypress, but I always thought it would be nice to centralise a lot more of PuTTY's complicated keyboard handling in the same way - at least the handling of the function keys and their numerous static and dynamic config options. In this year's general spirit of tidying up and refactoring, I think it's finally time. So here I introduce three more centralised functions for dealing with the numbered function keys, the small keypad (Ins, Home, PgUp etc) and the numeric keypad. Lots of horrible and duplicated code from the key handling functions in window.c and gtkwin.c is now more sensibly centralised: each platform keyboard handler concerns itself with the local format of a keyboard event and platform-specific enumeration of key codes, and once it's decided what the logical key press actually _is_, it hands off to the new functions in terminal.c to generate the appropriate escape code. Mostly this is intended to be a refactoring without functional change, leaving the keyboard handling how it's always been. But in cases where the Windows and GTK handlers were accidentally inconsistent, I've fixed the inconsistency rather than carefully keeping both sides how they were. Known consistency fixes: - swapping the arrow keys between normal (ESC [ A) and application (ESC O A) is now done by pressing Ctrl with them, and _not_ by pressing Shift. That was how it was always supposed to work, and how it's worked on GTK all along, but on Windows it's been done by Shift as well since 2010, due to a bug at the call site of format_arrow_key() introduced when I originally wrote that function. - in Xterm function key mode plus application keypad mode, the /*- keys on the numeric keypad now send ESC O {o,j,m} in place of ESC O {Q,R,S}. That's how the Windows keyboard handler has worked all along (it was a deliberate behaviour tweak for the Xterm-like function key mode, because in that mode ESC O {Q,R,S} are generated by F2-F4). But the GTK keyboard handler omitted that particular special case and was still sending ESC O {Q,R,S} for those keys in all application keypad modes. - also in Xterm function key mode plus app keypad mode, we only generates the app-keypad escape sequences if Num Lock is on; with Num Lock off, the numeric keypad becomes arrow keys and Home/End/etc, just as it would in non-app-keypad mode. Windows has done this all along, but again, GTK lacked that special case.
2018-12-08 08:25:32 +00:00
case VK_UP: xkey = 'A'; goto arrow_key;
case VK_DOWN: xkey = 'B'; goto arrow_key;
case VK_RIGHT: xkey = 'C'; goto arrow_key;
case VK_LEFT: xkey = 'D'; goto arrow_key;
case VK_CLEAR: xkey = 'G'; goto arrow_key; /* close enough */
arrow_key:
p += format_arrow_key((char *)p, term, xkey, shift_state & 2);
return p - output;
case VK_RETURN:
if (HIWORD(lParam) & KF_EXTENDED) {
keypad_key = '\r';
goto numeric_keypad;
}
Fix handling of Return and keypad Enter. The recent rewriting in both the GTK and Windows keyboard handlers left the keypad 'Enter' key in a bad state, when no override is enabled that causes it to generate an escape sequence. On Windows, a series of fallbacks was causing it to generate \r regardless of configuration, whereas in Telnet mode it should default to generating the special Telnet new-line sequence, and in response to ESC[20h (enabling term->cr_lf_return) it should generate \r\n. On GTK, it wasn't generating anything _at all_, and also, I can't see any evidence that the GTK keyboard handler had ever remembered to implement the cr_lf_return mode. Now Keypad Enter in non-escape-sequence mode should behave just like Return, on both platforms.
2019-04-15 19:43:10 +00:00
ordinary_return_key:
if (shift_state == 0 && term->cr_lf_return) {
*p++ = '\r';
*p++ = '\n';
return p - output;
} else {
*p++ = 0x0D;
*p++ = 0;
return -2;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Add AltGr support at last! Thanks to <andre@via.ecp.fr> for the technique if not all of the details. [originally from svn r92]
1999-03-12 17:14:06 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Okay we've done everything interesting; let windows deal with
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
* the boring stuff */
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool capsOn = false;
/* helg: clear CAPS LOCK state if caps lock switches to cyrillic */
if(keystate[VK_CAPITAL] != 0 &&
conf_get_bool(conf, CONF_xlat_capslockcyr)) {
capsOn= !left_alt;
keystate[VK_CAPITAL] = 0;
}
/* XXX how do we know what the max size of the keys array should
* be is? There's indication on MS' website of an Inquire/InquireEx
* functioning returning a KBINFO structure which tells us. */
if (osPlatformId == VER_PLATFORM_WIN32_NT && p_ToUnicodeEx) {
r = p_ToUnicodeEx(wParam, scan, keystate, keys_unicode,
Find ToUnicodeEx() at run time, not load time. This restores PuTTY's backward compatibility to versions of Windows too old to have ToUnicodeEx in their system libraries, which was accidentally broken in 0.63. [originally from svn r10061]
2013-11-17 14:03:20 +00:00
lenof(keys_unicode), 0, kbd_layout);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
/* XXX 'keys' parameter is declared in MSDN documentation as
* 'LPWORD lpChar'.
* The experience of a French user indicates that on
* Win98, WORD[] should be passed in, but on Win2K, it should
* be BYTE[]. German WinXP and my Win2K with "US International"
* driver corroborate this.
* Experimentally I've conditionalised the behaviour on the
* Win9x/NT split, but I suspect it's worse than that.
* See wishlist item `win-dead-keys' for more horrible detail
* and speculations. */
int i;
static WORD keys[3];
static BYTE keysb[3];
r = ToAsciiEx(wParam, scan, keystate, keys, 0, kbd_layout);
if (r > 0) {
for (i = 0; i < r; i++) {
keysb[i] = (BYTE)keys[i];
}
MultiByteToWideChar(CP_ACP, 0, (LPCSTR)keysb, r,
Switch to translating keystrokes using ToUnicodeEx rather than ToAsciiEx, where possible. This enables support for keys which generate Unicode characters that aren't in the system code page, which seems to me like a perverse way for Windows to have set up the system code page but apparently does happen, e.g. (I'm told) U+0219 and U+021B on Romanian keyboards. Patch mostly due to Andrei Damian-Fekete. [originally from svn r9942]
2013-07-20 11:31:24 +00:00
keys_unicode, lenof(keys_unicode));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
#ifdef SHOW_TOASCII_RESULT
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (r == 1 && !key_down) {
if (alt_sum) {
if (in_utf(term) || ucsdata.dbcs_screenfont)
debug(", (U+%04x)", alt_sum);
else
debug(", LCH(%d)", alt_sum);
} else {
debug(", ACH(%d)", keys_unicode[0]);
}
} else if (r > 0) {
int r1;
debug(", ASC(");
for (r1 = 0; r1 < r; r1++) {
debug("%s%d", r1 ? "," : "", keys_unicode[r1]);
}
debug(")");
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
#endif
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (r > 0) {
WCHAR keybuf;
p = output;
for (i = 0; i < r; i++) {
wchar_t wch = keys_unicode[i];
if (compose_state == 2 && wch >= ' ' && wch < 0x80) {
compose_char = wch;
compose_state++;
continue;
}
if (compose_state == 3 && wch >= ' ' && wch < 0x80) {
int nc;
compose_state = 0;
if ((nc = check_compose(compose_char, wch)) == -1) {
MessageBeep(MB_ICONHAND);
return 0;
}
keybuf = nc;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(term, &keybuf, 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
continue;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
compose_state = 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!key_down) {
if (alt_sum) {
if (in_utf(term) || ucsdata.dbcs_screenfont) {
keybuf = alt_sum;
Refactor terminal input to remove ldiscucs.c. The functions that previously lived in it now live in terminal.c itself; they've been renamed term_keyinput and term_keyinputw, and their function is to add data to the terminal's user input buffer from a char or wchar_t string respectively. They sit more comfortably in terminal.c anyway, because their whole point is to translate into the character encoding that the terminal is currently configured to use. Also, making them part of the terminal code means they can also take care of calling term_seen_key_event(), which simplifies most of the call sites in the GTK and Windows front ends. Generation of text _inside_ terminal.c, from responses to query escape sequences, is therefore not done by calling those external entry points: we send those responses directly to the ldisc, so that they don't count as keypresses for all the user-facing purposes like bell overload handling and scrollback reset. To make _that_ convenient, I've arranged that most of the code that previously lived in lpage_send and luni_send is now in separate translation functions, so those can still be called from situations where you're not going to do the default thing with the translated data. (However, pasted data _does_ still count as close enough to a keypress to call term_seen_key_event - but it clears the 'interactive' flag when the data is passed on to the line discipline, which tweaks a minor detail of control-char handling in line ending mode but mostly just means pastes aren't interrupted.)
2019-06-17 19:13:55 +00:00
term_keyinputw(term, &keybuf, 1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
char ch = (char) alt_sum;
/*
* We need not bother about stdin
* backlogs here, because in GUI PuTTY
* we can't do anything about it
* anyway; there's no means of asking
* Windows to hold off on KEYDOWN
* messages. We _have_ to buffer
* everything we're sent.
*/
term_keyinput(term, -1, &ch, 1);
}
alt_sum = 0;
} else {
term_keyinputw(term, &wch, 1);
}
} else {
if(capsOn && wch < 0x80) {
WCHAR cbuf[2];
cbuf[0] = 27;
cbuf[1] = xlat_uskbd2cyrllic(wch);
term_keyinputw(term, cbuf+!left_alt, 1+!!left_alt);
} else {
WCHAR cbuf[2];
cbuf[0] = '\033';
cbuf[1] = wch;
term_keyinputw(term, cbuf +!left_alt, 1+!!left_alt);
}
}
show_mouseptr(false);
}
/* This is so the ALT-Numpad and dead keys work correctly. */
keys_unicode[0] = 0;
return p - output;
}
/* If we're definitely not building up an ALT-54321 then clear it */
if (!left_alt)
keys_unicode[0] = 0;
/* If we will be using alt_sum fix the 256s */
else if (keys_unicode[0] && (in_utf(term) || ucsdata.dbcs_screenfont))
keys_unicode[0] = 10;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Robert de Bath's `Patch.a_alt_key': clean up the handling of Alt-Space, Alt-only and the System menu. It lets Windows do more of the work, and also saves a static variable, so it must be good :-) [originally from svn r1237]
2001-09-07 21:39:03 +00:00
/*
* ALT alone may or may not want to bring up the System menu.
* If it's not meant to, we return 0 on presses or releases of
* ALT, to show that we've swallowed the keystroke. Otherwise
* we return -1, which means Windows will give the keystroke
* its default handling (i.e. bring up the System menu).
*/
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (wParam == VK_MENU && !conf_get_bool(conf, CONF_alt_only))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
return -1;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_set_title(TermWin *tw, const char *title)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
sfree(window_name);
Introduced wrapper macros snew(), snewn() and sresize() for the 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]
2003-03-29 16:14:26 +00:00
window_name = snewn(1 + strlen(title), char);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
strcpy(window_name, title);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_win_name_always) || !IsIconic(hwnd))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetWindowText(hwnd, title);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_set_icon_title(TermWin *tw, const char *title)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
sfree(icon_name);
Introduced wrapper macros snew(), snewn() and sresize() for the 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]
2003-03-29 16:14:26 +00:00
icon_name = snewn(1 + strlen(title), char);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
strcpy(icon_name, title);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(conf, CONF_win_name_always) && IsIconic(hwnd))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetWindowText(hwnd, title);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_set_scrollbar(TermWin *tw, int total, int start, int page)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
SCROLLINFO si;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (!conf_get_bool(conf, is_full_screen() ?
CONF_scrollbar_in_fullscreen : CONF_scrollbar))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
si.cbSize = sizeof(si);
Robert de Bath's Big Patch, part 1 [originally from svn r516]
2000-07-26 12:13:51 +00:00
si.fMask = SIF_ALL | SIF_DISABLENOSCROLL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
si.nMin = 0;
si.nMax = total - 1;
si.nPage = page;
si.nPos = start;
Fix various segfaults and heap trashes. Thanks to Andrew Mobbs. [originally from svn r29]
1999-02-09 15:39:08 +00:00
if (hwnd)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetScrollInfo(hwnd, SB_VERT, &si, true);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool wintw_setup_draw_ctx(TermWin *tw)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
assert(!wintw_hdc);
wintw_hdc = make_hdc();
return wintw_hdc != NULL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_free_draw_ctx(TermWin *tw)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
assert(wintw_hdc);
free_hdc(wintw_hdc);
wintw_hdc = NULL;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
static void real_palette_set(int n, int r, int g, int b)
{
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
internal_set_colour(n, r, g, b);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (pal) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
logpal->palPalEntry[n].peRed = r;
logpal->palPalEntry[n].peGreen = g;
logpal->palPalEntry[n].peBlue = b;
logpal->palPalEntry[n].peFlags = PC_NOCOLLAPSE;
SetPaletteEntries(pal, 0, NALLCOLOURS, logpal->palPalEntry);
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool wintw_palette_get(TermWin *tw, int n, int *r, int *g, int *b)
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
{
if (n < 0 || n >= NALLCOLOURS)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
*r = colours_rgb[n].r;
*g = colours_rgb[n].g;
*b = colours_rgb[n].b;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_palette_set(TermWin *tw, int n, int r, int g, int b)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
if (n >= 16)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
n += 256 - 16;
Correct an inequality sign causing the bounds check in Windows palette_set() to be bogus. Fortunately, this isn't exploitable through the terminal emulator, because the palette escape sequence parser contains its own bounds check before even calling palette_set(). While I'm at it, fix the same goof in the OS X version! That port is more or less abandoned, but that's no excuse for leaving obviously wrong code lying around. [originally from svn r9965]
2013-07-22 07:12:26 +00:00
if (n >= NALLCOLOURS)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
real_palette_set(n, r, g, b);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (pal) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HDC hdc = make_hdc();
UnrealizeObject(pal);
RealizePalette(hdc);
free_hdc(hdc);
Alain Guibert points out that palette changes weren't causing the space between the text area and the window border to be refreshed. Fixed on Windows. Gtk still has a similar problem. [originally from svn r6583]
2006-02-25 14:13:46 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (n == (ATTR_DEFBG>>ATTR_BGSHIFT))
/* If Default Background changes, we need to ensure any
* space between the text area and the window border is
* redrawn. */
InvalidateRect(hwnd, NULL, true);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_palette_reset(TermWin *tw)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
int i;
Implement xterm 256-colour mode. [originally from svn r4917] [this svn revision also touched putty-wishlist]
2004-11-28 15:13:34 +00:00
/* And this */
for (i = 0; i < NALLCOLOURS; i++) {
Support OSC 4 terminal colour-palette queries. Markus Gans points out that some applications which (not at all unreasonably) don't trust $TERM to tell them the full capabilities of their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for the colour-palette value in position nn, and they may not particularly care _what_ the results are but they will use them to decide whether the right number of colour palette entries even exist.
2017-10-05 19:43:02 +00:00
internal_set_colour(i, defpal[i].rgbtRed,
defpal[i].rgbtGreen, defpal[i].rgbtBlue);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (pal) {
logpal->palPalEntry[i].peRed = defpal[i].rgbtRed;
logpal->palPalEntry[i].peGreen = defpal[i].rgbtGreen;
logpal->palPalEntry[i].peBlue = defpal[i].rgbtBlue;
logpal->palPalEntry[i].peFlags = 0;
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
if (pal) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HDC hdc;
SetPaletteEntries(pal, 0, NALLCOLOURS, logpal->palPalEntry);
hdc = make_hdc();
RealizePalette(hdc);
free_hdc(hdc);
Alain Guibert points out that palette changes weren't causing the space between the text area and the window border to be refreshed. Fixed on Windows. Gtk still has a similar problem. [originally from svn r6583]
2006-02-25 14:13:46 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* Default Background may have changed. Ensure any space between
* text area and window border is redrawn. */
InvalidateRect(hwnd, NULL, true);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void write_aclip(int clipboard, char *data, int len, bool must_deselect)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
HGLOBAL clipdata;
void *lock;
Add a system of clipboard identifiers. This lays some groundwork for making PuTTY's cut and paste handling more flexible in the area of which clipboard(s) it reads and writes, if more than one is available on the system. I've introduced a system of list macros which define an enumeration of integer clipboard ids, some defined centrally in putty.h (at present just a CLIP_NULL which never has any text in it, because that seems like the sort of thing that will come in useful for configuring a given copy or paste UI action to be ignored) and some defined per platform. All the front end functions that copy and paste take a clipboard id, and the Terminal structure is now configured at startup to tell it which clipboard id it should paste from on a mouse click, and which it should copy from on a selection. However, I haven't actually added _real_ support for multiple X11 clipboards, in that the Unix front end supports a single CLIP_SYSTEM regardless of whether it's in OS X or GTK mode. So this is currently a NFC refactoring which does nothing but prepare the way for real changes to come.
2017-12-09 12:00:13 +00:00
if (clipboard != CLIP_SYSTEM)
return;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
clipdata = GlobalAlloc(GMEM_DDESHARE | GMEM_MOVEABLE, len + 1);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (!clipdata)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
lock = GlobalLock(clipdata);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
if (!lock)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
memcpy(lock, data, len);
((unsigned char *) lock)[len] = 0;
GlobalUnlock(clipdata);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Add a parameter to write_clip() so that windlg.c need not call term_deselect [originally from svn r681]
2000-10-06 12:32:25 +00:00
if (!must_deselect)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_IGNORE_CLIP, true, 0);
Add a parameter to write_clip() so that windlg.c need not call term_deselect [originally from svn r681]
2000-10-06 12:32:25 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (OpenClipboard(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
EmptyClipboard();
SetClipboardData(CF_TEXT, clipdata);
CloseClipboard();
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GlobalFree(clipdata);
Add a parameter to write_clip() so that windlg.c need not call term_deselect [originally from svn r681]
2000-10-06 12:32:25 +00:00
if (!must_deselect)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_IGNORE_CLIP, false, 0);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Implement true-colour in write_clip for Windows This allows text copied from PuTTY to a rich-text program to retain the true-colour attribute.
2017-06-13 04:55:57 +00:00
typedef struct _rgbindex {
int index;
COLORREF ref;
} rgbindex;
int cmpCOLORREF(void *va, void *vb)
{
COLORREF a = ((rgbindex *)va)->ref;
COLORREF b = ((rgbindex *)vb)->ref;
return (a < b) ? -1 : (a > b) ? +1 : 0;
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
/*
* Note: unlike write_aclip() this will not append a nul.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_clip_write(
TermWin *tw, int clipboard, wchar_t *data, int *attr,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
truecolour *truecolour, int len, bool must_deselect)
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
{
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
HGLOBAL clipdata, clipdata2, clipdata3;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
int len2;
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
void *lock, *lock2, *lock3;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
Add a system of clipboard identifiers. This lays some groundwork for making PuTTY's cut and paste handling more flexible in the area of which clipboard(s) it reads and writes, if more than one is available on the system. I've introduced a system of list macros which define an enumeration of integer clipboard ids, some defined centrally in putty.h (at present just a CLIP_NULL which never has any text in it, because that seems like the sort of thing that will come in useful for configuring a given copy or paste UI action to be ignored) and some defined per platform. All the front end functions that copy and paste take a clipboard id, and the Terminal structure is now configured at startup to tell it which clipboard id it should paste from on a mouse click, and which it should copy from on a selection. However, I haven't actually added _real_ support for multiple X11 clipboards, in that the Unix front end supports a single CLIP_SYSTEM regardless of whether it's in OS X or GTK mode. So this is currently a NFC refactoring which does nothing but prepare the way for real changes to come.
2017-12-09 12:00:13 +00:00
if (clipboard != CLIP_SYSTEM)
return;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
len2 = WideCharToMultiByte(CP_ACP, 0, data, len, 0, 0, NULL, NULL);
clipdata = GlobalAlloc(GMEM_DDESHARE | GMEM_MOVEABLE,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
len * sizeof(wchar_t));
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
clipdata2 = GlobalAlloc(GMEM_DDESHARE | GMEM_MOVEABLE, len2);
Fix compiler warnings [originally from svn r1469]
2001-12-11 18:47:35 +00:00
if (!clipdata || !clipdata2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (clipdata)
GlobalFree(clipdata);
if (clipdata2)
GlobalFree(clipdata2);
return;
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
Another big batch of memory leak fixes, again mostly on error paths. The most interesting one is printer_add_enum, which I've modified to take a char ** rather than a char * so that it can both realloc its input buffer _and_ return NULL to indicate error. [originally from svn r9959]
2013-07-22 07:11:54 +00:00
if (!(lock = GlobalLock(clipdata))) {
GlobalFree(clipdata);
GlobalFree(clipdata2);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Another big batch of memory leak fixes, again mostly on error paths. The most interesting one is printer_add_enum, which I've modified to take a char ** rather than a char * so that it can both realloc its input buffer _and_ return NULL to indicate error. [originally from svn r9959]
2013-07-22 07:11:54 +00:00
}
if (!(lock2 = GlobalLock(clipdata2))) {
GlobalUnlock(clipdata);
GlobalFree(clipdata);
GlobalFree(clipdata2);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Another big batch of memory leak fixes, again mostly on error paths. The most interesting one is printer_add_enum, which I've modified to take a char ** rather than a char * so that it can both realloc its input buffer _and_ return NULL to indicate error. [originally from svn r9959]
2013-07-22 07:11:54 +00:00
}
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
memcpy(lock, data, len * sizeof(wchar_t));
WideCharToMultiByte(CP_ACP, 0, data, len, lock2, len2, NULL, NULL);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_rtf_paste)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wchar_t unitab[256];
strbuf *rtf = strbuf_new();
unsigned char *tdata = (unsigned char *)lock2;
wchar_t *udata = (wchar_t *)lock;
int uindex = 0, tindex = 0;
int multilen, blen, alen, totallen, i;
char before[16], after[4];
int fgcolour, lastfgcolour = -1;
int bgcolour, lastbgcolour = -1;
COLORREF fg, lastfg = -1;
COLORREF bg, lastbg = -1;
int attrBold, lastAttrBold = 0;
int attrUnder, lastAttrUnder = 0;
int palette[NALLCOLOURS];
int numcolours;
tree234 *rgbtree = NULL;
FontSpec *font = conf_get_fontspec(conf, CONF_font);
get_unitab(CP_ACP, unitab, 0);
strbuf_catf(
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
rtf, "{\\rtf1\\ansi\\deff0{\\fonttbl\\f0\\fmodern %s;}\\f0\\fs%d",
font->name, font->height*2);
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Add colour palette
* {\colortbl ;\red255\green0\blue0;\red0\green0\blue128;}
*/
/*
* First - Determine all colours in use
* o Foregound and background colours share the same palette
*/
if (attr) {
memset(palette, 0, sizeof(palette));
for (i = 0; i < (len-1); i++) {
fgcolour = ((attr[i] & ATTR_FGMASK) >> ATTR_FGSHIFT);
bgcolour = ((attr[i] & ATTR_BGMASK) >> ATTR_BGSHIFT);
if (attr[i] & ATTR_REVERSE) {
int tmpcolour = fgcolour; /* Swap foreground and background */
fgcolour = bgcolour;
bgcolour = tmpcolour;
}
if (bold_colours && (attr[i] & ATTR_BOLD)) {
if (fgcolour < 8) /* ANSI colours */
fgcolour += 8;
else if (fgcolour >= 256) /* Default colours */
fgcolour ++;
}
if ((attr[i] & ATTR_BLINK)) {
if (bgcolour < 8) /* ANSI colours */
bgcolour += 8;
else if (bgcolour >= 256) /* Default colours */
bgcolour ++;
}
palette[fgcolour]++;
palette[bgcolour]++;
}
if (truecolour) {
rgbtree = newtree234(cmpCOLORREF);
for (i = 0; i < (len-1); i++) {
if (truecolour[i].fg.enabled) {
rgbindex *rgbp = snew(rgbindex);
rgbp->ref = RGB(truecolour[i].fg.r,
truecolour[i].fg.g,
truecolour[i].fg.b);
if (add234(rgbtree, rgbp) != rgbp)
sfree(rgbp);
}
if (truecolour[i].bg.enabled) {
rgbindex *rgbp = snew(rgbindex);
rgbp->ref = RGB(truecolour[i].bg.r,
truecolour[i].bg.g,
truecolour[i].bg.b);
if (add234(rgbtree, rgbp) != rgbp)
sfree(rgbp);
}
}
}
/*
* Next - Create a reduced palette
*/
numcolours = 0;
for (i = 0; i < NALLCOLOURS; i++) {
if (palette[i] != 0)
palette[i] = ++numcolours;
}
if (rgbtree) {
rgbindex *rgbp;
for (i = 0; (rgbp = index234(rgbtree, i)) != NULL; i++)
rgbp->index = ++numcolours;
}
/*
* Finally - Write the colour table
*/
put_datapl(rtf, PTRLEN_LITERAL("{\\colortbl ;"));
for (i = 0; i < NALLCOLOURS; i++) {
if (palette[i] != 0) {
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
strbuf_catf(rtf, "\\red%d\\green%d\\blue%d;",
defpal[i].rgbtRed, defpal[i].rgbtGreen,
defpal[i].rgbtBlue);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
if (rgbtree) {
rgbindex *rgbp;
for (i = 0; (rgbp = index234(rgbtree, i)) != NULL; i++)
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
strbuf_catf(rtf, "\\red%d\\green%d\\blue%d;",
GetRValue(rgbp->ref), GetGValue(rgbp->ref),
GetBValue(rgbp->ref));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
put_datapl(rtf, PTRLEN_LITERAL("}"));
}
/*
* We want to construct a piece of RTF that specifies the
* same Unicode text. To do this we will read back in
* parallel from the Unicode data in `udata' and the
* non-Unicode data in `tdata'. For each character in
* `tdata' which becomes the right thing in `udata' when
* looked up in `unitab', we just copy straight over from
* tdata. For each one that doesn't, we must WCToMB it
* individually and produce a \u escape sequence.
*
* It would probably be more robust to just bite the bullet
* and WCToMB each individual Unicode character one by one,
* then MBToWC each one back to see if it was an accurate
* translation; but that strikes me as a horrifying number
* of Windows API calls so I want to see if this faster way
* will work. If it screws up badly we can always revert to
* the simple and slow way.
*/
while (tindex < len2 && uindex < len &&
tdata[tindex] && udata[uindex]) {
if (tindex + 1 < len2 &&
tdata[tindex] == '\r' &&
tdata[tindex+1] == '\n') {
tindex++;
uindex++;
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
}
/*
* Set text attributes
*/
if (attr) {
/*
* Determine foreground and background colours
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (truecolour && truecolour[tindex].fg.enabled) {
fgcolour = -1;
fg = RGB(truecolour[tindex].fg.r,
truecolour[tindex].fg.g,
truecolour[tindex].fg.b);
} else {
fgcolour = ((attr[tindex] & ATTR_FGMASK) >> ATTR_FGSHIFT);
fg = -1;
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (truecolour && truecolour[tindex].bg.enabled) {
bgcolour = -1;
bg = RGB(truecolour[tindex].bg.r,
truecolour[tindex].bg.g,
truecolour[tindex].bg.b);
} else {
bgcolour = ((attr[tindex] & ATTR_BGMASK) >> ATTR_BGSHIFT);
bg = -1;
}
if (attr[tindex] & ATTR_REVERSE) {
int tmpcolour = fgcolour; /* Swap foreground and background */
fgcolour = bgcolour;
bgcolour = tmpcolour;
COLORREF tmpref = fg;
fg = bg;
bg = tmpref;
}
if (bold_colours && (attr[tindex] & ATTR_BOLD) && (fgcolour >= 0)) {
if (fgcolour < 8) /* ANSI colours */
fgcolour += 8;
else if (fgcolour >= 256) /* Default colours */
fgcolour ++;
}
if ((attr[tindex] & ATTR_BLINK) && (bgcolour >= 0)) {
if (bgcolour < 8) /* ANSI colours */
bgcolour += 8;
else if (bgcolour >= 256) /* Default colours */
bgcolour ++;
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
}
/*
* Collect other attributes
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (bold_font_mode != BOLD_NONE)
attrBold = attr[tindex] & ATTR_BOLD;
else
attrBold = 0;
attrUnder = attr[tindex] & ATTR_UNDER;
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
/*
* Reverse video
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* o If video isn't reversed, ignore colour attributes for default foregound
* or background.
* o Special case where bolded text is displayed using the default foregound
* and background colours - force to bolded RTF.
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!(attr[tindex] & ATTR_REVERSE)) {
if (bgcolour >= 256) /* Default color */
bgcolour = -1; /* No coloring */
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (fgcolour >= 256) { /* Default colour */
if (bold_colours && (fgcolour & 1) && bgcolour == -1)
attrBold = ATTR_BOLD; /* Emphasize text with bold attribute */
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fgcolour = -1; /* No coloring */
}
}
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
/*
* Write RTF text attributes
*/
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((lastfgcolour != fgcolour) || (lastfg != fg)) {
lastfgcolour = fgcolour;
lastfg = fg;
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
if (fg == -1) {
strbuf_catf(rtf, "\\cf%d ",
(fgcolour >= 0) ? palette[fgcolour] : 0);
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
rgbindex rgb, *rgbp;
rgb.ref = fg;
if ((rgbp = find234(rgbtree, &rgb, NULL)) != NULL)
strbuf_catf(rtf, "\\cf%d ", rgbp->index);
}
}
if ((lastbgcolour != bgcolour) || (lastbg != bg)) {
lastbgcolour = bgcolour;
lastbg = bg;
if (bg == -1)
strbuf_catf(rtf, "\\highlight%d ",
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
(bgcolour >= 0) ? palette[bgcolour] : 0);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else {
rgbindex rgb, *rgbp;
rgb.ref = bg;
if ((rgbp = find234(rgbtree, &rgb, NULL)) != NULL)
strbuf_catf(rtf, "\\highlight%d ", rgbp->index);
}
}
if (lastAttrBold != attrBold) {
lastAttrBold = attrBold;
put_datapl(rtf, attrBold ?
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
PTRLEN_LITERAL("\\b ") :
PTRLEN_LITERAL("\\b0 "));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
if (lastAttrUnder != attrUnder) {
lastAttrUnder = attrUnder;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
put_datapl(rtf, attrUnder ?
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
PTRLEN_LITERAL("\\ul ") :
PTRLEN_LITERAL("\\ulnone "));
Preserve more attributes of text copied as RTF. Thanks to Stephen Balousek. [originally from svn r6555]
2006-02-13 22:18:17 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
if (unitab[tdata[tindex]] == udata[uindex]) {
multilen = 1;
before[0] = '\0';
after[0] = '\0';
blen = alen = 0;
} else {
multilen = WideCharToMultiByte(CP_ACP, 0, unitab+uindex, 1,
NULL, 0, NULL, NULL);
if (multilen != 1) {
blen = sprintf(before, "{\\uc%d\\u%d", (int)multilen,
(int)udata[uindex]);
alen = 1; strcpy(after, "}");
} else {
blen = sprintf(before, "\\u%d", udata[uindex]);
alen = 0; after[0] = '\0';
}
}
assert(tindex + multilen <= len2);
totallen = blen + alen;
for (i = 0; i < multilen; i++) {
if (tdata[tindex+i] == '\\' ||
tdata[tindex+i] == '{' ||
tdata[tindex+i] == '}')
totallen += 2;
else if (tdata[tindex+i] == 0x0D || tdata[tindex+i] == 0x0A)
totallen += 6; /* \par\r\n */
else if (tdata[tindex+i] > 0x7E || tdata[tindex+i] < 0x20)
totallen += 4;
else
totallen++;
}
put_data(rtf, before, blen);
for (i = 0; i < multilen; i++) {
if (tdata[tindex+i] == '\\' ||
tdata[tindex+i] == '{' ||
tdata[tindex+i] == '}') {
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
put_byte(rtf, '\\');
put_byte(rtf, tdata[tindex+i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (tdata[tindex+i] == 0x0D || tdata[tindex+i] == 0x0A) {
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
put_datapl(rtf, PTRLEN_LITERAL("\\par\r\n"));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (tdata[tindex+i] > 0x7E || tdata[tindex+i] < 0x20) {
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
strbuf_catf(rtf, "\\'%02x", tdata[tindex+i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
put_byte(rtf, tdata[tindex+i]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
put_data(rtf, after, alen);
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tindex += multilen;
uindex++;
}
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
Replace more ad-hoc growing char buffers with strbuf. I've fixed a handful of these where I found them in passing, but when I went systematically looking, there were a lot more that I hadn't found! A particular highlight of this collection is the code that formats Windows clipboard data in RTF, which was absolutely crying out for strbuf_catf, and now it's got it.
2019-02-11 06:58:07 +00:00
put_datapl(rtf, PTRLEN_LITERAL("}\0\0")); /* Terminate RTF stream */
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
clipdata3 = GlobalAlloc(GMEM_DDESHARE | GMEM_MOVEABLE, rtf->len);
if (clipdata3 && (lock3 = GlobalLock(clipdata3)) != NULL) {
memcpy(lock3, rtf->u, rtf->len);
GlobalUnlock(clipdata3);
}
strbuf_free(rtf);
if (rgbtree) {
rgbindex *rgbp;
while ((rgbp = delpos234(rgbtree, 0)) != NULL)
sfree(rgbp);
freetree234(rgbtree);
}
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
clipdata3 = NULL;
Implement writing RTF to the clipboard (off by default), so that if you enable it text will paste into Word et al in the same font as PuTTY itself is displaying in. In particular, this will be a fixed- pitch font, so tables and `ls' and the like will naturally line up. [originally from svn r1373]
2001-11-07 22:22:53 +00:00
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
GlobalUnlock(clipdata);
GlobalUnlock(clipdata2);
if (!must_deselect)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_IGNORE_CLIP, true, 0);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
if (OpenClipboard(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
EmptyClipboard();
SetClipboardData(CF_UNICODETEXT, clipdata);
SetClipboardData(CF_TEXT, clipdata2);
if (clipdata3)
SetClipboardData(RegisterClipboardFormat(CF_RTF), clipdata3);
CloseClipboard();
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GlobalFree(clipdata);
GlobalFree(clipdata2);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
if (!must_deselect)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_IGNORE_CLIP, false, 0);
RDB's Unicode patch. Fonts are now used in Unicode mode where possible and we have a single unified means of trying to display any Unicode code point. Instead of the various ad-hoc translation modes we had before, we now have a single `codepage' option which allows us to treat the incoming (and outgoing) text as any given character set, and locally we map that to Unicode and back. [originally from svn r1110]
2001-05-10 08:34:20 +00:00
}
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
static DWORD WINAPI clipboard_read_threadfunc(void *param)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
HWND hwnd = (HWND)param;
HGLOBAL clipdata;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
if (OpenClipboard(NULL)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((clipdata = GetClipboardData(CF_UNICODETEXT))) {
SendMessage(hwnd, WM_GOT_CLIPDATA,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
(WPARAM)true, (LPARAM)clipdata);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if ((clipdata = GetClipboardData(CF_TEXT))) {
SendMessage(hwnd, WM_GOT_CLIPDATA,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
(WPARAM)false, (LPARAM)clipdata);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
CloseClipboard();
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
}
return 0;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void process_clipdata(HGLOBAL clipdata, bool unicode)
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
{
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
wchar_t *clipboard_contents = NULL;
size_t clipboard_length = 0;
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
if (unicode) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
wchar_t *p = GlobalLock(clipdata);
wchar_t *p2;
if (p) {
/* Unwilling to rely on Windows having wcslen() */
for (p2 = p; *p2; p2++);
clipboard_length = p2 - p;
clipboard_contents = snewn(clipboard_length + 1, wchar_t);
memcpy(clipboard_contents, p, clipboard_length * sizeof(wchar_t));
clipboard_contents[clipboard_length] = L'\0';
term_do_paste(term, clipboard_contents, clipboard_length);
}
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *s = GlobalLock(clipdata);
int i;
if (s) {
i = MultiByteToWideChar(CP_ACP, 0, s, strlen(s) + 1, 0, 0);
clipboard_contents = snewn(i, wchar_t);
MultiByteToWideChar(CP_ACP, 0, s, strlen(s) + 1,
clipboard_contents, i);
clipboard_length = i - 1;
clipboard_contents[clipboard_length] = L'\0';
term_do_paste(term, clipboard_contents, clipboard_length);
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Stop front ends remembering the data of their last paste. Previously, both the Unix and Windows front ends would respond to a paste action by retrieving data from the system clipboard, converting it appropriately, _storing_ it in a persistent dynamic data block inside the front end, and then calling term_do_paste(term), which in turn would call back to the front end via get_clip() to retrieve the current contents of that stored data block. But, as far as I can tell, this was a completely pointless mechanism, because after a data block was written into this storage area, it would be immediately used for exactly one paste, and then never accessed again until the next paste action caused it to be freed and replaced with a new chunk of pasted data. So why on earth was it stored persistently at all, and why that callback mechanism from frontend to terminal back to frontend to retrieve it for the actual paste action? I have no idea. This change removes the entire system and replaces it with the completely obvious alternative: the character-set-converted version of paste data is allocated in a _local_ variable in the frontend paste functions, passed directly to term_do_paste which now takes (buffer,length) parameters, and freed immediately afterwards. get_clip() is gone.
2017-12-09 08:41:03 +00:00
sfree(clipboard_contents);
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
}
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_clip_request_paste(TermWin *tw, int clipboard)
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
{
Add a system of clipboard identifiers. This lays some groundwork for making PuTTY's cut and paste handling more flexible in the area of which clipboard(s) it reads and writes, if more than one is available on the system. I've introduced a system of list macros which define an enumeration of integer clipboard ids, some defined centrally in putty.h (at present just a CLIP_NULL which never has any text in it, because that seems like the sort of thing that will come in useful for configuring a given copy or paste UI action to be ignored) and some defined per platform. All the front end functions that copy and paste take a clipboard id, and the Terminal structure is now configured at startup to tell it which clipboard id it should paste from on a mouse click, and which it should copy from on a selection. However, I haven't actually added _real_ support for multiple X11 clipboards, in that the Unix front end supports a single CLIP_SYSTEM regardless of whether it's in OS X or GTK mode. So this is currently a NFC refactoring which does nothing but prepare the way for real changes to come.
2017-12-09 12:00:13 +00:00
assert(clipboard == CLIP_SYSTEM);
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
/*
* I always thought pasting was synchronous in Windows; the
* clipboard access functions certainly _look_ synchronous,
* unlike the X ones. But in fact it seems that in some
* situations the contents of the clipboard might not be
* immediately available, and the clipboard-reading functions
* may block. This leads to trouble if the application
* delivering the clipboard data has to get hold of it by -
* for example - talking over a network connection which is
* forwarded through this very PuTTY.
*
* Hence, we spawn a subthread to read the clipboard, and do
* our paste when it's finished. The thread will send a
* message back to our main window when it terminates, and
* that tells us it's OK to paste.
*/
DWORD in_threadid; /* required for Win9x */
CreateThread(NULL, 0, clipboard_read_threadfunc,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
hwnd, 0, &in_threadid);
Move the code that reads the Windows clipboard into a trivial subthread, so that it won't deadlock if fetching the content of the clipboard turns out to depend on a network connection forwarded through PuTTY. [originally from svn r8338]
2008-11-28 18:28:23 +00:00
}
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
/*
* Print a modal (Really Bad) message box and perform a fatal exit.
*/
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void modalfatalbox(const char *fmt, ...)
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
{
va_list ap;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *message, *title;
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
va_start(ap, fmt);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
message = dupvprintf(fmt, ap);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
va_end(ap);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
title = dupprintf("%s Fatal Error", appname);
MessageBox(hwnd, message, title, MB_SYSTEMMODAL | MB_ICONERROR | MB_OK);
sfree(message);
sfree(title);
First phase of porting. pterm now compiles and runs under Linux+gtk. 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]
2002-10-09 18:09:42 +00:00
cleanup_exit(1);
}
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
/*
* Print a message box and don't close the connection.
*/
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void nonfatal(const char *fmt, ...)
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
{
va_list ap;
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *message, *title;
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
va_start(ap, fmt);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
message = dupvprintf(fmt, ap);
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
va_end(ap);
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
title = dupprintf("%s Error", appname);
MessageBox(hwnd, message, title, MB_ICONERROR | MB_OK);
sfree(message);
sfree(title);
Add a nonfatal() function everywhere, to be used for reporting things that the user really ought to know but that are not actually fatal to continued operation of PuTTY or a single network connection. [originally from svn r9932]
2013-07-19 17:44:28 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool flash_window_ex(DWORD dwFlags, UINT uCount, DWORD dwTimeout)
At least, I have the technology to fix `beepind-win2k'. Tested on Win98, Win2K, and WinXP. [originally from svn r7119] [this svn revision also touched putty-wishlist]
2007-01-16 20:54:58 +00:00
{
if (p_FlashWindowEx) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
FLASHWINFO fi;
fi.cbSize = sizeof(fi);
fi.hwnd = hwnd;
fi.dwFlags = dwFlags;
fi.uCount = uCount;
fi.dwTimeout = dwTimeout;
return (*p_FlashWindowEx)(&fi);
At least, I have the technology to fix `beepind-win2k'. Tested on Win98, Win2K, and WinXP. [originally from svn r7119] [this svn revision also touched putty-wishlist]
2007-01-16 20:54:58 +00:00
}
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false; /* shrug */
At least, I have the technology to fix `beepind-win2k'. Tested on Win98, Win2K, and WinXP. [originally from svn r7119] [this svn revision also touched putty-wishlist]
2007-01-16 20:54:58 +00:00
}
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
static void flash_window(int mode);
static long next_flash;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool flashing = false;
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
At least, I have the technology to fix `beepind-win2k'. Tested on Win98, Win2K, and WinXP. [originally from svn r7119] [this svn revision also touched putty-wishlist]
2007-01-16 20:54:58 +00:00
/*
* Timer for platforms where we must maintain window flashing manually
* (e.g., Win95).
*/
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-18 21:42:48 +00:00
static void flash_window_timer(void *ctx, unsigned long now)
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
{
Two related changes to timing code: First, make absolute times unsigned. This means that it's safe to depend on their overflow behaviour (which is undefined for signed integers). This requires a little extra care in handling comparisons, but I think I've correctly adjusted them all. Second, functions registered with schedule_timer() are guaranteed to be called with precisely the time that was returned by schedule_timer(). Thus, it's only necessary to check these values for equality rather than doing risky range checks, so do that. The timing code still does lots that's undefined, unnecessary, or just wrong, but this is a good start. [originally from svn r9667]
2012-09-18 21:42:48 +00:00
if (flashing && now == next_flash) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
flash_window(1);
New timing infrastructure. There's a new function schedule_timer() 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]
2004-11-27 13:20:21 +00:00
}
}
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
/*
* Manage window caption / taskbar flashing, if enabled.
* 0 = stop, 1 = maintain, 2 = start
*/
static void flash_window(int mode)
{
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int beep_ind = conf_get_int(conf, CONF_beep_ind);
if ((mode == 0) || (beep_ind == B_IND_DISABLED)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* stop */
if (flashing) {
flashing = false;
if (p_FlashWindowEx)
flash_window_ex(FLASHW_STOP, 0, 0);
else
FlashWindow(hwnd, false);
}
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
} else if (mode == 2) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* start */
if (!flashing) {
flashing = true;
if (p_FlashWindowEx) {
/* For so-called "steady" mode, we use uCount=2, which
* seems to be the traditional number of flashes used
* by user notifications (e.g., by Explorer).
* uCount=0 appears to enable continuous flashing, per
* "flashing" mode, although I haven't seen this
* documented. */
flash_window_ex(FLASHW_ALL | FLASHW_TIMER,
(beep_ind == B_IND_FLASH ? 0 : 2),
0 /* system cursor blink rate */);
/* No need to schedule timer */
} else {
FlashWindow(hwnd, true);
next_flash = schedule_timer(450, flash_window_timer, hwnd);
}
}
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
} else if ((mode == 1) && (beep_ind == B_IND_FLASH)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* maintain */
if (flashing && !p_FlashWindowEx) {
FlashWindow(hwnd, true); /* toggle */
next_flash = schedule_timer(450, flash_window_timer, hwnd);
}
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
}
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
* Beep.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_bell(TermWin *tw, int mode)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Bell can now play an arbitrary sound file. [originally from svn r1041]
2001-04-14 11:37:47 +00:00
if (mode == BELL_DEFAULT) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* For MessageBeep style bells, we want to be careful of
* timing, because they don't have the nice property of
* PlaySound bells that each one cancels the previous
* active one. So we limit the rate to one per 50ms or so.
*/
static long lastbeep = 0;
long beepdiff;
beepdiff = GetTickCount() - lastbeep;
if (beepdiff >= 0 && beepdiff < 50)
return;
MessageBeep(MB_OK);
/*
* The above MessageBeep call takes time, so we record the
* time _after_ it finishes rather than before it starts.
*/
lastbeep = GetTickCount();
Bell can now play an arbitrary sound file. [originally from svn r1041]
2001-04-14 11:37:47 +00:00
} else if (mode == BELL_WAVEFILE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Filename *bell_wavefile = conf_get_filename(conf, CONF_bell_wavefile);
if (!p_PlaySound || !p_PlaySound(bell_wavefile->path, NULL,
Load winmm.dll (for PlaySound()) at run time. It's not on the default list of important system 'known DLLs' stored at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs (see https://isc.sans.edu/forums/diary/DLL+hijacking+vulnerabilities/9445/ ) which apparently makes it exempt from Windows's standard DLL hijacking defence, i.e. if an executable links against it in the normal way then that executable will be vulnerable to DLL hijacking from a file called winmm.dll in the same directory as it. The solution is to load it dynamically _after_ we've locked down our DLL search path, which fortunately PuTTY's code base is well used to doing already for other DLLs.
2017-03-13 21:24:06 +00:00
SND_ASYNC | SND_FILENAME)) {
Remove a load of obsolete printf string limits. In the previous commit I happened to notice a %.150s in a ppl_logevent call, which was probably an important safety precaution a couple of decades ago when that format string was being used for an sprintf into a fixed-size buffer, but now it's just pointless cruft. This commit removes all printf string formatting directives with a compile-time fixed size, with the one exception of a %.3s used to cut out a 3-letter month name in scpserver.c. In cases where the format string in question was already going to an arbitrary-length function like dupprintf or ppl_logevent, that's all I've done; in cases where there was still a fixed-size buffer, I've replaced it with a dynamic buffer and dupprintf.
2018-12-08 21:03:51 +00:00
char *buf, *otherbuf;
buf = dupprintf(
"Unable to play sound file\n%s\nUsing default sound instead",
bell_wavefile->path);
otherbuf = dupprintf("%s Sound Error", appname);
MessageBox(hwnd, buf, otherbuf, MB_OK | MB_ICONEXCLAMATION);
sfree(buf);
sfree(otherbuf);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
conf_set_int(conf, CONF_beep, BELL_DEFAULT);
}
Modified form of Jim Lucas's PC speaker patch. I don't like discriminating on the Windows version in order to decide whether to call MessageBeep(-1) or Beep() - I'd prefer to directly test the specific OS property in any given case - but it looks as if this is the best available option. [originally from svn r3208]
2003-05-24 12:31:32 +00:00
} else if (mode == BELL_PCSPEAKER) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
static long lastbeep = 0;
long beepdiff;
beepdiff = GetTickCount() - lastbeep;
if (beepdiff >= 0 && beepdiff < 50)
return;
/*
* We must beep in different ways depending on whether this
* is a 95-series or NT-series OS.
*/
if (osPlatformId == VER_PLATFORM_WIN32_NT)
Beep(800, 100);
else
MessageBeep(-1);
lastbeep = GetTickCount();
Bell can now play an arbitrary sound file. [originally from svn r1041]
2001-04-14 11:37:47 +00:00
}
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
/* Otherwise, either visual bell or disabled; do nothing here */
Major destabilisation, phase 1. In this phase I've moved (I think) 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]
2002-10-22 16:11:33 +00:00
if (!term->has_focus) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
flash_window(2); /* start */
Glenn Maynard's patch (as adapted by Jacob) for taskbar flashing when a bell occurs and the window is minimised. [originally from svn r1123]
2001-05-13 14:42:17 +00:00
}
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
Christopher Allene's patch for going full-screen on Alt-Enter. [originally from svn r1267]
2001-09-13 18:24:51 +00:00
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
/*
* Minimise or restore the window in response to a server-side
* request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_minimised(TermWin *tw, bool minimised)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
if (IsIconic(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!minimised)
ShowWindow(hwnd, SW_RESTORE);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (minimised)
ShowWindow(hwnd, SW_MINIMIZE);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
}
}
/*
* Move the window in response to a server-side request.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_move(TermWin *tw, int x, int y)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
int resize_action = conf_get_int(conf, CONF_resize_action);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (resize_action == RESIZE_DISABLED ||
resize_action == RESIZE_FONT ||
IsZoomed(hwnd))
Patch from RDB: the xterm move-window sequences now don't screw up when the window is e.g. maximised. [originally from svn r1533]
2002-01-08 09:56:06 +00:00
return;
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
SetWindowPos(hwnd, NULL, x, y, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
}
/*
* Move the window to the top or bottom of the z-order in response
* to a server-side request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_zorder(TermWin *tw, bool top)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_alwaysontop))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return; /* ignore */
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
SetWindowPos(hwnd, top ? HWND_TOP : HWND_BOTTOM, 0, 0, 0, 0,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SWP_NOMOVE | SWP_NOSIZE);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
}
/*
* Refresh the window in response to a server-side request.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_refresh(TermWin *tw)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
InvalidateRect(hwnd, NULL, true);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
}
/*
* Maximise or restore the window in response to a server-side
* request.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static void wintw_set_maximised(TermWin *tw, bool maximised)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
if (IsZoomed(hwnd)) {
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
if (!maximised)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ShowWindow(hwnd, SW_RESTORE);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (maximised)
ShowWindow(hwnd, SW_MAXIMIZE);
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
}
}
/*
* Report whether the window is iconic, for terminal reports.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool wintw_is_minimised(TermWin *tw)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
return IsIconic(hwnd);
}
/*
* Report the window's position, for terminal reports.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_get_pos(TermWin *tw, int *x, int *y)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
RECT r;
GetWindowRect(hwnd, &r);
*x = r.left;
*y = r.top;
}
/*
* Report the window's pixel size, for terminal reports.
*/
Remove the 'Frontend' type and replace it with a vtable. After the recent Seat and LogContext revamps, _nearly_ all the remaining uses of the type 'Frontend' were in terminal.c, which needs all sorts of interactions with the GUI window the terminal lives in, from the obvious (actually drawing text on the window, reading and writing the clipboard) to the obscure (minimising, maximising and moving the window in response to particular escape sequences). All of those functions are now provided by an abstraction called TermWin. The few remaining uses of Frontend after _that_ are internal to a particular platform directory, so as to spread the implementation of that particular kind of Frontend between multiple source files; so I've renamed all of those so that they take a more specifically named type that refers to the particular implementation rather than the general abstraction. So now the name 'Frontend' no longer exists in the code base at all, and everywhere one used to be used, it's completely clear whether it was operating in one of Frontend's three abstract roles (and if so, which), or whether it was specific to a particular implementation. Another type that's disappeared is 'Context', which used to be a typedef defined to something different on each platform, describing whatever short-lived resources were necessary to draw on the terminal window: the front end would provide a ready-made one when calling term_paint, and the terminal could request one with get_ctx/free_ctx if it wanted to do proactive window updates. Now that drawing context lives inside the TermWin itself, because there was never any need to have two of those contexts live at the same time. (Another minor API change is that the window-title functions - both reading and writing - have had a missing 'const' added to their char * parameters / return values.) I don't expect this change to enable any particularly interesting new functionality (in particular, I have no plans that need more than one implementation of TermWin in the same application). But it completes the tidying-up that began with the Seat and LogContext rework.
2018-10-25 17:44:04 +00:00
static void wintw_get_pixels(TermWin *tw, int *x, int *y)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
RECT r;
GetWindowRect(hwnd, &r);
*x = r.right - r.left;
*y = r.bottom - r.top;
}
/*
* Return the window or icon title.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static const char *wintw_get_title(TermWin *tw, bool icon)
Add support for most of the ESC[<low number>t sequences, which xterm uses to manipulate the window (minimise, maximise, front, back, move, resize) and report things about the window (is it minimised or maximised, how big is it, what's its title). Missing are ESC[4;X;Yt (resize to a specified pixel size; our resize code doesn't like it) and ESC[19;X;Yt (report size of _screen_ in _characters_, which it isn't even obvious how to do when you've got a variable font size). [originally from svn r1414]
2001-11-25 15:21:25 +00:00
{
return icon ? icon_name : window_name;
}
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
/*
* See if we're in full-screen mode.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool is_full_screen()
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
{
if (!IsZoomed(hwnd))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Use {Get,Set}WindowLongPtr() instead of {Get,Set}WindowLong() for compatibility with 64-bit Windows. Untested on 64-bit, but it doesn't appear to have broken anything on 32-bit. [originally from svn r5819]
2005-05-21 14:16:43 +00:00
if (GetWindowLongPtr(hwnd, GWL_STYLE) & WS_CAPTION)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return false;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
}
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
/* Get the rect/size of a full screen window using the nearest available
* monitor in multimon systems; default to something sensible if only
* one monitor is present. */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool get_fullscreen_rect(RECT * ss)
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
{
Andy Hood points out that `#ifdef MONITOR_DEFAULTTONEAREST' would benefit from _also_ being conditional on NO_MULTIMON not being defined, to prevent the possibility of only half the multimon code being included. [originally from svn r3644]
2003-12-16 18:28:43 +00:00
#if defined(MONITOR_DEFAULTTONEAREST) && !defined(NO_MULTIMON)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HMONITOR mon;
MONITORINFO mi;
mon = MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST);
mi.cbSize = sizeof(mi);
GetMonitorInfo(mon, &mi);
/* structure copy */
*ss = mi.rcMonitor;
return true;
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
#else
/* could also use code like this:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ss->left = ss->top = 0;
ss->right = GetSystemMetrics(SM_CXSCREEN);
ss->bottom = GetSystemMetrics(SM_CYSCREEN);
*/
return GetClientRect(GetDesktopWindow(), ss);
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
#endif
}
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
/*
* Go full-screen. This should only be called when we are already
* maximised.
*/
Alexey Savelyev's mkfiles.pl patch to support lcc-win32. This has caused a small amount of extra inconvenience at the tops of .rc files, but it's been positive overall since lcc has managed to point out some pedantic errors (typically static/extern mismatches between function prototypes and definitions) which everything else missed. [originally from svn r3744]
2004-01-20 20:35:27 +00:00
static void make_full_screen()
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
{
DWORD style;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
RECT ss;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
assert(IsZoomed(hwnd));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (is_full_screen())
return;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
/* Remove the window furniture. */
Use {Get,Set}WindowLongPtr() instead of {Get,Set}WindowLong() for compatibility with 64-bit Windows. Untested on 64-bit, but it doesn't appear to have broken anything on 32-bit. [originally from svn r5819]
2005-05-21 14:16:43 +00:00
style = GetWindowLongPtr(hwnd, GWL_STYLE);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
style &= ~(WS_CAPTION | WS_BORDER | WS_THICKFRAME);
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_scrollbar_in_fullscreen))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
style |= WS_VSCROLL;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
style &= ~WS_VSCROLL;
Use {Get,Set}WindowLongPtr() instead of {Get,Set}WindowLong() for compatibility with 64-bit Windows. Untested on 64-bit, but it doesn't appear to have broken anything on 32-bit. [originally from svn r5819]
2005-05-21 14:16:43 +00:00
SetWindowLongPtr(hwnd, GWL_STYLE, style);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
/* Resize ourselves to exactly cover the nearest monitor. */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
get_fullscreen_rect(&ss);
Fix multi-monitor / full-screen problems and clean up the code a little. Thanks to Wez Furlong for the patch. [originally from svn r1591]
2002-03-13 22:15:14 +00:00
SetWindowPos(hwnd, HWND_TOP, ss.left, ss.top,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ss.right - ss.left,
ss.bottom - ss.top,
SWP_FRAMECHANGED);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
Update size when going from maximised to full screen. [originally from svn r6618]
2006-03-29 17:55:40 +00:00
/* We may have changed size as a result */
reset_window(0);
Keep the state of the "Full Screen" menu item on the Ctrl+right-click context menu in sync with reality and the system menu. [originally from svn r8620]
2009-08-15 17:45:17 +00:00
/* Tick the menu item in the System and context menus. */
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
for (i = 0; i < lenof(popup_menus); i++)
CheckMenuItem(popup_menus[i].menu, IDM_FULLSCREEN, MF_CHECKED);
Keep the state of the "Full Screen" menu item on the Ctrl+right-click context menu in sync with reality and the system menu. [originally from svn r8620]
2009-08-15 17:45:17 +00:00
}
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
}
/*
* Clear the full-screen attributes.
*/
Alexey Savelyev's mkfiles.pl patch to support lcc-win32. This has caused a small amount of extra inconvenience at the tops of .rc files, but it's been positive overall since lcc has managed to point out some pedantic errors (typically static/extern mismatches between function prototypes and definitions) which everything else missed. [originally from svn r3744]
2004-01-20 20:35:27 +00:00
static void clear_full_screen()
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
{
DWORD oldstyle, style;
/* Reinstate the window furniture. */
Use {Get,Set}WindowLongPtr() instead of {Get,Set}WindowLong() for compatibility with 64-bit Windows. Untested on 64-bit, but it doesn't appear to have broken anything on 32-bit. [originally from svn r5819]
2005-05-21 14:16:43 +00:00
style = oldstyle = GetWindowLongPtr(hwnd, GWL_STYLE);
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
style |= WS_CAPTION | WS_BORDER;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
if (conf_get_int(conf, CONF_resize_action) == RESIZE_DISABLED)
Fixes to full-screen mode. There were various problems when you went full-screen, then selected Change Settings and then changed the resize behaviour, ranging from the window staying FS but acquiring borders to the window restoring its previous size and _failing_ to acquire borders. Should now all be fixed. [originally from svn r1470]
2001-12-11 18:47:55 +00:00
style &= ~WS_THICKFRAME;
else
style |= WS_THICKFRAME;
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
if (conf_get_bool(conf, CONF_scrollbar))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
style |= WS_VSCROLL;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
style &= ~WS_VSCROLL;
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
if (style != oldstyle) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetWindowLongPtr(hwnd, GWL_STYLE, style);
SetWindowPos(hwnd, NULL, 0, 0, 0, 0,
SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER |
SWP_FRAMECHANGED);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
}
Keep the state of the "Full Screen" menu item on the Ctrl+right-click context menu in sync with reality and the system menu. [originally from svn r8620]
2009-08-15 17:45:17 +00:00
/* Untick the menu item in the System and context menus. */
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
for (i = 0; i < lenof(popup_menus); i++)
CheckMenuItem(popup_menus[i].menu, IDM_FULLSCREEN, MF_UNCHECKED);
Keep the state of the "Full Screen" menu item on the Ctrl+right-click context menu in sync with reality and the system menu. [originally from svn r8620]
2009-08-15 17:45:17 +00:00
}
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
}
/*
* Toggle full-screen mode.
*/
Alexey Savelyev's mkfiles.pl patch to support lcc-win32. This has caused a small amount of extra inconvenience at the tops of .rc files, but it's been positive overall since lcc has managed to point out some pedantic errors (typically static/extern mismatches between function prototypes and definitions) which everything else missed. [originally from svn r3744]
2004-01-20 20:35:27 +00:00
static void flip_full_screen()
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
{
if (is_full_screen()) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ShowWindow(hwnd, SW_RESTORE);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
} else if (IsZoomed(hwnd)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
make_full_screen();
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SendMessage(hwnd, WM_FULLSCR_ON_MAX, 0, 0);
ShowWindow(hwnd, SW_MAXIMIZE);
FIFTH ATTEMPT at getting full-screen mode right. This new attempt (which I'll comment at some stage) should combine the believable semantics of RDB's fullscreen-by-maximise mode with the multi- monitor friendliness of Wez Furlong's approach while also working on Win98. If we're lucky. [originally from svn r1464]
2001-12-07 21:21:03 +00:00
}
}
Oops - repercussions of the close-on-exit stuff which I forgot to check in. I must stop doing my Unix checkins in the Unix subdir :-( [originally from svn r2125]
2002-10-24 14:12:55 +00:00
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static size_t win_seat_output(Seat *seat, bool is_stderr,
const void *data, size_t len)
Rationalisation of the system of frontend handles. Most modular bits of PuTTY (terminal, backend, logctx etc) take a `void *' handle passed to them from the frontend, and used as a context for all their callbacks. Most of these point at the frontend structure itself (on platforms where this is meaningful), except that the handle passed to the backend has always pointed at the terminal because from_backend() was implemented in terminal.c. This has finally bitten Unix PuTTY, because both backend and logctx have been passing their respective and very different frontend handles to logevent(), so I've fixed it. from_backend() is now a function supplied by the _frontend_ itself, in all cases, and the frontend handle passed to backends must be the same as that passed to everything else. What was from_backend() in terminal.c is now called term_data(), and the typical implementation of from_backend() in a GUI frontend will just extract the terminal handle from the frontend structure and delegate to that. This appears to work on Unix and Windows, but has most likely broken the Mac build. [originally from svn r3100]
2003-04-11 18:36:27 +00:00
{
return term_data(term, is_stderr, data, len);
}
Asynchronous agent requests on Windows. Actually, I've kept the ability to do synchronous ones as well, because PSCP and PSFTP don't really need async ones and it would have been a serious pain to implement them. Also, Pageant itself when run as a client of its primary instance doesn't benefit noticeably from async agent requests. [originally from svn r3154]
2003-04-28 13:59:32 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool win_seat_eof(Seat *seat)
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true; /* do respond to incoming EOF with outgoing */
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
static int win_seat_get_userpass_input(
Seat *seat, prompts_t *p, bufchain *input)
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
{
int ret;
Remove unused params from cmdline_get_passwd_input. NFC; I expect this to be a useful simplification for the same reasons as the previous commit.
2018-05-18 06:22:56 +00:00
ret = cmdline_get_passwd_input(p);
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
if (ret == -1)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = term_get_userpass_input(term, p, input);
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
return ret;
}
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
static bool win_seat_set_trust_status(Seat *seat, bool trusted)
{
term_set_trust_status(term, trusted);
return true;
}
Reference in New Issue Copy Permalink