nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f317f8e67e
putty-source/windows/platform.h

734 lines
26 KiB
C
Raw Normal View History

Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
/*
Remove the switching system in puttyps.h. It was there because of a limitation of mkfiles.pl, which had a single list of include directories that it used on all platforms. CMake does not. So now there's an easier and more sensible way to have a different header file included on Windows and Unix: call it the same name in the two subdirectories, and rely on CMake having put the right one of those subdirs on the include path.
2021-04-18 06:58:27 +00:00
* windows/platform.h: Windows-specific inter-module stuff.
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
*/
Remove the switching system in puttyps.h. It was there because of a limitation of mkfiles.pl, which had a single list of include directories that it used on all platforms. CMake does not. So now there's an easier and more sensible way to have a different header file included on Windows and Unix: call it the same name in the two subdirectories, and rely on CMake having put the right one of those subdirs on the include path.
2021-04-18 06:58:27 +00:00
#ifndef PUTTY_WINDOWS_PLATFORM_H
#define PUTTY_WINDOWS_PLATFORM_H
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
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 14:21:11 +00:00
#include <winsock2.h>
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
#include <windows.h>
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#include <stdio.h> /* for FILENAME_MAX */
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
Include stdint.h (where available) for uintptr_t. Commit f2e61275f introduced the use of uintptr_t, without adding an include of <stdint.h> which is where the C standard says that type should be defined. This didn't cause a build failure, because Visual Studio also defines it in <stddef.h> which we do include. But a user points out that other Windows toolchains - e.g. MinGW - don't necessarily do the same. I can't add an unconditional include of <stdint.h>, because the VS I use for the current official builds doesn't have that header at all. So I conditionalise it out for old VS; if it needs throwing out for any other toolchain, I'll add further conditions as reports come in.
2015-09-28 18:52:38 +00:00
/* We use uintptr_t for Win32/Win64 portability, so we should in
* principle include stdint.h, which defines it according to the C
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 14:21:11 +00:00
* standard. But older versions of Visual Studio don't provide
Include stdint.h (where available) for uintptr_t. Commit f2e61275f introduced the use of uintptr_t, without adding an include of <stdint.h> which is where the C standard says that type should be defined. This didn't cause a build failure, because Visual Studio also defines it in <stddef.h> which we do include. But a user points out that other Windows toolchains - e.g. MinGW - don't necessarily do the same. I can't add an unconditional include of <stdint.h>, because the VS I use for the current official builds doesn't have that header at all. So I conditionalise it out for old VS; if it needs throwing out for any other toolchain, I'll add further conditions as reports come in.
2015-09-28 18:52:38 +00:00
* stdint.h at all, but do (non-standardly) define uintptr_t in
* stddef.h. So here we try to make sure _some_ standard header is
* included which defines uintptr_t. */
#include <stddef.h>
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 14:21:11 +00:00
#if !HAVE_NO_STDINT_H
Include stdint.h (where available) for uintptr_t. Commit f2e61275f introduced the use of uintptr_t, without adding an include of <stdint.h> which is where the C standard says that type should be defined. This didn't cause a build failure, because Visual Studio also defines it in <stddef.h> which we do include. But a user points out that other Windows toolchains - e.g. MinGW - don't necessarily do the same. I can't add an unconditional include of <stdint.h>, because the VS I use for the current official builds doesn't have that header at all. So I conditionalise it out for old VS; if it needs throwing out for any other toolchain, I'll add further conditions as reports come in.
2015-09-28 18:52:38 +00:00
#include <stdint.h>
#endif
New header file 'defs.h'. This centralises a few things that multiple header files were previously defining, and were protecting against each other's redefinition with ifdefs - small things like structs and typedefs. Now all those things are in a defs.h which is by definition safe to include _first_ (out of all the codebase-local headers) and only need to be defined once.
2018-05-24 07:59:01 +00:00
#include "defs.h"
Add BinarySink wrappers on existing forms of output. There's now a stdio_sink, whose write function calls fwrite on the given FILE *; a bufchain_sink, whose write function appends to the given bufchain; and on Windows there's a handle_sink whose write function writes to the given 'struct handle'. (That is, not the raw Windows HANDLE, but our event-loop-friendly wrapper on it.) Not yet used for anything, but they're about to be.
2019-02-20 06:52:54 +00:00
#include "marshal.h"
New header file 'defs.h'. This centralises a few things that multiple header files were previously defining, and were protecting against each other's redefinition with ifdefs - small things like structs and typedefs. Now all those things are in a defs.h which is by definition safe to include _first_ (out of all the codebase-local headers) and only need to be defined once.
2018-05-24 07:59:01 +00:00
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
#include "tree234.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "help.h"
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
Mention CPU architecture in Windows build info. Apparently Windows on Arm has an emulator that lets it run x86 binaries without it being obvious, which could get confusing when people start reporting what version of what they're running where. (Indeed, it might get confusing for _me_ during early testing.) So now the Windows builds explicitly state 'x86' or 'Arm' as well as 32- or 64-bit.
2018-05-31 17:12:01 +00:00
#if defined _M_IX86 || defined _M_AMD64
#define BUILDINFO_PLATFORM "x86 Windows"
#elif defined _M_ARM || defined _M_ARM64
#define BUILDINFO_PLATFORM "Arm Windows"
#else
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
#define BUILDINFO_PLATFORM "Windows"
Mention CPU architecture in Windows build info. Apparently Windows on Arm has an emulator that lets it run x86 binaries without it being obvious, which could get confusing when people start reporting what version of what they're running where. (Indeed, it might get confusing for _me_ during early testing.) So now the Windows builds explicitly state 'x86' or 'Arm' as well as 32- or 64-bit.
2018-05-31 17:12:01 +00:00
#endif
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
struct Filename {
Turn 'Filename' into a dynamically allocated type with no arbitrary length limit, just as I did to FontSpec yesterday. [originally from svn r9316]
2011-10-02 11:01:57 +00:00
char *path;
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
};
Replace a couple more #defines with inline functions. My trawl of all the vtable systems in the code spotted a couple of other function-like macros in passing, which might as well be rewritten as inline functions too for the same reasons.
2019-02-27 19:47:12 +00:00
static inline FILE *f_open(const Filename *filename, const char *mode,
bool isprivate)
{
return fopen(filename->path, mode);
}
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
struct FontSpec {
Change the semantics of 'FontSpec' so that it's a dynamically allocated type. The main reason for this is to stop it from taking up a fixed large amount of space in every 'struct value' subunion in conf.c, although that makes little difference so far because Filename is still doing the same thing (and is therefore next on my list). However, the removal of its arbitrary length limit is not to be sneezed at. [originally from svn r9314]
2011-10-01 17:38:59 +00:00
char *name;
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 isbold;
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
int height;
int charset;
};
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
struct FontSpec *fontspec_new(
const char *name, bool bold, int height, int charset);
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 12:54:40 +00:00
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#ifndef CLEARTYPE_QUALITY
#define CLEARTYPE_QUALITY 5
#endif
#define FONT_QUALITY(fq) ( \
(fq) == FQ_DEFAULT ? DEFAULT_QUALITY : \
(fq) == FQ_ANTIALIASED ? ANTIALIASED_QUALITY : \
(fq) == FQ_NONANTIALIASED ? NONANTIALIASED_QUALITY : \
CLEARTYPE_QUALITY)
Support in the cross-platform code for translating to and from UTF-16 when exchanging wchar_t strings with the front end. Enabled by a #define in the platform's header file (one should not promiscuously translate UTF-16 surrogate pairs on 32-bit wchar_t platforms since that could give rise to redundant encoding attacks), which is present on Windows. [originally from svn r8495]
2009-03-24 22:24:31 +00:00
#define PLATFORM_IS_UTF16 /* enable UTF-16 processing when exchanging
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* wchar_t strings with environment */
Support in the cross-platform code for translating to and from UTF-16 when exchanging wchar_t strings with the front end. Enabled by a #define in the platform's header file (one should not promiscuously translate UTF-16 surrogate pairs on 32-bit wchar_t platforms since that could give rise to redundant encoding attacks), which is present on Windows. [originally from svn r8495]
2009-03-24 22:24:31 +00:00
Add a system of clipboard identifiers. This lays some groundwork for making PuTTY's cut and paste handling more flexible in the area of which clipboard(s) it reads and writes, if more than one is available on the system. I've introduced a system of list macros which define an enumeration of integer clipboard ids, some defined centrally in putty.h (at present just a CLIP_NULL which never has any text in it, because that seems like the sort of thing that will come in useful for configuring a given copy or paste UI action to be ignored) and some defined per platform. All the front end functions that copy and paste take a clipboard id, and the Terminal structure is now configured at startup to tell it which clipboard id it should paste from on a mouse click, and which it should copy from on a selection. However, I haven't actually added _real_ support for multiple X11 clipboards, in that the Unix front end supports a single CLIP_SYSTEM regardless of whether it's in OS X or GTK mode. So this is currently a NFC refactoring which does nothing but prepare the way for real changes to come.
2017-12-09 12:00:13 +00:00
#define PLATFORM_CLIPBOARDS(X) \
X(CLIP_SYSTEM, "system clipboard") \
/* end of list */
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
/*
* Where we can, we use GetWindowLongPtr and friends because they're
* more useful on 64-bit platforms, but they're a relatively recent
* innovation, missing from VC++ 6 and older MinGW. Degrade nicely.
* (NB that on some systems, some of these things are available but
* not others...)
*/
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
#ifndef GCLP_HCURSOR
/* GetClassLongPtr and friends */
#undef GetClassLongPtr
#define GetClassLongPtr GetClassLong
#undef SetClassLongPtr
#define SetClassLongPtr SetClassLong
#define GCLP_HCURSOR GCL_HCURSOR
/* GetWindowLongPtr and friends */
#undef GetWindowLongPtr
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#define GetWindowLongPtr GetWindowLong
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
#undef SetWindowLongPtr
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#define SetWindowLongPtr SetWindowLong
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
#undef GWLP_USERDATA
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#define GWLP_USERDATA GWL_USERDATA
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
#undef DWLP_MSGRESULT
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#define DWLP_MSGRESULT DWL_MSGRESULT
Somewhat gruesome tweak to use SetClassLongPtr where available and degrade nicely elsewhere, which should fix `win64' _properly_. Tested on recent-ish MinGW (with GetWindowLongPtr but not GetClassLongPtr), and VC++ 6.0 with a recent SDK, but not with vanilla VC++. [originally from svn r6535] [this svn revision also touched putty-wishlist]
2006-01-27 20:49:59 +00:00
/* Since we've clobbered the above functions, we should clobber the
* associated type regardless of whether it's defined. */
#undef LONG_PTR
#define LONG_PTR LONG
Configurable font quality on Windows. (Together with a little bit of macro stuff to cope with the inadequacy of VC++ 6 headers.) [originally from svn r6519]
2006-01-11 23:42:02 +00:00
#endif
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
#if !HAVE_STRTOUMAX
/* Work around lack of strtoumax in older MSVC libraries */
static inline uintmax_t strtoumax(const char *nptr, char **endptr, int base)
{ return _strtoui64(nptr, endptr, base); }
#endif
Make SaneDialogBox and SaneEndDialog use [GS]etWindowLong rather than a global variable. Should mean that pageant builds. [originally from svn r3274]
2003-06-18 17:25:18 +00:00
#define BOXFLAGS DLGWINDOWEXTRA
Use {Get,Set}WindowLongPtr() instead of {Get,Set}WindowLong() for compatibility with 64-bit Windows. Untested on 64-bit, but it doesn't appear to have broken anything on 32-bit. [originally from svn r5819]
2005-05-21 14:16:43 +00:00
#define BOXRESULT (DLGWINDOWEXTRA + sizeof(LONG_PTR))
Fix double-keystrokes by wrapping CreateDialog [originally from svn r3267]
2003-06-16 23:55:26 +00:00
#define DF_END 0x0001
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#ifndef __WINE__
Stop using MS-deprecated names stricmp and strnicmp. clang-cl generates warnings saying they're deprecated, in favour of the same names but prefixed with an underscore. The warnings are coming from the standard MS headers, and I'm already #defining those names differently on Unix, so I'll honour them.
2017-02-05 11:13:45 +00:00
/* Up-to-date Windows headers warn that the unprefixed versions of
* these names are deprecated. */
#define stricmp _stricmp
#define strnicmp _strnicmp
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#else
/* Compiling with winegcc, _neither_ version of these functions
* exists. Use the POSIX names. */
#define stricmp strcasecmp
#define strnicmp strncasecmp
#endif
Stop using MS-deprecated names stricmp and strnicmp. clang-cl generates warnings saying they're deprecated, in favour of the same names but prefixed with an underscore. The warnings are coming from the standard MS headers, and I'm already #defining those names differently on Unix, so I'll honour them.
2017-02-05 11:13:45 +00:00
Move the SSH implementation into its own subdirectory. This clears up another large pile of clutter at the top level, and in the process, allows me to rename source files to things that don't all have that annoying 'ssh' prefix at the top.
2021-04-22 16:58:40 +00:00
#define BROKEN_PIPE_ERROR_CODE ERROR_BROKEN_PIPE /* used in ssh/sharing.c */
Avoid logging pre-verstring EPIPE from sharing downstreams. If you use the new 'plink -shareexists' feature, then on Unix at least it's possible for the upstream to receive EPIPE, because the downstream makes a test connection and immediately closes it, so that upstream fails to write its version string. This looks a bit ugly in the upstream's Event Log, so I'm making a special case: an error of 'broken pipe' type, which occurs on a socket from a connection sharing downstream, before we've received a version string from that downstream, is treated as an unusual kind of normal connection termination and not logged as an error.
2015-09-25 11:05:55 +00:00
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
/*
I think r8738 broke IPv6 in MSVC Windows builds due to conflict with the WspiapiGetAddrInfo wrapper for getaddrinfo() in MSVC. Split GET_WINDOWS_FUNCTION into two variants, one with the old behaviour (bypassing the preprocessor) and another with the new behaviour (for ANSI/Unicode, although it's not actually used anywhere currently). [originally from svn r8898] [r8738 == 24b6168c1d4e6bf226f603a9b94c1ebf942b96f0]
2010-03-13 15:14:30 +00:00
* Dynamically linked functions. These come in two flavours:
*
* - GET_WINDOWS_FUNCTION does not expose "name" to the preprocessor,
* so will always dynamically link against exactly what is specified
* in "name". If you're not sure, use this one.
*
* - GET_WINDOWS_FUNCTION_PP allows "name" to be redirected via
* preprocessor definitions like "#define foo bar"; this is principally
* intended for the ANSI/Unicode DoSomething/DoSomethingA/DoSomethingW.
* If your function has an argument of type "LPTSTR" or similar, this
* is the variant to use.
* (However, it can't always be used, as it trips over more complicated
* macro trickery such as the WspiapiGetAddrInfo wrapper for getaddrinfo.)
*
* (DECL_WINDOWS_FUNCTION works with both these variants.)
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
*/
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
#define DECL_WINDOWS_FUNCTION(linkage, rettype, name, params) \
typedef rettype (WINAPI *t_##name) params; \
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
linkage t_##name p_##name
Stop using GLOBAL Windows API function pointers. The declarations in header files now use ordinary 'extern'. That means I have to arrange to put definitions matching those declarations in the appropriate modules; so I've made a macro DEFINE_WINDOWS_FUNCTION which performs a definition matching a prior DECLARE_WINDOWS_FUNCTION (and reusing the typedef made by the latter). This applies not only to the batch of functions that were marked GLOBAL in winstuff.h, but also the auxiliary sets marked WINCAPI_GLOBAL and WINSECUR_GLOBAL in wincapi.h and winsecur.h respectively.
2020-02-02 10:00:43 +00:00
/* If you DECL_WINDOWS_FUNCTION as extern in a header file, use this to
* define the function pointer in a source file */
#define DEF_WINDOWS_FUNCTION(name) t_##name p_##name
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
#define STR1(x) #x
#define STR(x) STR1(x)
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
#define GET_WINDOWS_FUNCTION_PP(module, name) \
TYPECHECK((t_##name)NULL == name, \
(p_##name = module ? \
(t_##name) GetProcAddress(module, STR(name)) : NULL))
#define GET_WINDOWS_FUNCTION(module, name) \
TYPECHECK((t_##name)NULL == name, \
(p_##name = module ? \
(t_##name) GetProcAddress(module, #name) : NULL))
#define GET_WINDOWS_FUNCTION_NO_TYPECHECK(module, name) \
(p_##name = module ? \
(t_##name) GetProcAddress(module, #name) : NULL)
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
#define PUTTY_REG_POS "Software\\SimonTatham\\PuTTY"
#define PUTTY_REG_PARENT "Software\\SimonTatham"
#define PUTTY_REG_PARENT_CHILD "PuTTY"
#define PUTTY_REG_GPARENT "Software"
#define PUTTY_REG_GPARENT_CHILD "SimonTatham"
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/* Result values for the jumplist registry functions. */
#define JUMPLISTREG_OK 0
#define JUMPLISTREG_ERROR_INVALID_PARAMETER 1
#define JUMPLISTREG_ERROR_KEYOPENCREATE_FAILURE 2
#define JUMPLISTREG_ERROR_VALUEREAD_FAILURE 3
#define JUMPLISTREG_ERROR_VALUEWRITE_FAILURE 4
#define JUMPLISTREG_ERROR_INVALID_VALUE 5
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
#define PUTTY_CHM_FILE "putty.chm"
Minor reorganisations to WinHelp support. (Done as part of a - failed - attempt to fix `winhelp-crash', but we may as well keep them.) [originally from svn r5314]
2005-02-16 01:47:10 +00:00
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
#define GETTICKCOUNT GetTickCount
#define CURSORBLINK GetCaretBlinkTime()
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define TICKSPERSEC 1000 /* GetTickCount returns milliseconds */
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
#define DEFAULT_CODEPAGE CP_ACP
Patch from Robert de Bath to ifdef out the Windows-specific hack for the offset horizontal line characters in the VT100 line-drawing set (o,p,r,s), so that no trace of it - and hence no pointless performance hit - is compiled into the cross-platform modules on non-Windows platforms. [originally from svn r9467]
2012-04-22 14:22:10 +00:00
#define USES_VTLINE_HACK
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
#ifndef NO_GSSAPI
/*
* GSS-API stuff
*/
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
#define GSS_CC CALLBACK
/*
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
typedef struct Ssh_gss_buf {
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
size_t length;
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
char *value;
} Ssh_gss_buf;
#define SSH_GSS_EMPTY_BUF (Ssh_gss_buf) {0,NULL}
Change the Unix version of Ssh_gss_name to be a gss_name_t rather than void *, and hence eliminate a few casts. The Windows definition is unchanged, but I daresay I've managed to stop it compiling nonetheless. [originally from svn r8359]
2008-12-01 21:18:29 +00:00
typedef void *Ssh_gss_name;
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
*/
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
#endif
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
/*
Remove remaining uses of the GLOBAL macro. We now have no remaining things in header files that switch from being a declaration to a definition depending on an awkward #define at the point of including that header. There are still a few mutable variables with external linkage, but at least now each one is defined in a specific source file file appropriate to its purpose and context. The remaining globals as of this commit were: - 'logctx' and 'term', which never needed to be globals in the first place, because they were never actually shared between source files. Now 'term' is just a static in window.c, and 'logctx' is a static in each of that and winplink.c. - 'hinst', which still has external linkage, but is now defined separately in each source file that sets it up (i.e. those with a WinMain) - osMajorVersion, osMinorVersion and osPlatformId, whose definitions now live in winmisc.c alongside the code which sets them up. (Actually they were defined there all along, it turns out, but every toolchain I've built with has commoned them together with the version defined by the GLOBAL in the header.) - 'hwnd', which nothing was actually _using_ any more after previous commits, so all this commit had to do was delete it.
2020-02-02 10:00:43 +00:00
* The all-important instance handle, saved from WinMain in every GUI
* program and exported for other GUI code to pass back to the Windows
* API.
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
*/
Remove remaining uses of the GLOBAL macro. We now have no remaining things in header files that switch from being a declaration to a definition depending on an awkward #define at the point of including that header. There are still a few mutable variables with external linkage, but at least now each one is defined in a specific source file file appropriate to its purpose and context. The remaining globals as of this commit were: - 'logctx' and 'term', which never needed to be globals in the first place, because they were never actually shared between source files. Now 'term' is just a static in window.c, and 'logctx' is a static in each of that and winplink.c. - 'hinst', which still has external linkage, but is now defined separately in each source file that sets it up (i.e. those with a WinMain) - osMajorVersion, osMinorVersion and osPlatformId, whose definitions now live in winmisc.c alongside the code which sets them up. (Actually they were defined there all along, it turns out, but every toolchain I've built with has commoned them together with the version defined by the GLOBAL in the header.) - 'hwnd', which nothing was actually _using_ any more after previous commits, so all this commit had to do was delete it.
2020-02-02 10:00:43 +00:00
extern HINSTANCE hinst;
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
Port forwarding module now passes backend handles around properly. As a result I've now been able to turn the global variables `back' and `backhandle' into module-level statics in the individual front ends. Now _that's_ progress! [originally from svn r2142]
2002-10-26 10:33:59 +00:00
/*
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
* Help file stuff in winhelp.c.
Port forwarding module now passes backend handles around properly. As a result I've now been able to turn the global variables `back' and `backhandle' into module-level statics in the individual front ends. Now _that's_ progress! [originally from svn r2142]
2002-10-26 10:33:59 +00:00
*/
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
void init_help(void);
void shutdown_help(void);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool has_help(void);
Initial support for HTML Help. All the ad-hoc help-file finding code and various calls to WinHelp() have been centralised into a new file winhelp.c, which in turn has been modified to detect a .CHM file as well as .HLP and select between them as appropriate. It explicitly tries to load HHCTRL.OCX and use GetProcAddress, meaning that it _should_ still work correctly on pre-HTML-Help platforms, falling gracefully back to WinHelp, but although I tested this by temporarily renaming my own HHCTRL.OCX I haven't yet been able to test it on a real HTML-Help-free platform. Also in this checkin: a new .but file and docs makefile changes to make it convenient to build the sources for a .CHM. As yet, owing to limitations of Halibut's CHM support, I'm not able to write a .CHM directly, more's the pity. [originally from svn r7000]
2006-12-17 11:16:07 +00:00
void launch_help(HWND hwnd, const char *topic);
void quit_help(HWND hwnd);
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
int has_embedded_chm(void); /* 1 = yes, 0 = no, -1 = N/A */
Port forwarding module now passes backend handles around properly. As a result I've now been able to turn the global variables `back' and `backhandle' into module-level statics in the individual front ends. Now _that's_ progress! [originally from svn r2142]
2002-10-26 10:33:59 +00:00
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
/*
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
* GUI seat methods in windlg.c, so that the vtable definition in
* window.c can refer to them.
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
*/
int win_seat_verify_ssh_host_key(
Pass more information to interactive host key check. Now we pass the whole set of fingerprints, and also a displayable format for the full host public key. NFC: this commit doesn't modify any of the host key prompts to _use_ any of the new information. That's coming next.
2021-03-13 10:59:47 +00:00
Seat *seat, const char *host, int port, const char *keytype,
char *keystr, const char *keydisp, char **key_fingerprints,
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
void (*callback)(void *ctx, int result), void *ctx);
int win_seat_confirm_weak_crypto_primitive(
Seat *seat, const char *algtype, const char *algname,
void (*callback)(void *ctx, int result), void *ctx);
int win_seat_confirm_weak_cached_hostkey(
Seat *seat, const char *algname, const char *betteralgs,
void (*callback)(void *ctx, int result), void *ctx);
Yet more global-removal. The static variables in logging.c are now absent, and also (I think) all the frontend request functions (such as request_resize) take a context pointer, so that multiple windows can be handled sensibly. I wouldn't swear to this, but I _think_ that only leaves the Unicode stuff as the last stubborn holdout. [originally from svn r2147]
2002-10-26 12:58:13 +00:00
Move declaration of write_aclip into winstuff.h. It's actually a function specific to the Windows front end, and has been all along - but I've only just noticed that no other front end either uses it or defines it.
2017-12-09 11:57:34 +00:00
/*
* Windows-specific clipboard helper function shared with windlg.c,
* which takes the data string in the system code page instead of
* Unicode.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void write_aclip(int clipboard, char *, int, bool);
Move declaration of write_aclip into winstuff.h. It's actually a function specific to the Windows front end, and has been all along - but I've only just noticed that no other front end either uses it or defines it.
2017-12-09 11:57:34 +00:00
Ben Rudiak-Gould points out that we should be using WM_APP as the base for our app-private window messages, which is considerably higher than the WM_XUSER we arbitrarily chose. (This isn't known to be causing any actual problems. The fix seems not to have obviously broken anything.) [originally from svn r6183] [this svn revision also touched putty-wishlist]
2005-08-10 18:31:24 +00:00
#define WM_NETEVENT (WM_APP + 5)
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
Selection now supported in pterm. Required small modifications outside the unix subdir, owing to more things needing to become platform-dependent. [originally from svn r2033]
2002-10-13 11:24:25 +00:00
/*
* On Windows, we send MA_2CLK as the only event marking the second
* press of a mouse button. Compare unix.h.
*/
#define MULTICLICK_ONLY_EVENT 1
/*
* On Windows, data written to the clipboard must be NUL-terminated.
*/
#define SELECTION_NUL_TERMINATED 1
SEL_NL is different between Windows and Unix; move it out into the platform-specific header files. [originally from svn r2043]
2002-10-14 09:06:31 +00:00
/*
* On Windows, copying to the clipboard terminates lines with CRLF.
*/
#define SEL_NL { 13, 10 }
Support XDM-AUTHORIZATION-1 for connecting to local X servers. If we're going to be a security program, we can at least make a token effort to use the most secure local X auth available! And I'm still half-tempted to see if I can support it for remote X servers too... [originally from svn r2537]
2003-01-11 09:31:54 +00:00
/*
* sk_getxdmdata() does not exist under Windows (not that I
* couldn't write it if I wanted to, but I haven't bothered), so
Overhaul of client-side XDM-AUTHORIZATION-1: * Make sk_getxdmdata() return an arbitrary string rather than two integers. This better matches the spec, even if the current version always returns six bytes * On Unix, for PF_UNIX sockets, return a counter rather than a constant along with the PID. This should allow multiple clients to connect within one second, and is what Xlib does. * On Unix, interpret AF_INET6 addresses like Xlib does, returning the embedded IPv4 address for v4-mapped addresses, and six bytes of zeroes otherwise. The latter is silly, but if I'm going to do anything more sane I need to check that X servers won't reject it. [originally from svn r5219]
2005-01-28 11:39:45 +00:00
* it's a macro which always returns NULL. With any luck this will
Support XDM-AUTHORIZATION-1 for connecting to local X servers. If we're going to be a security program, we can at least make a token effort to use the most secure local X auth available! And I'm still half-tempted to see if I can support it for remote X servers too... [originally from svn r2537]
2003-01-11 09:31:54 +00:00
* cause the compiler to notice it can optimise away the
Move the SSH implementation into its own subdirectory. This clears up another large pile of clutter at the top level, and in the process, allows me to rename source files to things that don't all have that annoying 'ssh' prefix at the top.
2021-04-22 16:58:40 +00:00
* implementation of XDM-AUTHORIZATION-1 in ssh/x11fwd.c :-)
Support XDM-AUTHORIZATION-1 for connecting to local X servers. If we're going to be a security program, we can at least make a token effort to use the most secure local X auth available! And I'm still half-tempted to see if I can support it for remote X servers too... [originally from svn r2537]
2003-01-11 09:31:54 +00:00
*/
Overhaul of client-side XDM-AUTHORIZATION-1: * Make sk_getxdmdata() return an arbitrary string rather than two integers. This better matches the spec, even if the current version always returns six bytes * On Unix, for PF_UNIX sockets, return a counter rather than a constant along with the PID. This should allow multiple clients to connect within one second, and is what Xlib does. * On Unix, interpret AF_INET6 addresses like Xlib does, returning the embedded IPv4 address for v4-mapped addresses, and six bytes of zeroes otherwise. The latter is silly, but if I'm going to do anything more sane I need to check that X servers won't reject it. [originally from svn r5219]
2005-01-28 11:39:45 +00:00
#define sk_getxdmdata(socket, lenp) (NULL)
Support XDM-AUTHORIZATION-1 for connecting to local X servers. If we're going to be a security program, we can at least make a token effort to use the most secure local X auth available! And I'm still half-tempted to see if I can support it for remote X servers too... [originally from svn r2537]
2003-01-11 09:31:54 +00:00
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
/*
* File-selector filter strings used in the config box. On Windows,
* these strings are of exactly the type needed to go in
* `lpstrFilter' in an OPENFILENAME structure.
*/
#define FILTER_KEY_FILES ("PuTTY Private Key Files (*.ppk)\0*.ppk\0" \
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"All Files (*.*)\0*\0\0\0")
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
#define FILTER_WAVE_FILES ("Wave Files (*.wav)\0*.WAV\0" \
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"All Files (*.*)\0*\0\0\0")
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
#define FILTER_DYNLIB_FILES ("Dynamic Library Files (*.dll)\0*.dll\0" \
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"All Files (*.*)\0*\0\0\0")
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
/*
* Exports from winnet.c.
*/
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
/* Report an event notification from WSA*Select */
void select_result(WPARAM, LPARAM);
/* Enumerate all currently live OS-level SOCKETs */
SOCKET first_socket(int *);
SOCKET next_socket(int *);
/* Ask winnet.c whether we currently want to try to write to a SOCKET */
bool socket_writable(SOCKET skt);
/* Force a refresh of the SOCKET list by re-calling do_select for each one */
void socket_reselect_all(void);
/* Make a SockAddr which just holds a named pipe address. */
SockAddr *sk_namedpipe_addr(const char *pipename);
Centralise implementations of Windows do_select(). Windows Plink and PSFTP had very similar implementations, and now they share one that lives in a new file winselcli.c. I've similarly moved GUI PuTTY's implementation out of window.c into winselgui.c, where other GUI programs wanting to do networking will be able to access that too. In the spirit of centralisation, I've also taken the opportunity to make both functions use the reasonably complete winsock_error_string() rather than (for some historical reason) each inlining a minimal version that reports most errors as 'unknown'.
2020-01-01 11:10:22 +00:00
/* Turn a WinSock error code into a string. */
const char *winsock_error_string(int error);
Revamp Windows pending_netevent using toplevel callbacks. This greatly simplifies the process of calling select_result() from the top level after receiving WM_NETEVENT. [originally from svn r10024]
2013-08-17 16:06:35 +00:00
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
/*
* winnet.c dynamically loads WinSock 2 or WinSock 1 depending on
* what it can get, which means any WinSock routines used outside
* that module must be exported from it as function pointers. So
* here they are.
*/
Stop using GLOBAL Windows API function pointers. The declarations in header files now use ordinary 'extern'. That means I have to arrange to put definitions matching those declarations in the appropriate modules; so I've made a macro DEFINE_WINDOWS_FUNCTION which performs a definition matching a prior DECLARE_WINDOWS_FUNCTION (and reusing the typedef made by the latter). This applies not only to the batch of functions that were marked GLOBAL in winstuff.h, but also the auxiliary sets marked WINCAPI_GLOBAL and WINSECUR_GLOBAL in wincapi.h and winsecur.h respectively.
2020-02-02 10:00:43 +00:00
DECL_WINDOWS_FUNCTION(extern, int, WSAAsyncSelect,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(SOCKET, HWND, u_int, long));
Stop using GLOBAL Windows API function pointers. The declarations in header files now use ordinary 'extern'. That means I have to arrange to put definitions matching those declarations in the appropriate modules; so I've made a macro DEFINE_WINDOWS_FUNCTION which performs a definition matching a prior DECLARE_WINDOWS_FUNCTION (and reusing the typedef made by the latter). This applies not only to the batch of functions that were marked GLOBAL in winstuff.h, but also the auxiliary sets marked WINCAPI_GLOBAL and WINSECUR_GLOBAL in wincapi.h and winsecur.h respectively.
2020-02-02 10:00:43 +00:00
DECL_WINDOWS_FUNCTION(extern, int, WSAEventSelect,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(SOCKET, WSAEVENT, long));
Stop using GLOBAL Windows API function pointers. The declarations in header files now use ordinary 'extern'. That means I have to arrange to put definitions matching those declarations in the appropriate modules; so I've made a macro DEFINE_WINDOWS_FUNCTION which performs a definition matching a prior DECLARE_WINDOWS_FUNCTION (and reusing the typedef made by the latter). This applies not only to the batch of functions that were marked GLOBAL in winstuff.h, but also the auxiliary sets marked WINCAPI_GLOBAL and WINSECUR_GLOBAL in wincapi.h and winsecur.h respectively.
2020-02-02 10:00:43 +00:00
DECL_WINDOWS_FUNCTION(extern, int, WSAGetLastError, (void));
DECL_WINDOWS_FUNCTION(extern, int, WSAEnumNetworkEvents,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(SOCKET, WSAEVENT, LPWSANETWORKEVENTS));
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#ifdef NEED_DECLARATION_OF_SELECT
/* This declaration is protected by an ifdef for the sake of building
* against winelib, in which you have to include winsock2.h before
* stdlib.h so that the right fd_set type gets defined. It would be a
* pain to do that throughout this codebase, so instead I arrange that
* only a modules actually needing to use (or define, or initialise)
* this function pointer will see its declaration, and _those_ modules
* - which will be Windows-specific anyway - can take more care. */
Stop using GLOBAL Windows API function pointers. The declarations in header files now use ordinary 'extern'. That means I have to arrange to put definitions matching those declarations in the appropriate modules; so I've made a macro DEFINE_WINDOWS_FUNCTION which performs a definition matching a prior DECLARE_WINDOWS_FUNCTION (and reusing the typedef made by the latter). This applies not only to the batch of functions that were marked GLOBAL in winstuff.h, but also the auxiliary sets marked WINCAPI_GLOBAL and WINSECUR_GLOBAL in wincapi.h and winsecur.h respectively.
2020-02-02 10:00:43 +00:00
DECL_WINDOWS_FUNCTION(extern, int, select,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(int, fd_set FAR *, fd_set FAR *,
fd_set FAR *, const struct timeval FAR *));
Fixes for winelib building (used by our Coverity build). Avoided referring to some functions and header files that aren't there in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory, multimon.h), and worked around a really amazingly annoying issue in which Winelib objects to you using the type 'fd_set' unless you included winsock2.h before stdlib.h.
2017-02-14 23:19:13 +00:00
#endif
The WinSock library is now loaded at run-time, which means we can attempt to load WS2 and then fall back to WS1 if that fails. This should allow us to use WS2-specific functionality to find out the local system's list of IP addresses, thus fixing winnet-if2lo, while degrading gracefully back to the previous behaviour if that functionality is unavailable. (I haven't yet actually done this; I've just laid the groundwork.) This checkin _may_ cause instability; it seemed fine to me on initial testing, but it's a bit of an upheaval and I wouldn't like to make bets on it just yet. [originally from svn r3502]
2003-10-12 13:46:12 +00:00
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
/*
Centralise implementations of Windows do_select(). Windows Plink and PSFTP had very similar implementations, and now they share one that lives in a new file winselcli.c. I've similarly moved GUI PuTTY's implementation out of window.c into winselgui.c, where other GUI programs wanting to do networking will be able to access that too. In the spirit of centralisation, I've also taken the opportunity to make both functions use the reasonably complete winsock_error_string() rather than (for some historical reason) each inlining a minimal version that reports most errors as 'unknown'.
2020-01-01 11:10:22 +00:00
* Implemented differently depending on the client of winnet.c, and
* called by winnet.c to turn on or off WSA*Select for a given socket.
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
*/
Const-correctness in do_select() return value. The error message it returns on failure is a string literal, so it shouldn't be returned as a mutable 'char *'.
2020-01-01 15:46:59 +00:00
const char *do_select(SOCKET skt, bool enable);
New timing infrastructure. There's a new function schedule_timer() which pretty much any module can call to request a call-back in the future. So terminal.c can do its own handling of blinking, visual bells and deferred screen updates, without having to rely on term_update() being called 50 times a second (fixes: pterm-timer); and ssh.c and telnet.c both invoke a new module pinger.c which takes care of sending keepalives, so they get sent uniformly in all front ends (fixes: plink-keepalives, unix-keepalives). [originally from svn r4906] [this svn revision also touched putty-wishlist]
2004-11-27 13:20:21 +00:00
Centralise implementations of Windows do_select(). Windows Plink and PSFTP had very similar implementations, and now they share one that lives in a new file winselcli.c. I've similarly moved GUI PuTTY's implementation out of window.c into winselgui.c, where other GUI programs wanting to do networking will be able to access that too. In the spirit of centralisation, I've also taken the opportunity to make both functions use the reasonably complete winsock_error_string() rather than (for some historical reason) each inlining a minimal version that reports most errors as 'unknown'.
2020-01-01 11:10:22 +00:00
/*
* Exports from winselgui.c and winselcli.c, each of which provides an
* implementation of do_select.
*/
void winselgui_set_hwnd(HWND hwnd);
void winselgui_clear_hwnd(void);
void winselcli_setup(void);
SOCKET winselcli_unique_socket(void);
extern HANDLE winselcli_event;
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
/*
* Network-subsystem-related functions provided in other Windows modules.
*/
Socket *make_handle_socket(HANDLE send_H, HANDLE recv_H, HANDLE stderr_H,
FdSocket, HandleSocket: store a notional peer address. In the case where these socket types are constructed because of a local proxy command, we do actually have a SockAddr representing the logical host we were trying to make a connection to. So we might as well store it in the socket implementation, and then we can include it in the PLUGLOG_CONNECT_SUCCESS call to make the log message more informative.
2021-09-13 13:34:46 +00:00
SockAddr *addr, int port, Plug *plug,
bool overlapped); /* winhsock */
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 10:06:33 +00:00
Socket *new_named_pipe_client(const char *pipename, Plug *plug); /* winnpc */
Socket *new_named_pipe_listener(const char *pipename, Plug *plug); /* winnps */
The remaining issue in `win-askappend-multi' appears to have been caused by the MessageBox() internal message loop eating WinSock FD_READ notifications, which then don't reappear afterwards because you have to explicitly prod a socket in order to get a repeat notification on it. Hence, here's a piece of infrastructure which seems to sort it out: a new winnet.c function called socket_reselect_all(), whose function is to go through all currently active sockets and re-run WSAAsyncSelect() on them, causing repeat notifications for anything we might have missed. I call this after every call to MessageBox(), and that seems to solve the problem. (The problem was actually masked in very recent revisions, probably by the reinstatement of pending_netevent in r7071. However, I don't believe that was a complete fix. This should be.) [originally from svn r7077] [r7071 == 57a763b0ec55b84d6a515e6d860759898d648869]
2007-01-08 19:38:39 +00:00
winnpc.c: add low-level connect_to_named_pipe() function. This contains most of the guts of the previously monolithic function new_named_pipe_client(), but it directly returns the HANDLE to the opened pipe, or a string error message on failure. new_named_pipe_client() is now a thin veneer on top of that, which returns a Socket * by wrapping up the HANDLE into a HandleSocket or the error message into an ErrorSocket as appropriate. So it's now possible to connect to a named pipe, using all our usual infrastructure (including in particular the ownership check of the server, to defend against spoofing attacks), without having to have a Socket-capable event loop in progress.
2020-01-01 18:58:11 +00:00
/* A lower-level function in winnpc.c, which does most of the work of
* new_named_pipe_client (including checking the ownership of what
* it's connected to), but returns a plain HANDLE instead of wrapping
* it into a Socket. */
HANDLE connect_to_named_pipe(const char *pipename, char **err);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
/*
* Exports from winctrls.c.
*/
struct ctlpos {
HWND hwnd;
WPARAM font;
int dlu4inpix;
int ypos, width;
int xoff;
Jeremy Sawicki's fix for the multiple-conflicting-accelerators problems: controls are now destroyed and recreated on a panel switch. In addition, this patch also introduces a better means of doing the group boxes. [originally from svn r884]
2001-01-22 17:17:26 +00:00
int boxystart, boxid;
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
char *boxtext;
};
Load comctl32.dll (for drag lists) at run time. This too is not in the list of known DLLs on Windows 10. I don't know of any actual viable hijacking attack based on it, which according to my reading of MSDN (specifically, a rather vague hint in https://msdn.microsoft.com/library/ff919712) _may_ be because we mention the common controls assembly in our application manifest; but better safe than sorry. Now the entire list of remaining DLLs that PuTTY links against at load time is a subset of the Win10 known DLLs list, so that _should_ mean that everything we load before we've deployed our own defence (SetDefaultDllDirectories) is defended against for us by Windows itself.
2017-03-13 21:42:44 +00:00
void init_common_controls(void); /* also does some DLL-loading */
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
/*
* Exports from winutils.c.
*/
Fix for `pageant-dirhandle': a new wrapper functions `request_file()' maintains a separate CWD for the file requester, so that when the Open File box is not open Pageant should stay where it was started. (Also some other minor cleanups in this area of Pageant.) [originally from svn r5413] [this svn revision also touched putty-wishlist]
2005-02-28 02:40:43 +00:00
typedef struct filereq_tag filereq; /* cwd for file requester */
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 request_file(filereq *state, OPENFILENAME *of, bool preserve, bool save);
Fix for `pageant-dirhandle': a new wrapper functions `request_file()' maintains a separate CWD for the file requester, so that when the Open File box is not open Pageant should stay where it was started. (Also some other minor cleanups in this area of Pageant.) [originally from svn r5413] [this svn revision also touched putty-wishlist]
2005-02-28 02:40:43 +00:00
filereq *filereq_new(void);
void filereq_free(filereq *state);
Stop winutils.c from depending on the global HWND. The GUI version of pgp_fingerprints() is now a differently named function that takes a parent HWND as a parameter, and so does my help-enabled wrapper around MessageBox.
2020-02-02 10:00:42 +00:00
void pgp_fingerprints_msgbox(HWND owner);
int message_box(HWND owner, LPCTSTR text, LPCTSTR caption,
DWORD style, DWORD helpctxid);
No border on Windows Pageant/PuTTYgen About boxes. (Bringing them in line with the PuTTY one in cc6ab00b71.)
2021-04-06 20:14:51 +00:00
void MakeDlgItemBorderless(HWND parent, int id);
Move a recently introduced utility function out of the file in which I declared it static, and into winutils.c where it can be more generally accessible. [originally from svn r9318]
2011-10-02 13:53:58 +00:00
char *GetDlgItemText_alloc(HWND hwnd, int id);
Pageant's command line handling now uses my new split_into_argv() function, because it's silly to have two (and because the old one was not the same as the new one, violating the Principle of Least Surprise). [originally from svn r1811]
2002-08-06 17:57:37 +00:00
void split_into_argv(char *, int *, char ***, char ***);
Revamp of command-line handling. Most command line options should now be processed in cmdline.c, which is called from all utilities (well, not Pageant or PuTTYgen). This should mean we get to standardise almost all options across almost all tools. Also one major change: `-load' is now the preferred option for loading a saved session in PuTTY proper. `@session' still works but is deprecated. [originally from svn r1799]
2002-08-04 21:18:56 +00:00
Jacob's patch for a drag-list to select SSH ciphers. Heavily hacked by me to make the drag list behaviour slightly more intuitive. WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH. [originally from svn r1199]
2001-08-25 19:33:33 +00:00
/*
* Private structure for prefslist state. Only in the header file
* so that we can delegate allocation to callers.
*/
struct prefslist {
int listid, upbid, dnbid;
int srcitem;
int dummyitem;
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 dragging;
Jacob's patch for a drag-list to select SSH ciphers. Heavily hacked by me to make the drag list behaviour slightly more intuitive. WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH. [originally from svn r1199]
2001-08-25 19:33:33 +00:00
};
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
/*
* This structure is passed to event handler functions as the `dlg'
* parameter, and hence is passed back to winctrls access functions.
*/
struct dlgparam {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
HWND hwnd; /* the hwnd of the dialog box */
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
struct winctrls *controltrees[8]; /* can have several of these */
int nctrltrees;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *wintitle; /* title of actual window */
char *errtitle; /* title of error sub-messageboxes */
void *data; /* data to pass in refresh events */
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
union control *focused, *lastfocused; /* which ctrl has focus now/before */
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 shortcuts[128]; /* track which shortcuts in use */
bool coloursel_wanted; /* has an event handler asked for
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
* a colour selector? */
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
struct {
unsigned char r, g, b; /* 0-255 */
bool ok;
} coloursel_result;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tree234 *privdata; /* stores per-control private data */
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 ended; /* has the dialog been ended? */
int endresult; /* and if so, what was the result? */
bool fixed_pitch_fonts; /* are we constrained to fixed fonts? */
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
};
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
/*
* Exports from winctrls.c.
*/
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void ctlposinit(struct ctlpos *cp, HWND hwnd,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int leftborder, int rightborder, int topborder);
Jacob's patch for a drag-list to select SSH ciphers. Heavily hacked by me to make the drag list behaviour slightly more intuitive. WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH. [originally from svn r1199]
2001-08-25 19:33:33 +00:00
HWND doctl(struct ctlpos *cp, RECT r,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *wclass, int wstyle, int exstyle, char *wtext, int wid);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void bartitle(struct ctlpos *cp, char *name, int id);
Jeremy Sawicki's fix for the multiple-conflicting-accelerators problems: controls are now destroyed and recreated on a panel switch. In addition, this patch also introduces a better means of doing the group boxes. [originally from svn r884]
2001-01-22 17:17:26 +00:00
void beginbox(struct ctlpos *cp, char *name, int idbox);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void endbox(struct ctlpos *cp);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void editboxfw(struct ctlpos *cp, bool password, char *text,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int staticid, int editid);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void radioline(struct ctlpos *cp, char *text, int id, int nacross, ...);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
void bareradioline(struct ctlpos *cp, int nacross, ...);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void radiobig(struct ctlpos *cp, char *text, int id, ...);
void checkbox(struct ctlpos *cp, char *text, int id);
Roman Pompejus's patch (heavily hacked) for parametric log file names with date, time and hostname automatically embedded. [originally from svn r1255]
2001-09-09 09:58:20 +00:00
void statictext(struct ctlpos *cp, char *text, int lines, int id);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void staticbtn(struct ctlpos *cp, char *stext, int sid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *btext, int bid);
PuTTYgen: add an extra button to save a public key into a file (as well as showing it for cut and paste). For SSH1, this feature is largely cosmetic and added for orthogonality; it comes into its own in SSH2, where it saves the Official One True Public Key Format as specified in the draft spec, and more particularly as used by ssh.com's product for authentication. Now that ssh-3.0.1 supports RSA user keys, this is suddenly actually useful. [originally from svn r1217]
2001-08-27 17:40:03 +00:00
void static2btn(struct ctlpos *cp, char *stext, int sid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *btext1, int bid1, char *btext2, int bid2);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void staticedit(struct ctlpos *cp, char *stext,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int sid, int eid, int percentedit);
Introduce the Bugs control panel, for overriding PuTTY's server version number checks to determine the presence or absence of server bugs. [originally from svn r1936]
2002-09-08 13:28:38 +00:00
void staticddl(struct ctlpos *cp, char *stext,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int sid, int lid, int percentlist);
Unicode cleanup phase 2: we now reintroduce the ability to enter a numeric code page, and also reinstate the direct-to-font zero translation mode (but now under an actual _name_ rather than blank). Also add CP437 to the list since at least one expatriate DOS user wanted it; also select a sensible ISO or KOI codepage based on the system locale. [originally from svn r1230]
2001-09-05 21:01:04 +00:00
void combobox(struct ctlpos *cp, char *text, int staticid, int listid);
PuTTYgen initial version. Still to do are basic user-friendliness features (prompt for passphrase twice, prompt before overwriting a file, check the key file was actually saved OK), testing of the generated keys to make sure I got the file format right, and support for a variable key size. I think what's already here is basically sound though. [originally from svn r715]
2000-10-19 15:43:08 +00:00
void staticpassedit(struct ctlpos *cp, char *stext,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int sid, int eid, int percentedit);
PuTTYgen initial version. Still to do are basic user-friendliness features (prompt for passphrase twice, prompt before overwriting a file, check the key file was actually saved OK), testing of the generated keys to make sure I got the file format right, and support for a variable key size. I think what's already here is basically sound though. [originally from svn r715]
2000-10-19 15:43:08 +00:00
void bigeditctrl(struct ctlpos *cp, char *stext,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int sid, int eid, int lines);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void ersatztab(struct ctlpos *cp, char *stext, int sid, int lid, int s2id);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void editbutton(struct ctlpos *cp, char *stext, int sid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int eid, char *btext, int bid);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void sesssaver(struct ctlpos *cp, char *text,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int staticid, int editid, int listid, ...);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void envsetter(struct ctlpos *cp, char *stext, int sid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *e1stext, int e1sid, int e1id,
char *e2stext, int e2sid, int e2id,
int listid, char *b1text, int b1id, char *b2text, int b2id);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void charclass(struct ctlpos *cp, char *stext, int sid, int listid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *btext, int bid, int eid, char *s2text, int s2id);
Miscellaneous cleanups and reorgs in preparation for building PuTTYgen. In particular, moved self-managing controls stuff out of windlg.c into the new and reusable winctrls.c. [originally from svn r714]
2000-10-18 15:36:32 +00:00
void colouredit(struct ctlpos *cp, char *stext, int sid, int listid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *btext, int bid, ...);
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
void prefslist(struct prefslist *hdl, struct ctlpos *cp, int lines,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *stext, int sid, int listid, int upbid, int dnbid);
Jacob's patch for a drag-list to select SSH ciphers. Heavily hacked by me to make the drag list behaviour slightly more intuitive. WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH. [originally from svn r1199]
2001-08-25 19:33:33 +00:00
int handle_prefslist(struct prefslist *hdl,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int *array, int maxmemb,
bool is_dlmsg, HWND hwnd,
WPARAM wParam, LPARAM lParam);
PuTTYgen initial version. Still to do are basic user-friendliness features (prompt for passphrase twice, prompt before overwriting a file, check the key file was actually saved OK), testing of the generated keys to make sure I got the file format right, and support for a variable key size. I think what's already here is basically sound though. [originally from svn r715]
2000-10-19 15:43:08 +00:00
void progressbar(struct ctlpos *cp, int id);
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-08 20:44:35 +00:00
void fwdsetter(struct ctlpos *cp, int listid, char *stext, int sid,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *e1stext, int e1sid, int e1id,
char *e2stext, int e2sid, int e2id,
char *btext, int bid,
char *r1text, int r1id, char *r2text, int r2id);
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
Expose the structure tag 'dlgparam'. This continues my ongoing crusade against dangerous 'void *' parameters.
2018-09-13 11:58:44 +00:00
void dlg_auto_set_fixed_pitch_flag(dlgparam *dlg);
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 dlg_get_fixed_pitch_flag(dlgparam *dlg);
void dlg_set_fixed_pitch_flag(dlgparam *dlg, bool flag);
Support for using variable-pitch fonts for the terminal on Windows. Done in much the same way as it is in the GTK front end: the character cell width is determined using the font's digits (which seems to give generally not-too-offensive spacing in most cases, at the expense of Ms and Ws typically overhanging a bit into adjacent cells) and each character is centred in its cell. Overhangs never leave permanent droppings on the window, because the existing work done in r5003 handles them just fine even in this stressful scenario. There's a hacky new checkbox in the Appearance panel to make variable-pitch fonts appear in the font selector (they still don't by default, because I still think it's _usually_ not What You Want); the checkbox state is not actually stored as part of a saved session, but it should be automatically ticked when reloading a session that's got a variable pitch font selected. (I'm half-expecting a potential flurry of requests for this feature in the wake of http://xkcd.com/840/ , so I thought I'd pre-empt them :-) [originally from svn r9063] [r5003 == ba470dec5e37ffbde05425f48e7e9a64219aec2e]
2010-12-29 14:11:25 +00:00
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
#define MAX_SHORTCUTS_PER_CTRL 16
/*
* This structure is what's stored for each `union control' in the
* portable-dialog interface.
*/
struct winctrl {
union control *ctrl;
/*
* The control may have several components at the Windows
* level, with different dialog IDs. To avoid needing N
* separate platformsidectrl structures (which could be stored
* separately in a tree234 so that lookup by ID worked), we
* impose the constraint that those IDs must be in a contiguous
* block.
*/
int base_id;
int num_ids;
dialog system: add a side-by-side alignment feature. This will let us put two controls side by side (e.g. in disjoint columns of a multi-col layout) and indicate that instead of the default behaviour of aligning their top edges, their centreline (or, even better if available, font baseline) should be aligned. NFC: nothing uses this yet.
2021-04-03 16:45:31 +00:00
/*
* For vertical alignment, the id of a particular representative
* control that has the y-extent of the sensible part of the
* control.
*/
int align_id;
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
/*
* Remember what keyboard shortcuts were used by this control,
* so that when we remove it again we can take them out of the
* list in the dlgparam.
*/
char shortcuts[MAX_SHORTCUTS_PER_CTRL];
/*
* Some controls need a piece of allocated memory in which to
* store temporary data about the control.
*/
void *data;
};
/*
* And this structure holds a set of the above, in two separate
* tree234s so that it can find an item by `union control' or by
* dialog ID.
*/
struct winctrls {
tree234 *byctrl, *byid;
};
As usual, gcc is better at warnings than MSVC, so here are some pedantic fiddlings with the new config-box stuff to cure some. [originally from svn r2909]
2003-03-06 12:41:39 +00:00
struct controlset;
struct controlbox;
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
void winctrl_init(struct winctrls *);
void winctrl_cleanup(struct winctrls *);
void winctrl_add(struct winctrls *, struct winctrl *);
void winctrl_remove(struct winctrls *, struct winctrl *);
struct winctrl *winctrl_findbyctrl(struct winctrls *, union control *);
struct winctrl *winctrl_findbyid(struct winctrls *, int);
struct winctrl *winctrl_findbyindex(struct winctrls *, int);
void winctrl_layout(struct dlgparam *dp, struct winctrls *wc,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct ctlpos *cp, struct controlset *s, int *id);
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 winctrl_handle_command(struct dlgparam *dp, UINT msg,
WPARAM wParam, LPARAM lParam);
As usual, gcc is better at warnings than MSVC, so here are some pedantic fiddlings with the new config-box stuff to cure some. [originally from svn r2909]
2003-03-06 12:41:39 +00:00
void winctrl_rem_shortcuts(struct dlgparam *dp, struct winctrl *c);
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 winctrl_context_help(struct dlgparam *dp, HWND hwnd, int id);
As usual, gcc is better at warnings than MSVC, so here are some pedantic fiddlings with the new config-box stuff to cure some. [originally from svn r2909]
2003-03-06 12:41:39 +00:00
Add the ability to allocate extra per-dialog-instance private data in the portable dialog interface. This has allowed me to remove `ssd->savedsession' in config.c, which was (I believe) the only out-of-place piece of per-instance data in the dialog template stuff. Now we should actually be able to run more than one config box in the same process at the same time (for platforms that'll find that useful). [originally from svn r2925]
2003-03-08 11:46:42 +00:00
void dp_init(struct dlgparam *dp);
void dp_add_tree(struct dlgparam *dp, struct winctrls *tree);
void dp_cleanup(struct dlgparam *dp);
As usual, gcc is better at warnings than MSVC, so here are some pedantic fiddlings with the new config-box stuff to cure some. [originally from svn r2909]
2003-03-06 12:41:39 +00:00
/*
* Exports from wincfg.c.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void win_setup_config_box(struct controlbox *b, HWND *hwndp, bool has_help,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
bool midsession, int protocol);
The long-awaited config box revamp! I've taken the whole config box to pieces, and put it back together in a new table-driven form. config.c sets up a data structure describing most of the config box; wincfg.c adds in the Windows-specific options (so that config.c can also form the basis for Mac and Unix config boxes). Then winctrls.c contains a shiny new layout engine which consumes that data structure, and windlg.c passes all WM_COMMAND and similar messages to a driver alongside that layout engine. In the process I've sorted out nicer-looking panel titles and finally fixed the list-boxes-are- never-the-right-size bug (turned out to be Windows's fault, of course). I _believe_ it should do everything the old config box did, including context help. Now everyone has to test it thoroughly... [originally from svn r2908]
2003-03-05 22:07:40 +00:00
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
/*
* Exports from windlg.c.
*/
void defuse_showwindow(void);
Stop having a global Conf. It's now a static in the main source file of each application that uses it, and isn't accessible from any other source file unless the main one passes it by reference. In fact, there were almost no instances of the latter: only the config-box functions in windlg.c were using 'conf' by virtue of its globalness, and it's easy to make those take it as a parameter.
2020-02-02 10:00:42 +00:00
bool do_config(Conf *);
bool do_reconfig(HWND, Conf *, int);
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
void showeventlog(HWND);
void showabout(HWND);
void force_normal(HWND hwnd);
As usual, gcc is better at warnings than MSVC, so here are some pedantic fiddlings with the new config-box stuff to cure some. [originally from svn r2909]
2003-03-06 12:41:39 +00:00
void modal_about_box(HWND hwnd);
void show_help(HWND hwnd);
Move the global 'logbox' into windlg.c. It was only used in one place outside that module, so I've provided an accessor for that one case.
2020-02-02 10:00:42 +00:00
HWND event_log_window(void);
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
Fix double-keystrokes by wrapping CreateDialog [originally from svn r3267]
2003-06-16 23:55:26 +00:00
/*
* Exports from winmisc.c.
*/
Remove remaining uses of the GLOBAL macro. We now have no remaining things in header files that switch from being a declaration to a definition depending on an awkward #define at the point of including that header. There are still a few mutable variables with external linkage, but at least now each one is defined in a specific source file file appropriate to its purpose and context. The remaining globals as of this commit were: - 'logctx' and 'term', which never needed to be globals in the first place, because they were never actually shared between source files. Now 'term' is just a static in window.c, and 'logctx' is a static in each of that and winplink.c. - 'hinst', which still has external linkage, but is now defined separately in each source file that sets it up (i.e. those with a WinMain) - osMajorVersion, osMinorVersion and osPlatformId, whose definitions now live in winmisc.c alongside the code which sets them up. (Actually they were defined there all along, it turns out, but every toolchain I've built with has commoned them together with the version defined by the GLOBAL in the header.) - 'hwnd', which nothing was actually _using_ any more after previous commits, so all this commit had to do was delete it.
2020-02-02 10:00:43 +00:00
extern DWORD osMajorVersion, osMinorVersion, osPlatformId;
Fix Windows warning about GetVersionEx deprecation. Rather than squelching the warning, I'm actually paying attention to the deprecation, in that I'm allowing for the possibility that the function might stop existing or stop returning success.
2018-06-03 14:05:44 +00:00
void init_winver(void);
Lock down the search path for Windows DLL loading. At least on systems providing SetDefaultDllDirectories, this should stop PuTTY from being willing to load DLLs from its containing directory - which makes no difference when it's been properly installed (in which case the application dir contains no DLLs anyway), but does if it's being run from somewhere uncontrolled like a browser downloads directory. Preliminary testing suggests that this shouldn't break any existing deliberate use of DLLs, including GSSAPI providers.
2016-07-18 19:02:32 +00:00
void dll_hijacking_protection(void);
Factor out Windows utility function get_system_dir(). The code to find out the location of the c:\windows\system32 directory was already present, in load_system32_dll(). Now it's moved out into a function of its own, so it can be called in other contexts.
2021-04-24 16:15:47 +00:00
const char *get_system_dir(void);
Create, and use for all loads of system DLLs, a wrapper function called load_system32_dll() which constructs a full pathname for the DLL using GetSystemDirectory. The only DLL load not covered by this change is the one for gssapi32.dll, because that one's not in the system32 directory. [originally from svn r8993]
2010-09-13 08:29:45 +00:00
HMODULE load_system32_dll(const char *libname);
Invent a win_strerror() function which behaves as much like Unix strerror as I can arrange, wrapping up all the ugly FormatMessage nonsense and caching previously looked-up messages for reuse so that callers can treat them as static. [originally from svn r9956]
2013-07-22 07:11:39 +00:00
const char *win_strerror(int error);
Turn off Windows process ACL restriction by default. As documented in bug 'win-process-acl-finesse', we've had enough assorted complaints about it breaking various non-malicious pieces of Windows process interaction (ranging from git->plink integration to screen readers for the vision-impaired) that I think it's more sensible to set the process back to its default level of protection. This precaution was never a fully effective protection anyway, due to the race condition at process startup; the only properly effective defence would have been to prevent malware running under the same user ID as PuTTY in the first place, so in that sense, nothing has changed. But people who want the arguable defence-in-depth advantage of the ACL restriction can now turn it on with the '-restrict-acl' command-line option, and it's up to them whether they can live with the assorted inconveniences that come with it. In the course of this change, I've centralised a bit more of the restriction code into winsecur.c, to avoid repeating the error handling in multiple places.
2017-01-28 21:56:28 +00:00
void restrict_process_acl(void);
Move the restricted_acl flag into winsecur.c. It's silly to set it at each call site of restrict_process_acl() if that function returns success! More sensible to have it be a flag in the same source file as restrict_process_acl(), set as an automatic _side effect_ of success. I've renamed the variable itself, and the global name 'restricted_acl' is now a query function that asks winsecur.c whether that operation has been (successfully) performed.
2020-02-02 10:00:42 +00:00
bool restricted_acl(void);
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);
void unescape_registry_key(const char *in, strbuf *out);
Fix for `slow-startup-printer': use PRINTER_INFO_4 on NT-class systems, which apparently tries less hard to find printers so won't slow the system down. Tested on 2000 and 98; in both cases printer enumeration and printing worked as well as they did in 2003-08-21. Made a single shared copy of osVersion in winmisc.c so that printing.c can find it. Made other users (window.c, pageant.c) use this copy. [originally from svn r3411]
2003-08-21 19:48:45 +00:00
New Windows utility function: is_console_handle(). Rather like isatty() on Unix, this tells you if a raw Windows HANDLE points at a console or not. Useful to know if your standard output or standard error is going to be shown to a user, or redirected to something that will make automated use of it.
2019-02-20 06:54:51 +00:00
bool is_console_handle(HANDLE);
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
/* A few pieces of up-to-date Windows API definition needed for older
* compilers. */
#ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
#define LOAD_LIBRARY_SEARCH_SYSTEM32 0x00000800
#endif
#ifndef LOAD_LIBRARY_SEARCH_USER_DIRS
#define LOAD_LIBRARY_SEARCH_USER_DIRS 0x00000400
#endif
#ifndef LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
#define LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR 0x00000100
#endif
Fix a build failure under Visual Studio 2010. Patch due to Brian K. White; we now condition our own declaration of DLL_DIRECTORY_COOKIE on whether the toolchain's headers had #defined it already, rather than trying to guess the answer to that from version-number macros. (Apparently everything that defines DLL_DIRECTORY_COOKIE does it by does seem to work in all my tests.)
2017-05-24 19:34:38 +00:00
#ifndef DLL_DIRECTORY_COOKIE
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
typedef PVOID DLL_DIRECTORY_COOKIE;
Fix a build failure under Visual Studio 2010. Patch due to Brian K. White; we now condition our own declaration of DLL_DIRECTORY_COOKIE on whether the toolchain's headers had #defined it already, rather than trying to guess the answer to that from version-number macros. (Apparently everything that defines DLL_DIRECTORY_COOKIE does it by does seem to work in all my tests.)
2017-05-24 19:34:38 +00:00
DECLSPEC_IMPORT DLL_DIRECTORY_COOKIE WINAPI AddDllDirectory (PCWSTR NewDirectory);
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
#endif
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
/*
* Exports from sizetip.c.
*/
void UpdateSizeTip(HWND src, int cx, int cy);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void EnableSizeTip(bool bEnable);
Begin destabilisation in the wake of 0.53! This checkin contains the beginning of a Unix port. It's nowhere near done, and currently it won't even compile on Unix. But this represents the start of the process of separating out platform-specific code, and also contains the mkfiles.pl changes required to support a Unix makefile and a non-flat source tree. [originally from svn r1993]
2002-10-07 16:45:23 +00:00
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
/*
* Exports from unicode.c.
*/
Fix small breakages as a result of yesterday's upheavals. Oops. [originally from svn r2610]
2003-01-15 16:16:36 +00:00
struct unicode_data;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
void init_ucs(Conf *, struct unicode_data *);
Proper support for using the font's own character encoding. If we know what that encoding actually is, we can do our best to support additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using the available characters; if we don't, we fall back to a mode where we disable all Unicode cut-and-paste and assume any Unicode character is undisplayable. [originally from svn r2413]
2003-01-01 22:25:25 +00:00
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
/*
* Exports from winhandl.c.
*/
Grow some nasty warts on the side of winhandl.c, in preparation for a serial port backend: - In order to do simultaneous reading and writing on the same HANDLE, you must enable overlapped access and pass an OVERLAPPED structure to each ReadFile and WriteFile call. This would make sense if it were an optional thing I could do if I wanted to do the reading and writing in the same thread, but making it mandatory even if I'm doing them in _different_ threads is just annoying and arbitrary. - Serial ports occasionally return length 0 from ReadFile, for no particularly good reason. Fortunately serial ports also don't have a real EOF condition to speak of, so ignoring EOFs is actually a viable response in spite of sounding utterly gross. Hence, handle_{input,output}_new() now accept a flags parameter, which includes a flag to enable the OVERLAPPED bureaucracy and a flag to cause EOFs to be ignored on input handles. The current clients of winhandl.c do not use either of these. [originally from svn r6813]
2006-08-27 10:00:36 +00:00
#define HANDLE_FLAG_OVERLAPPED 1
#define HANDLE_FLAG_IGNOREEOF 2
Eep! Next bit flag after 1 and 2 is _4_, not 3. Perhaps it's time I stopped coding and went and sat down quietly and tried not to touch anything for a while. [originally from svn r6828]
2006-08-28 18:27:54 +00:00
#define HANDLE_FLAG_UNITBUFFER 4
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
struct handle;
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
typedef size_t (*handle_inputfn_t)(
struct handle *h, const void *data, size_t len, int err);
handle_{got,sent}data: separate length and error params. Now we pass an error code in a separate dedicated parameter, instead of overloading the length parameter so that a negative value means an error code. This enables length to become unsigned without causing trouble.
2019-02-06 20:36:11 +00:00
typedef void (*handle_outputfn_t)(
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
struct handle *h, size_t new_backlog, int err);
Small tweak to the new handle API: provide a `privdata' field in each handle structure, set on initialisation and readable by an API call. [originally from svn r6798]
2006-08-26 07:41:15 +00:00
struct handle *handle_input_new(HANDLE handle, handle_inputfn_t gotdata,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *privdata, int flags);
Small tweak to the new handle API: provide a `privdata' field in each handle structure, set on initialisation and readable by an API call. [originally from svn r6798]
2006-08-26 07:41:15 +00:00
struct handle *handle_output_new(HANDLE handle, handle_outputfn_t sentdata,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *privdata, int flags);
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
size_t handle_write(struct handle *h, const void *data, size_t len);
Revamp of EOF handling in all network connections, pipes and other data channels. Should comprehensively fix 'half-closed', in principle, though it's a big and complicated change and so there's a good chance I've made at least one mistake somewhere. All connections should now be rigorous about propagating end-of-file (or end-of-data-stream, or socket shutdown, or whatever) independently in both directions, except in frontends with no mechanism for sending explicit EOF (e.g. interactive terminal windows) or backends which are basically always used for interactive sessions so it's unlikely that an application would be depending on independent EOF (telnet, rlogin). EOF should now never accidentally be sent while there's still buffered data to go out before it. (May help fix 'portfwd-corrupt', and also I noticed recently that the ssh main session channel can accidentally have MSG_EOF sent before the output bufchain is clear, leading to embarrassment when it subsequently does send the output). [originally from svn r9279]
2011-09-13 11:44:03 +00:00
void handle_write_eof(struct handle *h);
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
void handle_free(struct handle *h);
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
void handle_unthrottle(struct handle *h, size_t backlog);
size_t handle_backlog(struct handle *h);
Small tweak to the new handle API: provide a `privdata' field in each handle structure, set on initialisation and readable by an API call. [originally from svn r6798]
2006-08-26 07:41:15 +00:00
void *handle_get_privdata(struct handle *h);
Add BinarySink wrappers on existing forms of output. There's now a stdio_sink, whose write function calls fwrite on the given FILE *; a bufchain_sink, whose write function appends to the given bufchain; and on Windows there's a handle_sink whose write function writes to the given 'struct handle'. (That is, not the raw Windows HANDLE, but our event-loop-friendly wrapper on it.) Not yet used for anything, but they're about to be.
2019-02-20 06:52:54 +00:00
/* Analogue of stdio_sink in marshal.h, for a Windows handle */
struct handle_sink {
struct handle *h;
BinarySink_IMPLEMENTATION;
};
void handle_sink_init(handle_sink *sink, struct handle *h);
New piece of Windows infrastructure: winhandl.c takes Plink's thread-based approach to stdin and stdout, wraps it in a halfway sensible API, and makes it a globally available service across all network tools. There is no direct functionality enhancement from this checkin: winplink.c now talks to the new API instead of doing it all internally, but does nothing different as a result. However, this should lay the groundwork for several diverse pieces of work in future: pipe-based ProxyCommand on Windows, a serial port back end, and (hopefully) a pipe-based means of communicating with Pageant, which should have sensible blocking behaviour and hence permit asynchronous agent requests and decrypt-on-demand. [originally from svn r6797]
2006-08-25 22:10:16 +00:00
Reorganise Windows HANDLE management. Before commit 6e69223dc262755, Pageant would stop working after a certain number of PuTTYs were active at the same time. (At most about 60, but maybe fewer - see below.) This was because of two separate bugs. The easy one, fixed in 6e69223dc262755 itself, was that PuTTY left each named-pipe connection to Pageant open for the rest of its lifetime. So the real problem was that Pageant had too many active connections at once. (And since a given PuTTY might make multiple connections during userauth - one to list keys, and maybe another to actually make a signature - that was why the number of _PuTTYs_ might vary.) It was clearly a bug that PuTTY was leaving connections to Pageant needlessly open. But it was _also_ a bug that Pageant couldn't handle more than about 60 at once. In this commit, I fix that secondary bug. The cause of the bug is that the WaitForMultipleObjects function family in the Windows API have a limit on the number of HANDLE objects they can select between. The limit is MAXIMUM_WAIT_OBJECTS, defined to be 64. And handle-io.c was using a separate event object for each I/O subthread to communicate back to the main thread, so as soon as all those event objects (plus a handful of other HANDLEs) added up to more than 64, we'd start passing an overlarge handle array to WaitForMultipleObjects, and it would start not doing what we wanted. To fix this, I've reorganised handle-io.c so that all its subthreads share just _one_ event object to signal readiness back to the main thread. There's now a linked list of 'struct handle' objects that are ready to be processed, protected by a CRITICAL_SECTION. Each subthread signals readiness by adding itself to the linked list, and setting the event object to indicate that the list is now non-empty. When the main thread receives the event, it iterates over the whole list processing all the ready handles. (Each 'struct handle' still has a separate event object for the main thread to use to communicate _to_ the subthread. That's OK, because no thread is ever waiting on all those events at once: each subthread only waits on its own.) The previous HT_FOREIGN system didn't really fit into this framework. So I've moved it out into its own system. There's now a handle-wait.c which deals with the relatively simple job of managing a list of handles that need to be waited for, each with a callback function; that's what communicates a list of HANDLEs to event loops, and receives the notification when the event loop notices that one of them has done something. And handle-io.c is now just one client of handle-wait.c, providing a single HANDLE to the event loop, and dealing internally with everything that needs to be done when that handle fires. The new top-level handle-wait.c system *still* can't deal with more than MAXIMUM_WAIT_OBJECTS. At the moment, I'm reasonably convinced it doesn't need to: the only kind of HANDLE that any of our tools could previously have needed to wait on more than one of was the one in handle-io.c that I've just removed. But I've left some assertions and a TODO comment in there just in case we need to change that in future.
2021-05-24 12:06:10 +00:00
/*
* Exports from handle-wait.c.
*/
typedef struct HandleWait HandleWait;
typedef void (*handle_wait_callback_fn_t)(void *);
HandleWait *add_handle_wait(HANDLE h, handle_wait_callback_fn_t callback,
void *callback_ctx);
void delete_handle_wait(HandleWait *hw);
typedef struct HandleWaitList {
HANDLE handles[MAXIMUM_WAIT_OBJECTS];
int nhandles;
} HandleWaitList;
HandleWaitList *get_handle_wait_list(void);
void handle_wait_activate(HandleWaitList *hwl, int index);
void handle_wait_list_free(HandleWaitList *hwl);
Windows Pageant: establish a named-pipe server. This reuses all the named-pipe IPC code I set up for connection sharing a few years ago, to set up a named pipe with a predictable name and speak the stream-oriented SSH agent protocol over it. In this commit, we just set up the server, and there's no code that speaks the client end of the new IPC yet. But my plan is that clients should switch over to using this interface if possible, because it's generally better: it doesn't have to be handled synchronously in the middle of a GUI event loop (either in Pageant itself _or_ in its client), and it's a better fit to the connection-oriented nature of forwarded agent connections (so if any features ever appear in the agent protocol that require state within a connection, we'll now be able to support them).
2020-01-01 15:55:06 +00:00
/*
* Exports from winpgntc.c.
*/
char *agent_named_pipe_name(void);
Support for Windows PuTTY connecting straight to a local serial port in place of making a network connection. This has involved a couple of minor infrastructure changes: - New dlg_label_change() function in the dialog.h interface, which alters the label on a control. Only used, at present, to switch the Host Name and Port boxes into Serial Line and Speed, which means that any platform not implementing serial connections (i.e. currently all but Windows) does not need to actually do anything in this function. Yet. - New small piece of infrastructure: cfg_launchable() determines whether a Config structure describes a session ready to be launched. This was previously determined by seeing if it had a non-empty host name, but it has to check the serial line as well so there's a centralised function for it. I haven't gone through all front ends and arranged for this function to be used everywhere it needs to be; so far I've only checked Windows. - Similarly, cfg_dest() returns the destination of a connection (host name or serial line) in a text format suitable for putting into messages such as `Unable to connect to %s'. [originally from svn r6815]
2006-08-28 10:35:12 +00:00
/*
* Exports from winser.c.
*/
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
extern const struct BackendVtable serial_backend;
Support for Windows PuTTY connecting straight to a local serial port in place of making a network connection. This has involved a couple of minor infrastructure changes: - New dlg_label_change() function in the dialog.h interface, which alters the label on a control. Only used, at present, to switch the Host Name and Port boxes into Serial Line and Speed, which means that any platform not implementing serial connections (i.e. currently all but Windows) does not need to actually do anything in this function. Yet. - New small piece of infrastructure: cfg_launchable() determines whether a Config structure describes a session ready to be launched. This was previously determined by seeing if it had a non-empty host name, but it has to check the serial line as well so there's a centralised function for it. I haven't gone through all front ends and arranged for this function to be used everywhere it needs to be; so far I've only checked Windows. - Similarly, cfg_dest() returns the destination of a connection (host name or serial line) in a text format suitable for putting into messages such as `Unable to connect to %s'. [originally from svn r6815]
2006-08-28 10:35:12 +00:00
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/*
* Exports from winjump.c.
*/
#define JUMPLIST_SUPPORTED /* suppress #defines in putty.h */
void add_session_to_jumplist(const char * const sessionname);
void remove_session_from_jumplist(const char * const sessionname);
Try to delete jump lists in "-cleanup". [originally from svn r9050]
2010-12-26 20:00:45 +00:00
void clear_jumplist(void);
Nitpick: fix missing 'void' in one declaration. Jumped out at me in my trawl of the whole code base: set_explicit_app_user_model_id is declared and defined as () rather than (void), but this isn't C++.
2018-11-03 08:28:35 +00:00
bool set_explicit_app_user_model_id(void);
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
Windows PuTTYgen: switch to CryptGenRandom. We now only use the mouse-movement based entropy collection system if the system CPRNG fails to provide us with as much entropy as we want.
2018-06-03 13:41:31 +00:00
/*
* Exports from winnoise.c.
*/
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool win_read_random(void *buf, unsigned wanted); /* returns true on success */
Windows PuTTYgen: switch to CryptGenRandom. We now only use the mouse-movement based entropy collection system if the system CPRNG fails to provide us with as much entropy as we want.
2018-06-03 13:41:31 +00:00
Support for Windows 7 jump lists (right-click on a program's taskbar icon, even if the program isn't running at the time, to be presented with an application-defined collection of helpful links). The current jump list is updated every time a saved session is loaded, and shows the last few launchable saved sessions (i.e. not those like Default Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in the same directory as the PuTTY binary, the jump list will present links to launch those too. Based on a patch sent last year by Daniel B. Roy, though it's barely recognisable any more... [originally from svn r9046]
2010-12-23 17:32:28 +00:00
/*
* Extra functions in winstore.c over and above the interface in
* storage.h.
*
* These functions manipulate the Registry section which mirrors the
* current Windows 7 jump list. (Because the real jump list storage is
* write-only, we need to keep another copy of whatever we put in it,
* so that we can put in a slightly modified version the next time.)
*/
/* Adds a saved session to the registry jump list mirror. 'item' is a
* string naming a saved session. */
int add_to_jumplist_registry(const char *item);
/* Removes an item from the registry jump list mirror. */
int remove_from_jumplist_registry(const char *item);
/* Returns the current jump list entries from the registry. Caller
* must free the returned pointer, which points to a contiguous
* sequence of NUL-terminated strings in memory, terminated with an
* empty one. */
char *get_jumplist_registry_entries(void);
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
/*
* Windows clipboard-UI wording.
*/
#define CLIPNAME_IMPLICIT "Last selected text"
#define CLIPNAME_EXPLICIT "System clipboard"
#define CLIPNAME_EXPLICIT_OBJECT "system clipboard"
/* These defaults are the ones PuTTY has historically had */
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
#define CLIPUI_DEFAULT_AUTOCOPY true
Add GUI configuration for choice of clipboards. On all platforms, you can now configure which clipboard the mouse pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are: - nothing at all - a clipboard which is implicitly written by the act of mouse selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else) - the standard clipboard written by explicit copy/paste UI actions (CLIPBOARD on X, the unique system clipboard elsewhere). Also, you can control whether selecting text with the mouse _also_ writes to the explicitly accessed clipboard. The wording of the various messages changes between platforms, but the basic UI shape is the same everywhere.
2017-12-10 17:16:50 +00:00
#define CLIPUI_DEFAULT_MOUSE CLIPUI_EXPLICIT
#define CLIPUI_DEFAULT_INS CLIPUI_EXPLICIT
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
/* In winmisc.c */
char *registry_get_string(HKEY root, const char *path, const char *leaf);
Factor out common code from Windows CLI main loops. There aren't quite as many of these as there are on Unix, but Windows Plink and PSFTP still share some suspiciously similar-looking code. Now they're both clients of wincliloop.c.
2020-02-07 19:15:13 +00:00
/* In wincliloop.c */
typedef bool (*cliloop_pre_t)(void *vctx, const HANDLE **extra_handles,
size_t *n_extra_handles);
typedef bool (*cliloop_post_t)(void *vctx, size_t extra_handle_index);
void cli_main_loop(cliloop_pre_t pre, cliloop_post_t post, void *ctx);
bool cliloop_null_pre(void *vctx, const HANDLE **, size_t *);
bool cliloop_null_post(void *vctx, size_t);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
extern const struct BackendVtable conpty_backend;
/* Functions that parametrise window.c between PuTTY and pterm */
Move some parts of window.c into putty.c. This prepares the ground for a second essentially similarly-shaped program reusing most of window.c but handling its command line and startup differently. A couple of large parts of WinMain() to do with backend selection and command-line handling are now subfunctions in a separate file putty.c. Also, our custom AppUserModelId is defined in that file, so that it can vary with the client application.
2021-05-08 16:20:50 +00:00
void gui_term_process_cmdline(Conf *conf, char *cmdline);
const struct BackendVtable *backend_vt_from_conf(Conf *conf);
const wchar_t *get_app_user_model_id(void);
/* And functions in window.c that those files call back to */
char *handle_restrict_acl_cmdline_prefix(char *cmdline);
bool handle_special_sessionname_cmdline(char *cmdline, Conf *conf);
bool handle_special_filemapping_cmdline(char *cmdline, Conf *conf);
Remove the switching system in puttyps.h. It was there because of a limitation of mkfiles.pl, which had a single list of include directories that it used on all platforms. CMake does not. So now there's an easier and more sensible way to have a different header file included on Windows and Unix: call it the same name in the two subdirectories, and rely on CMake having put the right one of those subdirs on the include path.
2021-04-18 06:58:27 +00:00
#endif /* PUTTY_WINDOWS_PLATFORM_H */
Reference in New Issue Copy Permalink