D.1 Cross-OS portability

Despite Windows being its main area of fame, PuTTY is no longer a Windows-only application suite. It has a working Unix port; a Mac port is in progress; more ports may or may not happen at a later date.

Therefore, embedding Windows-specific code in core modules such as ssh.c is not acceptable. We went to great lengths to remove all the Windows-specific stuff from our core modules, and to shift it out into Windows-specific modules. Adding large amounts of Windows-specific stuff in parts of the code that should be portable is almost guaranteed to make us reject a contribution.

The PuTTY source base is divided into platform-specific modules and platform-generic modules. The Unix-specific modules are all in the unix subdirectory; the Mac-specific modules are in the mac subdirectory; the Windows-specific modules are in the windows subdirectory.

All the modules in the main source directory - notably all of the code for the various back ends - are platform-generic. We want to keep them that way.

This also means you should stick to what you are guaranteed by ANSI/ISO C (that is, the original C89/C90 standard, not C99). Try not to make assumptions about the precise size of basic types such as int and long int; don't use pointer casts to do endianness-dependent operations, and so on.

(There are one or two aspects of ANSI C portability which we don't care about. In particular, we expect PuTTY to be compiled on 32-bit architectures or bigger; so it's safe to assume that int is at least 32 bits wide, not just the 16 you are guaranteed by ANSI C. Similarly, we assume that the execution character encoding is a superset of the printable characters of ASCII, though we don't assume the numeric values of control characters, particularly '\n' and '\r'. Also, the X forwarding code assumes that time_t has the Unix format and semantics, i.e. an integer giving the number of seconds since 1970.)