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 15:05:44 +01:00
|
|
|
#include <limits.h>
|
2003-01-10 18:33:35 +00:00
|
|
|
#include "putty.h"
|
2015-08-11 11:25:40 +02:00
|
|
|
#ifndef SECURITY_WIN32
|
2014-11-01 14:44:16 +00:00
|
|
|
#define SECURITY_WIN32
|
2015-08-11 11:25:40 +02:00
|
|
|
#endif
|
2010-03-24 20:12:25 +00:00
|
|
|
#include <security.h>
|
2003-01-10 18:33:35 +00:00
|
|
|
|
2018-06-03 15:05:44 +01: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 10:48:20 +01:00
|
|
|
void filename_serialise(BinarySink *bs, const Filename *f)
|
2011-10-02 11:01:57 +00:00
|
|
|
{
|
2018-05-24 10:48:20 +01:00
|
|
|
put_asciz(bs, f->path);
|
2011-10-02 11:01:57 +00:00
|
|
|
}
|
2018-05-28 15:36:15 +01:00
|
|
|
Filename *filename_deserialise(BinarySource *src)
|
2003-02-01 12:54:40 +00:00
|
|
|
{
|
2018-05-28 15:36:15 +01: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 09:23:26 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01:00
|
|
|
GET_WINDOWS_FUNCTION(secur32, GetUserNameExA);
|
|
|
|
|
tried_usernameex = true;
|
|
|
|
|
}
|
2010-03-24 20:12:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p_GetUserNameExA) {
|
2019-09-08 20:29:00 +01: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 20:29:00 +01: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 20:02:32 +01: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");
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 15:21:11 +01:00
|
|
|
#if !HAVE_SETDEFAULTDLLDIRECTORIES
|
2021-04-10 14:45:24 +01:00
|
|
|
/* For older Visual Studio, 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 18:56:55 +01:00
|
|
|
GET_WINDOWS_FUNCTION_NO_TYPECHECK(
|
|
|
|
|
kernel32_module, SetDefaultDllDirectories);
|
|
|
|
|
#else
|
2016-07-18 20:02:32 +01: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 18:56:55 +01:00
|
|
|
#endif
|
2016-07-18 20:02:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p_SetDefaultDllDirectories) {
|
2017-04-03 21:30:18 +02:00
|
|
|
/* LOAD_LIBRARY_SEARCH_SYSTEM32 and explicitly specified
|
|
|
|
|
* directories only */
|
|
|
|
|
p_SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 |
|
|
|
|
|
LOAD_LIBRARY_SEARCH_USER_DIRS);
|
2016-07-18 20:02:32 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-03 15:05:44 +01:00
|
|
|
void init_winver(void)
|
2003-08-21 19:48:45 +00:00
|
|
|
{
|
2018-06-03 15:05:44 +01: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 15:05:44 +01: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 19:42:37 +01: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 14:13:20 +02: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 10:48:20 +01:00
|
|
|
void fontspec_serialise(BinarySink *bs, FontSpec *f)
|
2011-10-01 17:38:59 +00:00
|
|
|
{
|
2018-05-24 10:48:20 +01: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 15:36:15 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01: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 20:29:00 +01:00
|
|
|
debug_fp = fopen("debug.log", "w");
|
2019-01-23 23:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (debug_hdl != INVALID_HANDLE_VALUE) {
|
2019-09-08 20:29:00 +01: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;
|
|
|
|
|
}
|