2003-01-10 18:33:35 +00:00
|
|
|
/*
|
2004-04-27 12:31:57 +00:00
|
|
|
* winmisc.c: miscellaneous Windows-specific things
|
2003-01-10 18:33:35 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
2018-06-03 14:05:44 +00:00
|
|
|
#include <limits.h>
|
2003-01-10 18:33:35 +00:00
|
|
|
#include "putty.h"
|
2015-08-11 09:25:40 +00:00
|
|
|
#ifndef SECURITY_WIN32
|
2014-11-01 14:44:16 +00:00
|
|
|
#define SECURITY_WIN32
|
2015-08-11 09:25:40 +00:00
|
|
|
#endif
|
2010-03-24 20:12:25 +00:00
|
|
|
#include <security.h>
|
2003-01-10 18:33:35 +00:00
|
|
|
|
2018-06-03 14:05:44 +00:00
|
|
|
DWORD osMajorVersion, osMinorVersion, osPlatformId;
|
2003-08-21 19:48:45 +00:00
|
|
|
|
2004-10-06 22:31:07 +00:00
|
|
|
char *platform_get_x_display(void) {
|
|
|
|
|
/* We may as well check for DISPLAY in case it's useful. */
|
|
|
|
|
return dupstr(getenv("DISPLAY"));
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-02 11:01:57 +00:00
|
|
|
Filename *filename_from_str(const char *str)
|
2003-02-01 12:54:40 +00:00
|
|
|
{
|
2011-10-02 11:01:57 +00:00
|
|
|
Filename *ret = snew(Filename);
|
|
|
|
|
ret->path = dupstr(str);
|
2003-02-01 12:54:40 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-02 11:01:57 +00:00
|
|
|
Filename *filename_copy(const Filename *fn)
|
|
|
|
|
{
|
|
|
|
|
return filename_from_str(fn->path);
|
|
|
|
|
}
|
|
|
|
|
|
2003-02-01 17:24:27 +00:00
|
|
|
const char *filename_to_str(const Filename *fn)
|
2003-02-01 12:54:40 +00:00
|
|
|
{
|
2003-02-01 17:24:27 +00:00
|
|
|
return fn->path;
|
2003-02-01 12:54:40 +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
|
|
|
bool filename_equal(const Filename *f1, const Filename *f2)
|
2011-10-02 11:01:57 +00:00
|
|
|
{
|
|
|
|
|
return !strcmp(f1->path, f2->path);
|
|
|
|
|
}
|
|
|
|
|
|
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 filename_is_null(const Filename *fn)
|
2003-02-01 12:54:40 +00:00
|
|
|
{
|
2011-10-02 11:01:57 +00:00
|
|
|
return !*fn->path;
|
2003-02-01 12:54:40 +00:00
|
|
|
}
|
|
|
|
|
|
2011-10-02 11:01:57 +00:00
|
|
|
void filename_free(Filename *fn)
|
|
|
|
|
{
|
|
|
|
|
sfree(fn->path);
|
|
|
|
|
sfree(fn);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-24 09:48:20 +00:00
|
|
|
void filename_serialise(BinarySink *bs, const Filename *f)
|
2011-10-02 11:01:57 +00:00
|
|
|
{
|
2018-05-24 09:48:20 +00:00
|
|
|
put_asciz(bs, f->path);
|
2011-10-02 11:01:57 +00:00
|
|
|
}
|
2018-05-28 14:36:15 +00:00
|
|
|
Filename *filename_deserialise(BinarySource *src)
|
2003-02-01 12:54:40 +00:00
|
|
|
{
|
2018-05-28 14:36:15 +00:00
|
|
|
return filename_from_str(get_asciz(src));
|
2003-02-01 12:54:40 +00:00
|
|
|
}
|
2003-03-06 13:24:02 +00:00
|
|
|
|
2015-09-25 08:23:26 +00:00
|
|
|
char filename_char_sanitise(char c)
|
|
|
|
|
{
|
|
|
|
|
if (strchr("<>:\"/\\|?*", c))
|
|
|
|
|
return '.';
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
2003-08-25 13:53:41 +00:00
|
|
|
char *get_username(void)
|
|
|
|
|
{
|
|
|
|
|
DWORD namelen;
|
|
|
|
|
char *user;
|
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 got_username = false;
|
2010-03-24 20:12:25 +00:00
|
|
|
DECL_WINDOWS_FUNCTION(static, BOOLEAN, GetUserNameExA,
|
2019-09-08 19:29:00 +00:00
|
|
|
(EXTENDED_NAME_FORMAT, LPSTR, PULONG));
|
2003-08-25 13:53:41 +00:00
|
|
|
|
2010-03-24 20:12:25 +00:00
|
|
|
{
|
2019-09-08 19:29:00 +00:00
|
|
|
static bool tried_usernameex = false;
|
|
|
|
|
if (!tried_usernameex) {
|
|
|
|
|
/* Not available on Win9x, so load dynamically */
|
|
|
|
|
HMODULE secur32 = load_system32_dll("secur32.dll");
|
|
|
|
|
/* If MIT Kerberos is installed, the following call to
|
|
|
|
|
GET_WINDOWS_FUNCTION makes Windows implicitly load
|
|
|
|
|
sspicli.dll WITHOUT proper path sanitizing, so better
|
|
|
|
|
load it properly before */
|
|
|
|
|
HMODULE sspicli = load_system32_dll("sspicli.dll");
|
2017-12-10 09:19:15 +00:00
|
|
|
(void)sspicli; /* squash compiler warning about unused variable */
|
2019-09-08 19:29:00 +00:00
|
|
|
GET_WINDOWS_FUNCTION(secur32, GetUserNameExA);
|
|
|
|
|
tried_usernameex = true;
|
|
|
|
|
}
|
2010-03-24 20:12:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p_GetUserNameExA) {
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
|
* If available, use the principal -- this avoids the problem
|
|
|
|
|
* that the local username is case-insensitive but Kerberos
|
|
|
|
|
* usernames are case-sensitive.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Get the length */
|
|
|
|
|
namelen = 0;
|
|
|
|
|
(void) p_GetUserNameExA(NameUserPrincipal, NULL, &namelen);
|
|
|
|
|
|
|
|
|
|
user = snewn(namelen, char);
|
|
|
|
|
got_username = p_GetUserNameExA(NameUserPrincipal, user, &namelen);
|
|
|
|
|
if (got_username) {
|
|
|
|
|
char *p = strchr(user, '@');
|
|
|
|
|
if (p) *p = 0;
|
|
|
|
|
} else {
|
|
|
|
|
sfree(user);
|
|
|
|
|
}
|
2004-12-30 16:45:11 +00:00
|
|
|
}
|
2003-08-25 13:53:41 +00:00
|
|
|
|
2010-03-24 20:12:25 +00:00
|
|
|
if (!got_username) {
|
2019-09-08 19:29:00 +00:00
|
|
|
/* Fall back to local user name */
|
|
|
|
|
namelen = 0;
|
|
|
|
|
if (!GetUserName(NULL, &namelen)) {
|
|
|
|
|
/*
|
|
|
|
|
* Apparently this doesn't work at least on Windows XP SP2.
|
|
|
|
|
* Thus assume a maximum of 256. It will fail again if it
|
|
|
|
|
* doesn't fit.
|
|
|
|
|
*/
|
|
|
|
|
namelen = 256;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
user = snewn(namelen, char);
|
|
|
|
|
got_username = GetUserName(user, &namelen);
|
|
|
|
|
if (!got_username) {
|
|
|
|
|
sfree(user);
|
|
|
|
|
}
|
2010-03-24 20:12:25 +00:00
|
|
|
}
|
2003-08-25 13:53:41 +00:00
|
|
|
|
2010-03-24 20:12:25 +00:00
|
|
|
return got_username ? user : NULL;
|
2003-08-25 13:53:41 +00:00
|
|
|
}
|
|
|
|
|
|
2016-07-18 19:02:32 +00:00
|
|
|
void dll_hijacking_protection(void)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* If the OS provides it, call SetDefaultDllDirectories() to
|
|
|
|
|
* prevent DLLs from being loaded from the directory containing
|
|
|
|
|
* our own binary, and instead only load from system32.
|
|
|
|
|
*
|
|
|
|
|
* This is a protection against hijacking attacks, if someone runs
|
|
|
|
|
* PuTTY directly from their web browser's download directory
|
|
|
|
|
* having previously been enticed into clicking on an unwise link
|
|
|
|
|
* that downloaded a malicious DLL to the same directory under one
|
|
|
|
|
* of various magic names that seem to be things that standard
|
|
|
|
|
* Windows DLLs delegate to.
|
|
|
|
|
*
|
|
|
|
|
* It shouldn't break deliberate loading of user-provided DLLs
|
|
|
|
|
* such as GSSAPI providers, because those are specified by their
|
|
|
|
|
* full pathname by the user-provided configuration.
|
|
|
|
|
*/
|
|
|
|
|
static HMODULE kernel32_module;
|
|
|
|
|
DECL_WINDOWS_FUNCTION(static, BOOL, SetDefaultDllDirectories, (DWORD));
|
|
|
|
|
|
|
|
|
|
if (!kernel32_module) {
|
|
|
|
|
kernel32_module = load_system32_dll("kernel32.dll");
|
2017-06-20 18:02:48 +00:00
|
|
|
#if (defined _MSC_VER && _MSC_VER < 1900) || defined COVERITY
|
|
|
|
|
/* For older Visual Studio, and also for the system I
|
|
|
|
|
* currently use for Coveritying the Windows code, this
|
|
|
|
|
* function isn't available in the header files to
|
|
|
|
|
* type-check */
|
Add automatic type-checking to GET_WINDOWS_FUNCTION.
This gives me an extra safety-check against having mistyped one of the
function prototypes that we load at run time from DLLs: we verify that
the typedef we defined based on the prototype in our source code
matches the type of the real function as declared in the Windows
headers.
This was an idea I had while adding a pile of further functions using
this mechanism. It didn't catch any errors (either in the new
functions or in the existing collection), but that's no reason not to
keep it anyway now that I've thought of it!
In VS2015, this automated type-check works for most functions, but a
couple manage to break it. SetCurrentProcessExplicitAppUserModelID in
winjump.c can't be type-checked, because including <shobjidl.h> where
that function is declared would also bring in a load of other stuff
that conflicts with the painful manual COM declarations in winjump.c.
(That stuff could probably be removed now we're on an up-to-date
Visual Studio, on the other hand, but that's a separate chore.) And
gai_strerror, used in winnet.c, does _have_ an implementation in a
DLL, but the header files like to provide an inline version with a
different calling convention, which defeats this error-checking trick.
And in the older VS2003 that we still precautionarily build with,
several more type-checks have to be #ifdeffed out because the
functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
|
|
|
GET_WINDOWS_FUNCTION_NO_TYPECHECK(
|
|
|
|
|
kernel32_module, SetDefaultDllDirectories);
|
|
|
|
|
#else
|
2016-07-18 19:02:32 +00:00
|
|
|
GET_WINDOWS_FUNCTION(kernel32_module, SetDefaultDllDirectories);
|
Add automatic type-checking to GET_WINDOWS_FUNCTION.
This gives me an extra safety-check against having mistyped one of the
function prototypes that we load at run time from DLLs: we verify that
the typedef we defined based on the prototype in our source code
matches the type of the real function as declared in the Windows
headers.
This was an idea I had while adding a pile of further functions using
this mechanism. It didn't catch any errors (either in the new
functions or in the existing collection), but that's no reason not to
keep it anyway now that I've thought of it!
In VS2015, this automated type-check works for most functions, but a
couple manage to break it. SetCurrentProcessExplicitAppUserModelID in
winjump.c can't be type-checked, because including <shobjidl.h> where
that function is declared would also bring in a load of other stuff
that conflicts with the painful manual COM declarations in winjump.c.
(That stuff could probably be removed now we're on an up-to-date
Visual Studio, on the other hand, but that's a separate chore.) And
gai_strerror, used in winnet.c, does _have_ an implementation in a
DLL, but the header files like to provide an inline version with a
different calling convention, which defeats this error-checking trick.
And in the older VS2003 that we still precautionarily build with,
several more type-checks have to be #ifdeffed out because the
functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
|
|
|
#endif
|
2016-07-18 19:02:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p_SetDefaultDllDirectories) {
|
2017-04-03 19:30:18 +00:00
|
|
|
/* LOAD_LIBRARY_SEARCH_SYSTEM32 and explicitly specified
|
|
|
|
|
* directories only */
|
|
|
|
|
p_SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 |
|
|
|
|
|
LOAD_LIBRARY_SEARCH_USER_DIRS);
|
2016-07-18 19:02:32 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-03 14:05:44 +00:00
|
|
|
void init_winver(void)
|
2003-08-21 19:48:45 +00:00
|
|
|
{
|
2018-06-03 14:05:44 +00:00
|
|
|
OSVERSIONINFO osVersion;
|
|
|
|
|
static HMODULE kernel32_module;
|
|
|
|
|
DECL_WINDOWS_FUNCTION(static, BOOL, GetVersionExA, (LPOSVERSIONINFO));
|
|
|
|
|
|
|
|
|
|
if (!kernel32_module) {
|
|
|
|
|
kernel32_module = load_system32_dll("kernel32.dll");
|
|
|
|
|
/* Deliberately don't type-check this function, because that
|
|
|
|
|
* would involve using its declaration in a header file which
|
|
|
|
|
* triggers a deprecation warning. I know it's deprecated (see
|
|
|
|
|
* below) and don't need telling. */
|
|
|
|
|
GET_WINDOWS_FUNCTION_NO_TYPECHECK(kernel32_module, GetVersionExA);
|
|
|
|
|
}
|
|
|
|
|
|
2003-08-21 19:48:45 +00:00
|
|
|
ZeroMemory(&osVersion, sizeof(osVersion));
|
|
|
|
|
osVersion.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
|
2018-06-03 14:05:44 +00:00
|
|
|
if (p_GetVersionExA && p_GetVersionExA(&osVersion)) {
|
|
|
|
|
osMajorVersion = osVersion.dwMajorVersion;
|
|
|
|
|
osMinorVersion = osVersion.dwMinorVersion;
|
|
|
|
|
osPlatformId = osVersion.dwPlatformId;
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* GetVersionEx is deprecated, so allow for it perhaps going
|
|
|
|
|
* away in future API versions. If it's not there, simply
|
|
|
|
|
* assume that's because Windows is too _new_, so fill in the
|
|
|
|
|
* variables we care about to a value that will always compare
|
|
|
|
|
* higher than any given test threshold.
|
|
|
|
|
*
|
|
|
|
|
* Normally we should be checking against the presence of a
|
|
|
|
|
* specific function if possible in any case.
|
|
|
|
|
*/
|
|
|
|
|
osMajorVersion = osMinorVersion = UINT_MAX; /* a very high number */
|
|
|
|
|
osPlatformId = VER_PLATFORM_WIN32_NT; /* not Win32s or Win95-like */
|
|
|
|
|
}
|
2003-08-21 19:48:45 +00:00
|
|
|
}
|
|
|
|
|
|
2010-09-13 08:29:45 +00:00
|
|
|
HMODULE load_system32_dll(const char *libname)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Wrapper function to load a DLL out of c:\windows\system32
|
|
|
|
|
* without going through the full DLL search path. (Hence no
|
|
|
|
|
* attack is possible by placing a substitute DLL earlier on that
|
|
|
|
|
* path.)
|
|
|
|
|
*/
|
|
|
|
|
static char *sysdir = 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 sysdirsize = 0;
|
2010-09-13 08:29:45 +00:00
|
|
|
char *fullpath;
|
|
|
|
|
HMODULE ret;
|
|
|
|
|
|
|
|
|
|
if (!sysdir) {
|
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
|
|
|
size_t len;
|
|
|
|
|
while ((len = GetSystemDirectory(sysdir, sysdirsize)) >= sysdirsize)
|
|
|
|
|
sgrowarray(sysdir, sysdirsize, len);
|
2010-09-13 08:29:45 +00:00
|
|
|
}
|
|
|
|
|
|
Make dupcat() into a variadic macro.
Up until now, it's been a variadic _function_, whose argument list
consists of 'const char *' ASCIZ strings to concatenate, terminated by
one containing a null pointer. Now, that function is dupcat_fn(), and
it's wrapped by a C99 variadic _macro_ called dupcat(), which
automatically suffixes the null-pointer terminating argument.
This has three benefits. Firstly, it's just less effort at every call
site. Secondly, it protects against the risk of accidentally leaving
off the NULL, causing arbitrary words of stack memory to be
dereferenced as char pointers. And thirdly, it protects against the
more subtle risk of writing a bare 'NULL' as the terminating argument,
instead of casting it explicitly to a pointer. That last one is
necessary because C permits the macro NULL to expand to an integer
constant such as 0, so NULL by itself may not have pointer type, and
worse, it may not be marshalled in a variadic argument list in the
same way as a pointer. (For example, on a 64-bit machine it might only
occupy 32 bits. And yet, on another 64-bit platform, it might work
just fine, so that you don't notice the mistake!)
I was inspired to do this by happening to notice one of those bare
NULL terminators, and thinking I'd better check if there were any
more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
|
|
|
fullpath = dupcat(sysdir, "\\", libname);
|
2010-09-13 08:29:45 +00:00
|
|
|
ret = LoadLibrary(fullpath);
|
|
|
|
|
sfree(fullpath);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-22 07:11:39 +00:00
|
|
|
/*
|
|
|
|
|
* A tree234 containing mappings from system error codes to strings.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
struct errstring {
|
|
|
|
|
int error;
|
|
|
|
|
char *text;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int errstring_find(void *av, void *bv)
|
|
|
|
|
{
|
|
|
|
|
int *a = (int *)av;
|
|
|
|
|
struct errstring *b = (struct errstring *)bv;
|
|
|
|
|
if (*a < b->error)
|
|
|
|
|
return -1;
|
|
|
|
|
if (*a > b->error)
|
|
|
|
|
return +1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
static int errstring_compare(void *av, void *bv)
|
|
|
|
|
{
|
|
|
|
|
struct errstring *a = (struct errstring *)av;
|
|
|
|
|
return errstring_find(&a->error, bv);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static tree234 *errstrings = NULL;
|
|
|
|
|
|
|
|
|
|
const char *win_strerror(int error)
|
|
|
|
|
{
|
|
|
|
|
struct errstring *es;
|
|
|
|
|
|
|
|
|
|
if (!errstrings)
|
|
|
|
|
errstrings = newtree234(errstring_compare);
|
|
|
|
|
|
|
|
|
|
es = find234(errstrings, &error, errstring_find);
|
|
|
|
|
|
|
|
|
|
if (!es) {
|
2013-11-22 19:41:43 +00:00
|
|
|
char msgtext[65536]; /* maximum size for FormatMessage is 64K */
|
2013-07-22 07:11:39 +00:00
|
|
|
|
|
|
|
|
es = snew(struct errstring);
|
|
|
|
|
es->error = error;
|
|
|
|
|
if (!FormatMessage((FORMAT_MESSAGE_FROM_SYSTEM |
|
|
|
|
|
FORMAT_MESSAGE_IGNORE_INSERTS), NULL, error,
|
|
|
|
|
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
|
2013-11-22 19:41:43 +00:00
|
|
|
msgtext, lenof(msgtext)-1, NULL)) {
|
|
|
|
|
sprintf(msgtext,
|
2015-08-11 12:13:20 +00:00
|
|
|
"(unable to format: FormatMessage returned %u)",
|
|
|
|
|
(unsigned int)GetLastError());
|
2013-07-22 07:11:39 +00:00
|
|
|
} else {
|
2013-11-22 19:41:43 +00:00
|
|
|
int len = strlen(msgtext);
|
|
|
|
|
if (len > 0 && msgtext[len-1] == '\n')
|
|
|
|
|
msgtext[len-1] = '\0';
|
2013-07-22 07:11:39 +00:00
|
|
|
}
|
2013-11-22 19:41:43 +00:00
|
|
|
es->text = dupprintf("Error %d: %s", error, msgtext);
|
2013-07-22 07:11:39 +00:00
|
|
|
add234(errstrings, es);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return es->text;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
FontSpec *fontspec_new(const char *name, bool bold, int height, int charset)
|
2011-10-01 17:38:59 +00:00
|
|
|
{
|
|
|
|
|
FontSpec *f = snew(FontSpec);
|
|
|
|
|
f->name = dupstr(name);
|
|
|
|
|
f->isbold = bold;
|
|
|
|
|
f->height = height;
|
|
|
|
|
f->charset = charset;
|
|
|
|
|
return f;
|
|
|
|
|
}
|
|
|
|
|
FontSpec *fontspec_copy(const FontSpec *f)
|
|
|
|
|
{
|
|
|
|
|
return fontspec_new(f->name, f->isbold, f->height, f->charset);
|
|
|
|
|
}
|
|
|
|
|
void fontspec_free(FontSpec *f)
|
|
|
|
|
{
|
|
|
|
|
sfree(f->name);
|
|
|
|
|
sfree(f);
|
|
|
|
|
}
|
2018-05-24 09:48:20 +00:00
|
|
|
void fontspec_serialise(BinarySink *bs, FontSpec *f)
|
2011-10-01 17:38:59 +00:00
|
|
|
{
|
2018-05-24 09:48:20 +00:00
|
|
|
put_asciz(bs, f->name);
|
|
|
|
|
put_uint32(bs, f->isbold);
|
|
|
|
|
put_uint32(bs, f->height);
|
|
|
|
|
put_uint32(bs, f->charset);
|
2011-10-01 17:38:59 +00:00
|
|
|
}
|
2018-05-28 14:36:15 +00:00
|
|
|
FontSpec *fontspec_deserialise(BinarySource *src)
|
|
|
|
|
{
|
|
|
|
|
const char *name = get_asciz(src);
|
|
|
|
|
unsigned isbold = get_uint32(src);
|
|
|
|
|
unsigned height = get_uint32(src);
|
|
|
|
|
unsigned charset = get_uint32(src);
|
|
|
|
|
return fontspec_new(name, isbold, height, charset);
|
2011-10-01 17:38:59 +00:00
|
|
|
}
|
2018-02-07 07:22:18 +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
|
|
|
bool open_for_write_would_lose_data(const Filename *fn)
|
2018-02-07 07:22:18 +00:00
|
|
|
{
|
2018-02-07 20:05:32 +00:00
|
|
|
WIN32_FILE_ATTRIBUTE_DATA attrs;
|
|
|
|
|
if (!GetFileAttributesEx(fn->path, GetFileExInfoStandard, &attrs)) {
|
|
|
|
|
/*
|
|
|
|
|
* Generally, if we don't identify a specific reason why we
|
|
|
|
|
* should return true from this function, we return false, and
|
|
|
|
|
* let the subsequent attempt to open the file for real give a
|
|
|
|
|
* more useful error message.
|
|
|
|
|
*/
|
2018-10-29 19:50:29 +00:00
|
|
|
return false;
|
2018-02-07 07:22:18 +00:00
|
|
|
}
|
2018-02-07 20:05:32 +00:00
|
|
|
if (attrs.dwFileAttributes & (FILE_ATTRIBUTE_DEVICE |
|
|
|
|
|
FILE_ATTRIBUTE_DIRECTORY)) {
|
|
|
|
|
/*
|
|
|
|
|
* File is something other than an ordinary disk file, so
|
|
|
|
|
* opening it for writing will not cause truncation. (It may
|
|
|
|
|
* not _succeed_ either, but that's not our problem here!)
|
|
|
|
|
*/
|
2018-10-29 19:50:29 +00:00
|
|
|
return false;
|
2018-02-07 20:05:32 +00:00
|
|
|
}
|
|
|
|
|
if (attrs.nFileSizeHigh == 0 && attrs.nFileSizeLow == 0) {
|
|
|
|
|
/*
|
|
|
|
|
* File is zero-length (or may be a named pipe, which
|
|
|
|
|
* dwFileAttributes can't tell apart from a regular file), so
|
|
|
|
|
* opening it for writing won't truncate any data away because
|
|
|
|
|
* there's nothing to truncate anyway.
|
|
|
|
|
*/
|
2018-10-29 19:50:29 +00:00
|
|
|
return false;
|
2018-02-07 20:05:32 +00:00
|
|
|
}
|
2018-10-29 19:50:29 +00:00
|
|
|
return true;
|
2018-02-07 07:22:18 +00:00
|
|
|
}
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
|
|
|
|
|
void escape_registry_key(const char *in, strbuf *out)
|
|
|
|
|
{
|
|
|
|
|
bool candot = false;
|
|
|
|
|
static const char hex[16] = "0123456789ABCDEF";
|
|
|
|
|
|
|
|
|
|
while (*in) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (*in == ' ' || *in == '\\' || *in == '*' || *in == '?' ||
|
|
|
|
|
*in == '%' || *in < ' ' || *in > '~' || (*in == '.'
|
|
|
|
|
&& !candot)) {
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
put_byte(out, '%');
|
2019-09-08 19:29:00 +00:00
|
|
|
put_byte(out, hex[((unsigned char) *in) >> 4]);
|
|
|
|
|
put_byte(out, hex[((unsigned char) *in) & 15]);
|
|
|
|
|
} else
|
|
|
|
|
put_byte(out, *in);
|
|
|
|
|
in++;
|
|
|
|
|
candot = true;
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void unescape_registry_key(const char *in, strbuf *out)
|
|
|
|
|
{
|
|
|
|
|
while (*in) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (*in == '%' && in[1] && in[2]) {
|
|
|
|
|
int i, j;
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
i = in[1] - '0';
|
|
|
|
|
i -= (i > 9 ? 7 : 0);
|
|
|
|
|
j = in[2] - '0';
|
|
|
|
|
j -= (j > 9 ? 7 : 0);
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
put_byte(out, (i << 4) + j);
|
|
|
|
|
in += 3;
|
|
|
|
|
} else {
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
put_byte(out, *in++);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-01-23 23:29:57 +00:00
|
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
|
static FILE *debug_fp = NULL;
|
|
|
|
|
static HANDLE debug_hdl = INVALID_HANDLE_VALUE;
|
|
|
|
|
static int debug_got_console = 0;
|
|
|
|
|
|
|
|
|
|
void dputs(const char *buf)
|
|
|
|
|
{
|
|
|
|
|
DWORD dw;
|
|
|
|
|
|
|
|
|
|
if (!debug_got_console) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (AllocConsole()) {
|
|
|
|
|
debug_got_console = 1;
|
|
|
|
|
debug_hdl = GetStdHandle(STD_OUTPUT_HANDLE);
|
|
|
|
|
}
|
2019-01-23 23:29:57 +00:00
|
|
|
}
|
|
|
|
|
if (!debug_fp) {
|
2019-09-08 19:29:00 +00:00
|
|
|
debug_fp = fopen("debug.log", "w");
|
2019-01-23 23:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (debug_hdl != INVALID_HANDLE_VALUE) {
|
2019-09-08 19:29:00 +00:00
|
|
|
WriteFile(debug_hdl, buf, strlen(buf), &dw, NULL);
|
2019-01-23 23:29:57 +00:00
|
|
|
}
|
|
|
|
|
fputs(buf, debug_fp);
|
|
|
|
|
fflush(debug_fp);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2019-01-26 20:26:09 +00:00
|
|
|
|
|
|
|
|
char *registry_get_string(HKEY root, const char *path, const char *leaf)
|
|
|
|
|
{
|
|
|
|
|
HKEY key = root;
|
|
|
|
|
bool need_close_key = false;
|
|
|
|
|
char *toret = NULL, *str = NULL;
|
|
|
|
|
|
|
|
|
|
if (path) {
|
|
|
|
|
if (RegCreateKey(key, path, &key) != ERROR_SUCCESS)
|
|
|
|
|
goto out;
|
|
|
|
|
need_close_key = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DWORD type, size;
|
|
|
|
|
if (RegQueryValueEx(key, leaf, 0, &type, NULL, &size) != ERROR_SUCCESS)
|
|
|
|
|
goto out;
|
|
|
|
|
if (type != REG_SZ)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
str = snewn(size + 1, char);
|
|
|
|
|
DWORD size_got = size;
|
|
|
|
|
if (RegQueryValueEx(key, leaf, 0, &type, (LPBYTE)str,
|
|
|
|
|
&size_got) != ERROR_SUCCESS)
|
|
|
|
|
goto out;
|
|
|
|
|
if (type != REG_SZ || size_got > size)
|
|
|
|
|
goto out;
|
|
|
|
|
str[size_got] = '\0';
|
|
|
|
|
|
|
|
|
|
toret = str;
|
|
|
|
|
str = NULL;
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
if (need_close_key)
|
|
|
|
|
RegCloseKey(key);
|
|
|
|
|
sfree(str);
|
|
|
|
|
return toret;
|
|
|
|
|
}
|