The right way to introduce a feature like this is to put the new code in a separate source file, and (if necessary) introduce a second new source file defining the same set of functions, but defining them as stubs which don't provide the feature. Then the module whose behaviour needs to vary (proxy.c in this example) can call the functions defined in these two modules, and it will either provide the new feature or not provide it according to which of your new modules it is linked with. Of course, object files are never shared between platforms; so it is allowable to use #ifdef to select between platforms. This happens in puttyps.h (choosing which of the platform-specific include files to use), and also in misc.c (the Windows-specific ‘Minefield’ memory diagnostic system). It should be used sparingly, though, if at all.
D.14 Do as we say, not as we do The current PuTTY code probably does not conform strictly to all of the principles listed above. There may be the occasional SSH-specific piece of code in what should be a backend-independent module, or the occasional dependence on a non-standard X library function under Unix.
This should not be taken as a licence to go ahead and violate the rules. Where we violate them ourselves, we're not happy about it, and we would welcome patches that fix any existing problems. Please try to help us make our code better, not worse!
Appendix E: PuTTY download keys and signatures We create GPG signatures for all the PuTTY files distributed from our web site, so that users can be confident that the files have not been tampered with. Here we identify our public keys, and explain our signature policy so you can have an accurate idea of what each signature guarantees. This description is provided as both a web page on the PuTTY site, and an appendix in the PuTTY manual. As of release 0.58, all of the PuTTY executables contain fingerprint material (usually accessed via the -pgpfp command-line option), such that if you have an executable you trust, you can use it to establish a trust path, for instance to a newer version downloaded from the Internet. (Note that none of the keys, signatures, etc mentioned here have anything to do with keys used with SSH - they are purely for verifying the origin of files distributed by the PuTTY team.)
We maintain multiple keys, stored with different levels of security due to being used in different ways. See section E.2
below for details. The keys we provide are:
Snapshot Key
Used to sign routine development builds of PuTTY: nightly snapshots, pre-releases, and sometimes also custom diagnostic builds we send to particular users.
Release Key
Used to sign manually released versions of PuTTY.
Secure Contact Key
An encryption-capable key suitable for people to send confidential messages to the PuTTY team, e.g. reports of vulnerabilities.
Master Key
Used to tie all the above keys into the GPG web of trust. The Master Key signs all the other keys, and other GPG users have signed it in turn.