1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
putty-source/windows/windlg.c

1024 lines
27 KiB
C
Raw Normal View History

/*
* windlg.c - dialogs for PuTTY(tel), including the configuration dialog.
*/
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <assert.h>
#include <ctype.h>
#include <time.h>
#include "putty.h"
#include "ssh.h"
#include "win_res.h"
#include "storage.h"
#include "dialog.h"
#include "licence.h"
#include <commctrl.h>
#include <commdlg.h>
#include <shellapi.h>
#ifdef MSVC4
#define TVINSERTSTRUCT TV_INSERTSTRUCT
#define TVITEM TV_ITEM
#define ICON_BIG 1
#endif
/*
* These are the various bits of data required to handle the
* portable-dialog stuff in the config box. Having them at file
* scope in here isn't too bad a place to put them; if we were ever
* to need more than one config box per process we could always
* shift them to a per-config-box structure stored in GWL_USERDATA.
*/
static struct controlbox *ctrlbox;
/*
* ctrls_base holds the OK and Cancel buttons: the controls which
* are present in all dialog panels. ctrls_panel holds the ones
* which change from panel to panel.
*/
static struct winctrls ctrls_base, ctrls_panel;
static struct dlgparam dp;
#define LOGEVENT_INITIAL_MAX 128
#define LOGEVENT_CIRCULAR_MAX 128
static char *events_initial[LOGEVENT_INITIAL_MAX];
static char *events_circular[LOGEVENT_CIRCULAR_MAX];
static int ninitial = 0, ncircular = 0, circular_first = 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
extern Conf *conf; /* defined in window.c */
#define PRINTER_DISABLED_STRING "None (printing disabled)"
void force_normal(HWND hwnd)
{
static int recurse = 0;
WINDOWPLACEMENT wp;
if (recurse)
return;
recurse = 1;
wp.length = sizeof(wp);
if (GetWindowPlacement(hwnd, &wp) && wp.showCmd == SW_SHOWMAXIMIZED) {
wp.showCmd = SW_SHOWNORMAL;
SetWindowPlacement(hwnd, &wp);
}
recurse = 0;
}
static char *getevent(int i)
{
if (i < ninitial)
return events_initial[i];
if ((i -= ninitial) < ncircular)
return events_circular[(circular_first + i) % LOGEVENT_CIRCULAR_MAX];
return NULL;
}
static INT_PTR CALLBACK LogProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
int i;
switch (msg) {
case WM_INITDIALOG:
{
char *str = dupprintf("%s Event Log", appname);
SetWindowText(hwnd, str);
sfree(str);
}
{
static int tabs[4] = { 78, 108 };
SendDlgItemMessage(hwnd, IDN_LIST, LB_SETTABSTOPS, 2,
(LPARAM) tabs);
}
for (i = 0; i < ninitial; i++)
SendDlgItemMessage(hwnd, IDN_LIST, LB_ADDSTRING,
0, (LPARAM) events_initial[i]);
for (i = 0; i < ncircular; i++)
SendDlgItemMessage(hwnd, IDN_LIST, LB_ADDSTRING,
0, (LPARAM) events_circular[(circular_first + i) % LOGEVENT_CIRCULAR_MAX]);
return 1;
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDOK:
case IDCANCEL:
logbox = NULL;
SetActiveWindow(GetParent(hwnd));
DestroyWindow(hwnd);
return 0;
case IDN_COPY:
if (HIWORD(wParam) == BN_CLICKED ||
HIWORD(wParam) == BN_DOUBLECLICKED) {
int selcount;
int *selitems;
selcount = SendDlgItemMessage(hwnd, IDN_LIST,
LB_GETSELCOUNT, 0, 0);
if (selcount == 0) { /* don't even try to copy zero items */
MessageBeep(0);
break;
}
selitems = snewn(selcount, int);
if (selitems) {
int count = SendDlgItemMessage(hwnd, IDN_LIST,
LB_GETSELITEMS,
selcount,
(LPARAM) selitems);
int i;
int size;
char *clipdata;
static unsigned char sel_nl[] = SEL_NL;
if (count == 0) { /* can't copy zero stuff */
MessageBeep(0);
break;
}
size = 0;
for (i = 0; i < count; i++)
size +=
strlen(getevent(selitems[i])) + sizeof(sel_nl);
clipdata = snewn(size, char);
if (clipdata) {
char *p = clipdata;
for (i = 0; i < count; i++) {
char *q = getevent(selitems[i]);
int qlen = strlen(q);
memcpy(p, q, qlen);
p += qlen;
memcpy(p, sel_nl, sizeof(sel_nl));
p += sizeof(sel_nl);
}
write_aclip(NULL, CLIP_SYSTEM, clipdata, size, TRUE);
sfree(clipdata);
}
sfree(selitems);
for (i = 0; i < (ninitial + ncircular); i++)
SendDlgItemMessage(hwnd, IDN_LIST, LB_SETSEL,
FALSE, i);
}
}
return 0;
}
return 0;
case WM_CLOSE:
logbox = NULL;
SetActiveWindow(GetParent(hwnd));
DestroyWindow(hwnd);
return 0;
}
return 0;
}
static INT_PTR CALLBACK LicenceProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch (msg) {
case WM_INITDIALOG:
{
char *str = dupprintf("%s Licence", appname);
SetWindowText(hwnd, str);
sfree(str);
SetDlgItemText(hwnd, IDA_TEXT, LICENCE_TEXT("\r\n\r\n"));
}
return 1;
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDOK:
case IDCANCEL:
EndDialog(hwnd, 1);
return 0;
}
return 0;
case WM_CLOSE:
EndDialog(hwnd, 1);
return 0;
}
return 0;
}
static INT_PTR CALLBACK AboutProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
char *str;
switch (msg) {
case WM_INITDIALOG:
str = dupprintf("About %s", appname);
SetWindowText(hwnd, str);
sfree(str);
{
char *buildinfo_text = buildinfo("\r\n");
char *text = dupprintf
("%s\r\n\r\n%s\r\n\r\n%s\r\n\r\n%s",
appname, ver, buildinfo_text,
"\251 " SHORT_COPYRIGHT_DETAILS ". All rights reserved.");
sfree(buildinfo_text);
SetDlgItemText(hwnd, IDA_TEXT, text);
sfree(text);
}
return 1;
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDOK:
case IDCANCEL:
EndDialog(hwnd, TRUE);
return 0;
case IDA_LICENCE:
EnableWindow(hwnd, 0);
DialogBox(hinst, MAKEINTRESOURCE(IDD_LICENCEBOX),
hwnd, LicenceProc);
EnableWindow(hwnd, 1);
SetActiveWindow(hwnd);
return 0;
case IDA_WEB:
/* Load web browser */
ShellExecute(hwnd, "open",
2017-05-07 15:29:01 +00:00
"https://www.chiark.greenend.org.uk/~sgtatham/putty/",
0, 0, SW_SHOWDEFAULT);
return 0;
}
return 0;
case WM_CLOSE:
EndDialog(hwnd, TRUE);
return 0;
}
return 0;
}
static int SaneDialogBox(HINSTANCE hinst,
LPCTSTR tmpl,
HWND hwndparent,
DLGPROC lpDialogFunc)
{
WNDCLASS wc;
HWND hwnd;
MSG msg;
int flags;
int ret;
int gm;
wc.style = CS_DBLCLKS | CS_SAVEBITS | CS_BYTEALIGNWINDOW;
wc.lpfnWndProc = DefDlgProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = DLGWINDOWEXTRA + 2*sizeof(LONG_PTR);
wc.hInstance = hinst;
wc.hIcon = NULL;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH) (COLOR_BACKGROUND +1);
wc.lpszMenuName = NULL;
wc.lpszClassName = "PuTTYConfigBox";
RegisterClass(&wc);
hwnd = CreateDialog(hinst, tmpl, hwndparent, lpDialogFunc);
SetWindowLongPtr(hwnd, BOXFLAGS, 0); /* flags */
SetWindowLongPtr(hwnd, BOXRESULT, 0); /* result from SaneEndDialog */
while ((gm=GetMessage(&msg, NULL, 0, 0)) > 0) {
flags=GetWindowLongPtr(hwnd, BOXFLAGS);
if (!(flags & DF_END) && !IsDialogMessage(hwnd, &msg))
DispatchMessage(&msg);
if (flags & DF_END)
break;
}
if (gm == 0)
PostQuitMessage(msg.wParam); /* We got a WM_QUIT, pass it on */
ret=GetWindowLongPtr(hwnd, BOXRESULT);
DestroyWindow(hwnd);
return ret;
}
static void SaneEndDialog(HWND hwnd, int ret)
{
SetWindowLongPtr(hwnd, BOXRESULT, ret);
SetWindowLongPtr(hwnd, BOXFLAGS, DF_END);
}
/*
* Null dialog procedure.
*/
static INT_PTR CALLBACK NullDlgProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
return 0;
}
enum {
IDCX_ABOUT = IDC_ABOUT,
IDCX_TVSTATIC,
IDCX_TREEVIEW,
IDCX_STDBASE,
IDCX_PANELBASE = IDCX_STDBASE + 32
};
struct treeview_faff {
HWND treeview;
HTREEITEM lastat[4];
};
static HTREEITEM treeview_insert(struct treeview_faff *faff,
int level, char *text, char *path)
{
TVINSERTSTRUCT ins;
int i;
HTREEITEM newitem;
ins.hParent = (level > 0 ? faff->lastat[level - 1] : TVI_ROOT);
ins.hInsertAfter = faff->lastat[level];
#if _WIN32_IE >= 0x0400 && defined NONAMELESSUNION
#define INSITEM DUMMYUNIONNAME.item
#else
#define INSITEM item
#endif
ins.INSITEM.mask = TVIF_TEXT | TVIF_PARAM;
ins.INSITEM.pszText = text;
ins.INSITEM.cchTextMax = strlen(text)+1;
ins.INSITEM.lParam = (LPARAM)path;
newitem = TreeView_InsertItem(faff->treeview, &ins);
if (level > 0)
TreeView_Expand(faff->treeview, faff->lastat[level - 1],
(level > 1 ? TVE_COLLAPSE : TVE_EXPAND));
faff->lastat[level] = newitem;
for (i = level + 1; i < 4; i++)
faff->lastat[i] = NULL;
return newitem;
}
/*
* Create the panelfuls of controls in the configuration box.
*/
static void create_controls(HWND hwnd, char *path)
{
struct ctlpos cp;
int index;
int base_id;
struct winctrls *wc;
if (!path[0]) {
/*
* Here we must create the basic standard controls.
*/
ctlposinit(&cp, hwnd, 3, 3, 235);
wc = &ctrls_base;
base_id = IDCX_STDBASE;
} else {
/*
* Otherwise, we're creating the controls for a particular
* panel.
*/
ctlposinit(&cp, hwnd, 100, 3, 13);
wc = &ctrls_panel;
base_id = IDCX_PANELBASE;
}
for (index=-1; (index = ctrl_find_path(ctrlbox, path, index)) >= 0 ;) {
struct controlset *s = ctrlbox->ctrlsets[index];
winctrl_layout(&dp, wc, &cp, s, &base_id);
}
}
/*
* This function is the configuration box.
* (Being a dialog procedure, in general it returns 0 if the default
* dialog processing should be performed, and 1 if it should not.)
*/
static INT_PTR CALLBACK GenericMainDlgProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
HWND hw, treeview;
struct treeview_faff tvfaff;
int ret;
switch (msg) {
case WM_INITDIALOG:
dp.hwnd = hwnd;
create_controls(hwnd, ""); /* Open and Cancel buttons etc */
SetWindowText(hwnd, dp.wintitle);
SetWindowLongPtr(hwnd, GWLP_USERDATA, 0);
if (has_help())
SetWindowLongPtr(hwnd, GWL_EXSTYLE,
GetWindowLongPtr(hwnd, GWL_EXSTYLE) |
WS_EX_CONTEXTHELP);
else {
HWND item = GetDlgItem(hwnd, IDC_HELPBTN);
if (item)
DestroyWindow(item);
}
SendMessage(hwnd, WM_SETICON, (WPARAM) ICON_BIG,
(LPARAM) LoadIcon(hinst, MAKEINTRESOURCE(IDI_CFGICON)));
/*
* Centre the window.
*/
{ /* centre the window */
RECT rs, rd;
hw = GetDesktopWindow();
if (GetWindowRect(hw, &rs) && GetWindowRect(hwnd, &rd))
MoveWindow(hwnd,
(rs.right + rs.left + rd.left - rd.right) / 2,
(rs.bottom + rs.top + rd.top - rd.bottom) / 2,
rd.right - rd.left, rd.bottom - rd.top, TRUE);
}
/*
* Create the tree view.
*/
{
RECT r;
WPARAM font;
HWND tvstatic;
r.left = 3;
r.right = r.left + 95;
r.top = 3;
r.bottom = r.top + 10;
MapDialogRect(hwnd, &r);
tvstatic = CreateWindowEx(0, "STATIC", "Cate&gory:",
WS_CHILD | WS_VISIBLE,
r.left, r.top,
r.right - r.left, r.bottom - r.top,
hwnd, (HMENU) IDCX_TVSTATIC, hinst,
NULL);
font = SendMessage(hwnd, WM_GETFONT, 0, 0);
SendMessage(tvstatic, WM_SETFONT, font, MAKELPARAM(TRUE, 0));
r.left = 3;
r.right = r.left + 95;
r.top = 13;
r.bottom = r.top + 219;
MapDialogRect(hwnd, &r);
treeview = CreateWindowEx(WS_EX_CLIENTEDGE, WC_TREEVIEW, "",
WS_CHILD | WS_VISIBLE |
WS_TABSTOP | TVS_HASLINES |
TVS_DISABLEDRAGDROP | TVS_HASBUTTONS
| TVS_LINESATROOT |
TVS_SHOWSELALWAYS, r.left, r.top,
r.right - r.left, r.bottom - r.top,
hwnd, (HMENU) IDCX_TREEVIEW, hinst,
NULL);
font = SendMessage(hwnd, WM_GETFONT, 0, 0);
SendMessage(treeview, WM_SETFONT, font, MAKELPARAM(TRUE, 0));
tvfaff.treeview = treeview;
memset(tvfaff.lastat, 0, sizeof(tvfaff.lastat));
}
/*
* Set up the tree view contents.
*/
{
HTREEITEM hfirst = NULL;
int i;
char *path = NULL;
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
char *firstpath = NULL;
for (i = 0; i < ctrlbox->nctrlsets; i++) {
struct controlset *s = ctrlbox->ctrlsets[i];
HTREEITEM item;
int j;
char *c;
if (!s->pathname[0])
continue;
j = path ? ctrl_path_compare(s->pathname, path) : 0;
if (j == INT_MAX)
continue; /* same path, nothing to add to tree */
/*
* We expect never to find an implicit path
* component. For example, we expect never to see
* A/B/C followed by A/D/E, because that would
* _implicitly_ create A/D. All our path prefixes
* are expected to contain actual controls and be
* selectable in the treeview; so we would expect
* to see A/D _explicitly_ before encountering
* A/D/E.
*/
assert(j == ctrl_path_elements(s->pathname) - 1);
c = strrchr(s->pathname, '/');
if (!c)
c = s->pathname;
else
c++;
item = treeview_insert(&tvfaff, j, c, s->pathname);
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
if (!hfirst) {
hfirst = item;
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
firstpath = s->pathname;
}
path = s->pathname;
}
/*
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
* Put the treeview selection on to the first panel in the
* ctrlbox.
*/
TreeView_SelectItem(treeview, hfirst);
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
/*
* And create the actual control set for that panel, to
* match the initial treeview selection.
*/
assert(firstpath); /* config.c must have given us _something_ */
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
create_controls(hwnd, firstpath);
dlg_refresh(NULL, &dp); /* and set up control values */
}
/*
* Set focus into the first available control.
*/
{
int i;
struct winctrl *c;
for (i = 0; (c = winctrl_findbyindex(&ctrls_panel, i)) != NULL;
i++) {
if (c->ctrl) {
dlg_set_focus(c->ctrl, &dp);
break;
}
}
}
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
/*
* Now we've finished creating our initial set of controls,
* it's safe to actually show the window without risking setup
* flicker.
*/
ShowWindow(hwnd, SW_SHOWNORMAL);
/*
* Set the flag that activates a couple of the other message
* handlers below, which were disabled until now to avoid
* spurious firing during the above setup procedure.
*/
SetWindowLongPtr(hwnd, GWLP_USERDATA, 1);
return 0;
case WM_LBUTTONUP:
/*
* Button release should trigger WM_OK if there was a
* previous double click on the session list.
*/
ReleaseCapture();
if (dp.ended)
SaneEndDialog(hwnd, dp.endresult ? 1 : 0);
break;
case WM_NOTIFY:
if (LOWORD(wParam) == IDCX_TREEVIEW &&
((LPNMHDR) lParam)->code == TVN_SELCHANGED) {
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
/*
* Selection-change events on the treeview cause us to do
* a flurry of control deletion and creation - but only
* after WM_INITDIALOG has finished. The initial
* selection-change event(s) during treeview setup are
* ignored.
*/
HTREEITEM i;
TVITEM item;
char buffer[64];
Fix accidental dependence on Windows API quirk in config box. Our config boxes are constructed using the CreateDialog() API function, rather than the modal DialogBox(). CreateDialog() is not that different from CreateWindow(), so windows created with it don't appear on the screen automatically; MSDN says that they must be shown via ShowWindow(), just like non-dialog windows have to be. But we weren't doing that at any point! So how was our config box ever getting displayed at all? Apparently by sheer chance, it turns out. The handler for a selection change in the tree view, which has to delete a whole panel of controls and creates a different set, surrounds that procedure with some WM_SETREDRAW calls and an InvalidateRect(), to prevent flicker while lots of changes were being made. And the creation of the _first_ panelful of controls, at dialog box setup, was done by simply selecting an item in the treeview and expecting that handler to be recursively called. And it appears that calling WM_SETREDRAW(TRUE) and then InvalidateRect was undocumentedly having an effect equivalent to the ShowWindow() we should have called, so that we never noticed the latter was missing. But a recent Vista update (all reports implicate KB3057839) has caused that not to work any more: on an updated Vista machine, in some desktop configurations, it seems that any attempt to fiddle with WM_SETREDRAW during dialog setup can leave the dialog box in a really unhelpful invisible state - the window is _physically there_ (you can see its taskbar entry, and the mouse pointer changes as you move over where its edit boxes are), but 100% transparent. So now we're doing something a bit more sensible. The first panelful of controls is created directly by the WM_INITDIALOG handler, rather than recursing into code that wasn't really designed to run at setup time. To be on the safe side, that handler for treeview selection change is also disabled until the WM_INITDIALOG handler has finished (like we already did with the WM_COMMAND handler), so that we can be sure of not accidentally messing about with WM_SETREDRAW at all during setup. And at the end of setup, we show the window in the sensible way, by a docs-approved call to ShowWindow(). This appears (on the one machine I've so far tested it on) to fix the Vista invisible-window issue, and also it should be more API-compliant and hence safer in future.
2015-06-18 06:05:19 +00:00
if (GetWindowLongPtr(hwnd, GWLP_USERDATA) != 1)
return 0;
i = TreeView_GetSelection(((LPNMHDR) lParam)->hwndFrom);
SendMessage (hwnd, WM_SETREDRAW, FALSE, 0);
item.hItem = i;
item.pszText = buffer;
item.cchTextMax = sizeof(buffer);
item.mask = TVIF_TEXT | TVIF_PARAM;
TreeView_GetItem(((LPNMHDR) lParam)->hwndFrom, &item);
{
/* Destroy all controls in the currently visible panel. */
int k;
HWND item;
struct winctrl *c;
while ((c = winctrl_findbyindex(&ctrls_panel, 0)) != NULL) {
for (k = 0; k < c->num_ids; k++) {
item = GetDlgItem(hwnd, c->base_id + k);
if (item)
DestroyWindow(item);
}
winctrl_rem_shortcuts(&dp, c);
winctrl_remove(&ctrls_panel, c);
sfree(c->data);
sfree(c);
}
}
create_controls(hwnd, (char *)item.lParam);
dlg_refresh(NULL, &dp); /* set up control values */
SendMessage (hwnd, WM_SETREDRAW, TRUE, 0);
InvalidateRect (hwnd, NULL, TRUE);
SetFocus(((LPNMHDR) lParam)->hwndFrom); /* ensure focus stays */
return 0;
}
break;
case WM_COMMAND:
case WM_DRAWITEM:
default: /* also handle drag list msg here */
/*
* Only process WM_COMMAND once the dialog is fully formed.
*/
if (GetWindowLongPtr(hwnd, GWLP_USERDATA) == 1) {
ret = winctrl_handle_command(&dp, msg, wParam, lParam);
if (dp.ended && GetCapture() != hwnd)
SaneEndDialog(hwnd, dp.endresult ? 1 : 0);
} else
ret = 0;
return ret;
case WM_HELP:
if (!winctrl_context_help(&dp, hwnd,
((LPHELPINFO)lParam)->iCtrlId))
MessageBeep(0);
break;
case WM_CLOSE:
quit_help(hwnd);
SaneEndDialog(hwnd, 0);
return 0;
/* Grrr Explorer will maximize Dialogs! */
case WM_SIZE:
if (wParam == SIZE_MAXIMIZED)
force_normal(hwnd);
return 0;
}
return 0;
}
void modal_about_box(HWND hwnd)
{
EnableWindow(hwnd, 0);
DialogBox(hinst, MAKEINTRESOURCE(IDD_ABOUTBOX), hwnd, AboutProc);
EnableWindow(hwnd, 1);
SetActiveWindow(hwnd);
}
void show_help(HWND hwnd)
{
launch_help(hwnd, NULL);
}
void defuse_showwindow(void)
{
/*
* Work around the fact that the app's first call to ShowWindow
* will ignore the default in favour of the shell-provided
* setting.
*/
{
HWND hwnd;
hwnd = CreateDialog(hinst, MAKEINTRESOURCE(IDD_ABOUTBOX),
NULL, NullDlgProc);
ShowWindow(hwnd, SW_HIDE);
SetActiveWindow(hwnd);
DestroyWindow(hwnd);
}
}
int do_config(void)
{
int ret;
ctrlbox = ctrl_new_box();
setup_config_box(ctrlbox, FALSE, 0, 0);
win_setup_config_box(ctrlbox, &dp.hwnd, has_help(), FALSE, 0);
dp_init(&dp);
winctrl_init(&ctrls_base);
winctrl_init(&ctrls_panel);
dp_add_tree(&dp, &ctrls_base);
dp_add_tree(&dp, &ctrls_panel);
dp.wintitle = dupprintf("%s Configuration", appname);
dp.errtitle = dupprintf("%s Error", appname);
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
dp.data = conf;
dlg_auto_set_fixed_pitch_flag(&dp);
dp.shortcuts['g'] = TRUE; /* the treeview: `Cate&gory' */
ret =
SaneDialogBox(hinst, MAKEINTRESOURCE(IDD_MAINBOX), NULL,
GenericMainDlgProc);
ctrl_free_box(ctrlbox);
winctrl_cleanup(&ctrls_panel);
winctrl_cleanup(&ctrls_base);
dp_cleanup(&dp);
return ret;
}
int do_reconfig(HWND hwnd, int protcfginfo)
{
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 *backup_conf;
int ret, protocol;
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
backup_conf = conf_copy(conf);
ctrlbox = ctrl_new_box();
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
protocol = conf_get_int(conf, CONF_protocol);
setup_config_box(ctrlbox, TRUE, protocol, protcfginfo);
win_setup_config_box(ctrlbox, &dp.hwnd, has_help(), TRUE, protocol);
dp_init(&dp);
winctrl_init(&ctrls_base);
winctrl_init(&ctrls_panel);
dp_add_tree(&dp, &ctrls_base);
dp_add_tree(&dp, &ctrls_panel);
dp.wintitle = dupprintf("%s Reconfiguration", appname);
dp.errtitle = dupprintf("%s Error", appname);
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
dp.data = conf;
dlg_auto_set_fixed_pitch_flag(&dp);
dp.shortcuts['g'] = TRUE; /* the treeview: `Cate&gory' */
ret = SaneDialogBox(hinst, MAKEINTRESOURCE(IDD_MAINBOX), NULL,
GenericMainDlgProc);
ctrl_free_box(ctrlbox);
winctrl_cleanup(&ctrls_base);
winctrl_cleanup(&ctrls_panel);
dp_cleanup(&dp);
if (!ret)
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_copy_into(conf, backup_conf);
conf_free(backup_conf);
return ret;
}
void logevent(void *frontend, const char *string)
{
char timebuf[40];
char **location;
struct tm tm;
log_eventlog(logctx, string);
tm=ltime();
strftime(timebuf, sizeof(timebuf), "%Y-%m-%d %H:%M:%S\t", &tm);
if (ninitial < LOGEVENT_INITIAL_MAX)
location = &events_initial[ninitial];
else
location = &events_circular[(circular_first + ncircular) % LOGEVENT_CIRCULAR_MAX];
if (*location)
sfree(*location);
*location = dupcat(timebuf, string, (const char *)NULL);
if (logbox) {
int count;
SendDlgItemMessage(logbox, IDN_LIST, LB_ADDSTRING,
0, (LPARAM) *location);
count = SendDlgItemMessage(logbox, IDN_LIST, LB_GETCOUNT, 0, 0);
SendDlgItemMessage(logbox, IDN_LIST, LB_SETTOPINDEX, count - 1, 0);
}
if (ninitial < LOGEVENT_INITIAL_MAX) {
ninitial++;
} else if (ncircular < LOGEVENT_CIRCULAR_MAX) {
ncircular++;
} else if (ncircular == LOGEVENT_CIRCULAR_MAX) {
circular_first = (circular_first + 1) % LOGEVENT_CIRCULAR_MAX;
sfree(events_circular[circular_first]);
events_circular[circular_first] = dupstr("..");
}
}
void showeventlog(HWND hwnd)
{
if (!logbox) {
logbox = CreateDialog(hinst, MAKEINTRESOURCE(IDD_LOGBOX),
hwnd, LogProc);
ShowWindow(logbox, SW_SHOWNORMAL);
}
SetActiveWindow(logbox);
}
void showabout(HWND hwnd)
{
DialogBox(hinst, MAKEINTRESOURCE(IDD_ABOUTBOX), hwnd, AboutProc);
}
int verify_ssh_host_key(void *frontend, char *host, int port,
const char *keytype, char *keystr, char *fingerprint,
void (*callback)(void *ctx, int result), void *ctx)
{
int ret;
static const char absentmsg[] =
"The server's host key is not cached in the registry. You\n"
"have no guarantee that the server is the computer you\n"
"think it is.\n"
"The server's %s key fingerprint is:\n"
"%s\n"
"If you trust this host, hit Yes to add the key to\n"
"%s's cache and carry on connecting.\n"
"If you want to carry on connecting just once, without\n"
"adding the key to the cache, hit No.\n"
"If you do not trust this host, hit Cancel to abandon the\n"
"connection.\n";
static const char wrongmsg[] =
"WARNING - POTENTIAL SECURITY BREACH!\n"
"\n"
"The server's host key does not match the one %s has\n"
"cached in the registry. This means that either the\n"
"server administrator has changed the host key, or you\n"
"have actually connected to another computer pretending\n"
"to be the server.\n"
"The new %s key fingerprint is:\n"
"%s\n"
"If you were expecting this change and trust the new key,\n"
"hit Yes to update %s's cache and continue connecting.\n"
"If you want to carry on connecting but without updating\n"
"the cache, hit No.\n"
"If you want to abandon the connection completely, hit\n"
"Cancel. Hitting Cancel is the ONLY guaranteed safe\n" "choice.\n";
static const char mbtitle[] = "%s Security Alert";
/*
* Verify the key against the registry.
*/
ret = verify_host_key(host, port, keytype, keystr);
if (ret == 0) /* success - key matched OK */
return 1;
else if (ret == 2) { /* key was different */
int mbret;
char *text = dupprintf(wrongmsg, appname, keytype, fingerprint,
appname);
char *caption = dupprintf(mbtitle, appname);
mbret = message_box(text, caption,
MB_ICONWARNING | MB_YESNOCANCEL | MB_DEFBUTTON3,
HELPCTXID(errors_hostkey_changed));
assert(mbret==IDYES || mbret==IDNO || mbret==IDCANCEL);
sfree(text);
sfree(caption);
if (mbret == IDYES) {
store_host_key(host, port, keytype, keystr);
return 1;
} else if (mbret == IDNO)
return 1;
} else if (ret == 1) { /* key was absent */
int mbret;
char *text = dupprintf(absentmsg, keytype, fingerprint, appname);
char *caption = dupprintf(mbtitle, appname);
mbret = message_box(text, caption,
MB_ICONWARNING | MB_YESNOCANCEL | MB_DEFBUTTON3,
HELPCTXID(errors_hostkey_absent));
assert(mbret==IDYES || mbret==IDNO || mbret==IDCANCEL);
sfree(text);
sfree(caption);
if (mbret == IDYES) {
store_host_key(host, port, keytype, keystr);
return 1;
} else if (mbret == IDNO)
return 1;
}
return 0; /* abandon the connection */
}
/*
* Ask whether the selected algorithm is acceptable (since it was
* below the configured 'warn' threshold).
*/
int askalg(void *frontend, const char *algtype, const char *algname,
void (*callback)(void *ctx, int result), void *ctx)
{
static const char mbtitle[] = "%s Security Alert";
static const char msg[] =
"The first %s supported by the server\n"
"is %.64s, which is below the configured\n"
"warning threshold.\n"
"Do you want to continue with this connection?\n";
char *message, *title;
int mbret;
message = dupprintf(msg, algtype, algname);
title = dupprintf(mbtitle, appname);
mbret = MessageBox(NULL, message, title,
MB_ICONWARNING | MB_YESNO | MB_DEFBUTTON2);
socket_reselect_all();
sfree(message);
sfree(title);
if (mbret == IDYES)
return 1;
else
return 0;
}
int askhk(void *frontend, const char *algname, const char *betteralgs,
void (*callback)(void *ctx, int result), void *ctx)
{
static const char mbtitle[] = "%s Security Alert";
static const char msg[] =
"The first host key type we have stored for this server\n"
"is %s, which is below the configured warning threshold.\n"
"The server also provides the following types of host key\n"
"above the threshold, which we do not have stored:\n"
"%s\n"
"Do you want to continue with this connection?\n";
char *message, *title;
int mbret;
message = dupprintf(msg, algname, betteralgs);
title = dupprintf(mbtitle, appname);
mbret = MessageBox(NULL, message, title,
MB_ICONWARNING | MB_YESNO | MB_DEFBUTTON2);
socket_reselect_all();
sfree(message);
sfree(title);
if (mbret == IDYES)
return 1;
else
return 0;
}
/*
* Ask whether to wipe a session log file before writing to it.
* Returns 2 for wipe, 1 for append, 0 for cancel (don't log).
*/
int askappend(void *frontend, Filename *filename,
void (*callback)(void *ctx, int result), void *ctx)
{
static const char msgtemplate[] =
"The session log file \"%.*s\" already exists.\n"
"You can overwrite it with a new session log,\n"
"append your session log to the end of it,\n"
"or disable session logging for this session.\n"
"Hit Yes to wipe the file, No to append to it,\n"
"or Cancel to disable logging.";
char *message;
char *mbtitle;
int mbret;
message = dupprintf(msgtemplate, FILENAME_MAX, filename->path);
mbtitle = dupprintf("%s Log to File", appname);
mbret = MessageBox(NULL, message, mbtitle,
MB_ICONQUESTION | MB_YESNOCANCEL | MB_DEFBUTTON3);
socket_reselect_all();
sfree(message);
sfree(mbtitle);
if (mbret == IDYES)
return 2;
else if (mbret == IDNO)
return 1;
else
return 0;
}
/*
* Warn about the obsolescent key file format.
*
* Uniquely among these functions, this one does _not_ expect a
* frontend handle. This means that if PuTTY is ported to a
* platform which requires frontend handles, this function will be
* an anomaly. Fortunately, the problem it addresses will not have
* been present on that platform, so it can plausibly be
* implemented as an empty function.
*/
void old_keyfile_warning(void)
{
static const char mbtitle[] = "%s Key File Warning";
static const char message[] =
"You are loading an SSH-2 private key which has an\n"
"old version of the file format. This means your key\n"
"file is not fully tamperproof. Future versions of\n"
"%s may stop supporting this private key format,\n"
"so we recommend you convert your key to the new\n"
"format.\n"
"\n"
"You can perform this conversion by loading the key\n"
"into PuTTYgen and then saving it again.";
char *msg, *title;
msg = dupprintf(message, appname);
title = dupprintf(mbtitle, appname);
MessageBox(NULL, msg, title, MB_OK);
socket_reselect_all();
sfree(msg);
sfree(title);
}