New library-style 'utils' subdirectories.
Now that the new CMake build system is encouraging us to lay out the
code like a set of libraries, it seems like a good idea to make them
look more _like_ libraries, by putting things into separate modules as
far as possible.
This fixes several previous annoyances in which you had to link
against some object in order to get a function you needed, but that
object also contained other functions you didn't need which included
link-time symbol references you didn't want to have to deal with. The
usual offender was subsidiary supporting programs including misc.c for
some innocuous function and then finding they had to deal with the
requirements of buildinfo().
This big reorganisation introduces three new subdirectories called
'utils', one at the top level and one in each platform subdir. In each
case, the directory contains basically the same files that were
previously placed in the 'utils' build-time library, except that the
ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c,
winmisc.c, winmiscs.c, winutils.c) have been split up into much
smaller pieces.
2021-04-17 14:22:20 +00:00
|
|
|
/*
|
|
|
|
* GetOpenFileName/GetSaveFileName tend to muck around with the process'
|
|
|
|
* working directory on at least some versions of Windows.
|
|
|
|
* Here's a wrapper that gives more control over this, and hides a little
|
|
|
|
* bit of other grottiness.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "putty.h"
|
|
|
|
|
|
|
|
struct filereq_tag {
|
|
|
|
TCHAR cwd[MAX_PATH];
|
2023-05-29 14:30:57 +00:00
|
|
|
WCHAR wcwd[MAX_PATH];
|
New library-style 'utils' subdirectories.
Now that the new CMake build system is encouraging us to lay out the
code like a set of libraries, it seems like a good idea to make them
look more _like_ libraries, by putting things into separate modules as
far as possible.
This fixes several previous annoyances in which you had to link
against some object in order to get a function you needed, but that
object also contained other functions you didn't need which included
link-time symbol references you didn't want to have to deal with. The
usual offender was subsidiary supporting programs including misc.c for
some innocuous function and then finding they had to deal with the
requirements of buildinfo().
This big reorganisation introduces three new subdirectories called
'utils', one at the top level and one in each platform subdir. In each
case, the directory contains basically the same files that were
previously placed in the 'utils' build-time library, except that the
ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c,
winmisc.c, winmiscs.c, winutils.c) have been split up into much
smaller pieces.
2021-04-17 14:22:20 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* `of' is expected to be initialised with most interesting fields, but
|
|
|
|
* this function does some administrivia. (assume `of' was memset to 0)
|
|
|
|
* save==1 -> GetSaveFileName; save==0 -> GetOpenFileName
|
|
|
|
* `state' is optional.
|
|
|
|
*/
|
|
|
|
bool request_file(filereq *state, OPENFILENAME *of, bool preserve, bool save)
|
|
|
|
{
|
|
|
|
TCHAR cwd[MAX_PATH]; /* process CWD */
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
/* Get process CWD */
|
|
|
|
if (preserve) {
|
|
|
|
DWORD r = GetCurrentDirectory(lenof(cwd), cwd);
|
|
|
|
if (r == 0 || r >= lenof(cwd))
|
|
|
|
/* Didn't work, oh well. Stop trying to be clever. */
|
|
|
|
preserve = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Open the file requester, maybe setting lpstrInitialDir */
|
|
|
|
{
|
|
|
|
#ifdef OPENFILENAME_SIZE_VERSION_400
|
|
|
|
of->lStructSize = OPENFILENAME_SIZE_VERSION_400;
|
|
|
|
#else
|
|
|
|
of->lStructSize = sizeof(*of);
|
|
|
|
#endif
|
|
|
|
of->lpstrInitialDir = (state && state->cwd[0]) ? state->cwd : NULL;
|
|
|
|
/* Actually put up the requester. */
|
|
|
|
ret = save ? GetSaveFileName(of) : GetOpenFileName(of);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get CWD left by requester */
|
|
|
|
if (state) {
|
|
|
|
DWORD r = GetCurrentDirectory(lenof(state->cwd), state->cwd);
|
|
|
|
if (r == 0 || r >= lenof(state->cwd))
|
|
|
|
/* Didn't work, oh well. */
|
|
|
|
state->cwd[0] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Restore process CWD */
|
|
|
|
if (preserve)
|
|
|
|
/* If it fails, there's not much we can do. */
|
|
|
|
(void) SetCurrentDirectory(cwd);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-05-29 14:30:57 +00:00
|
|
|
/*
|
|
|
|
* Here's the same one again, the wide-string version
|
|
|
|
*/
|
|
|
|
bool request_file_w(filereq *state, OPENFILENAMEW *of,
|
|
|
|
bool preserve, bool save)
|
|
|
|
{
|
|
|
|
WCHAR cwd[MAX_PATH]; /* process CWD */
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
/* Get process CWD */
|
|
|
|
if (preserve) {
|
|
|
|
DWORD r = GetCurrentDirectoryW(lenof(cwd), cwd);
|
|
|
|
if (r == 0 || r >= lenof(cwd))
|
|
|
|
/* Didn't work, oh well. Stop trying to be clever. */
|
|
|
|
preserve = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Open the file requester, maybe setting lpstrInitialDir */
|
|
|
|
{
|
|
|
|
of->lStructSize = sizeof(*of);
|
|
|
|
of->lpstrInitialDir = (state && state->wcwd[0]) ? state->wcwd : NULL;
|
|
|
|
/* Actually put up the requester. */
|
|
|
|
ret = save ? GetSaveFileNameW(of) : GetOpenFileNameW(of);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get CWD left by requester */
|
|
|
|
if (state) {
|
|
|
|
DWORD r = GetCurrentDirectoryW(lenof(state->wcwd), state->wcwd);
|
|
|
|
if (r == 0 || r >= lenof(state->wcwd))
|
|
|
|
/* Didn't work, oh well. */
|
|
|
|
state->wcwd[0] = L'\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Restore process CWD */
|
|
|
|
if (preserve)
|
|
|
|
/* If it fails, there's not much we can do. */
|
|
|
|
(void) SetCurrentDirectoryW(cwd);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
New library-style 'utils' subdirectories.
Now that the new CMake build system is encouraging us to lay out the
code like a set of libraries, it seems like a good idea to make them
look more _like_ libraries, by putting things into separate modules as
far as possible.
This fixes several previous annoyances in which you had to link
against some object in order to get a function you needed, but that
object also contained other functions you didn't need which included
link-time symbol references you didn't want to have to deal with. The
usual offender was subsidiary supporting programs including misc.c for
some innocuous function and then finding they had to deal with the
requirements of buildinfo().
This big reorganisation introduces three new subdirectories called
'utils', one at the top level and one in each platform subdir. In each
case, the directory contains basically the same files that were
previously placed in the 'utils' build-time library, except that the
ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c,
winmisc.c, winmiscs.c, winutils.c) have been split up into much
smaller pieces.
2021-04-17 14:22:20 +00:00
|
|
|
filereq *filereq_new(void)
|
|
|
|
{
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
filereq *state = snew(filereq);
|
|
|
|
state->cwd[0] = '\0';
|
2023-05-29 14:30:57 +00:00
|
|
|
state->wcwd[0] = L'\0';
|
Rename 'ret' variables passed from allocation to return.
I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no
longer fond of the variable name 'ret', because it's used in two quite
different contexts: it's the return value from a subroutine you just
called (e.g. 'int ret = read(fd, buf, len);' and then check for error
or EOF), or it's the value you're preparing to return from the
_containing_ routine (maybe by assigning it a default value and then
conditionally modifying it, or by starting at NULL and reallocating,
or setting it just before using the 'goto out' cleanup idiom). In the
past I've occasionally made mistakes by forgetting which meaning the
variable had, or accidentally conflating both uses.
If all else fails, I now prefer 'retd' (short for 'returned') in the
former situation, and 'toret' (obviously, the value 'to return') in
the latter case. But even better is to pick a name that actually says
something more specific about what the thing actually is.
One particular bad habit throughout this codebase is to have a set of
functions that deal with some object type (say 'Foo'), all *but one*
of which take a 'Foo *foo' parameter, but the foo_new() function
starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the
canonical name for the ambient Foo is 'foo', so should foo_new()!
So here's a no-brainer start on cutting down on the uses of 'ret': I
looked for all the cases where it was being assigned the result of an
allocation, and renamed the variable to be a description of the thing
being allocated. In the case of a new() function belonging to a
family, I picked the same name as the rest of the functions in its own
family, for consistency. In other cases I picked something sensible.
One case where it _does_ make sense not to use your usual name for the
variable type is when you're cloning an existing object. In that case,
_neither_ of the Foo objects involved should be called 'foo', because
it's ambiguous! They should be named so you can see which is which. In
the two cases I found here, I've called them 'orig' and 'copy'.
As in the previous refactoring, many thanks to clang-rename for the
help.
2022-09-13 13:53:36 +00:00
|
|
|
return state;
|
New library-style 'utils' subdirectories.
Now that the new CMake build system is encouraging us to lay out the
code like a set of libraries, it seems like a good idea to make them
look more _like_ libraries, by putting things into separate modules as
far as possible.
This fixes several previous annoyances in which you had to link
against some object in order to get a function you needed, but that
object also contained other functions you didn't need which included
link-time symbol references you didn't want to have to deal with. The
usual offender was subsidiary supporting programs including misc.c for
some innocuous function and then finding they had to deal with the
requirements of buildinfo().
This big reorganisation introduces three new subdirectories called
'utils', one at the top level and one in each platform subdir. In each
case, the directory contains basically the same files that were
previously placed in the 'utils' build-time library, except that the
ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c,
winmisc.c, winmiscs.c, winutils.c) have been split up into much
smaller pieces.
2021-04-17 14:22:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void filereq_free(filereq *state)
|
|
|
|
{
|
|
|
|
sfree(state);
|
|
|
|
}
|