mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 01:18:00 +00:00
75b6e12f84
This begins the process of making PuTTY more able to handle Unicode strings as a first-class type in its configuration. One of the new types, CONF_TYPE_UTF8, looks physically just like CONF_TYPE_STR but the semantics are that it's definitely encoded in UTF-8, instead of 'shrug, whatever the system locale's encoding is'. Unfortunately, we can't yet switch over any Conf items to having that type, because our data representations in saved configuration (both on Unix and Windows) store char strings in the system encoding. So we'll have to change that representation at the same time, which risks breaking backwards compatibility with old PuTTYs reading the same configuration. So the other new type, CONF_TYPE_STR_AMBI, is intended as a transitional form, recording a configuration setting that _might_ be explicitly UTF-8 or might have the legacy 'shrug, whatever' semantics, depending on where we got it from. My general migration plan is that first I _enable_ Unicode support in a Conf item, by turning it into STR_AMBI; the Unicode version of the string (if any) is saved in a new location, and a best-effort local-charset version is saved where it's always been. That way new PuTTY can read the Unicode version, and old PuTTY reading that configuration will behave no worse than it would have done already. It would be nice to think that in the far future we've migrated everything to STR_AMBI and can move them all to mandatory UTF-8, obsoleting the old configuration. I think it's more likely we'll never get there. But at least _new_ Conf items, with no backwards compatibility requirement in the first place, can be CONF_TYPE_UTF8 where appropriate. (In conf_get_str_ambi(), I considered making it mandatory via assert() to pass the 'utf8' output pointer as non-NULL, to defend against lazy adaptation of existing code by just changing the function call. But in fact I think there's a legitimate use case for not caring if the output is UTF-8 or not, because some of the existing SSH code currently just shoves strings like usernames directly on to the wire whether they're in the right encoding or not; so if you want to do the correct UTF-8 thing where possible and preserve legacy behaviour if not, then treating both classes of string the same _is_ the right thing to do.) This also requires linking the Unicode support into many Unix applications that hadn't previously needed it. |
||
|---|---|---|
| charset | ||
| cmake | ||
| contrib | ||
| crypto | ||
| doc | ||
| icons | ||
| keygen | ||
| otherbackends | ||
| proxy | ||
| ssh | ||
| stubs | ||
| terminal | ||
| test | ||
| unicode | ||
| unix | ||
| utils | ||
| windows | ||
| .gitignore | ||
| aqsync.c | ||
| be_list.c | ||
| Buildscr | ||
| Buildscr.cv | ||
| callback.c | ||
| cgtest.c | ||
| CHECKLST.txt | ||
| clicons.c | ||
| CMakeLists.txt | ||
| cmdgen.c | ||
| cmdline.c | ||
| conf-enums.h | ||
| conf.h | ||
| config.c | ||
| console.c | ||
| console.h | ||
| defs.h | ||
| dialog.c | ||
| dialog.h | ||
| errsock.c | ||
| import.c | ||
| LATEST.VER | ||
| ldisc.c | ||
| LICENCE | ||
| licence.pl | ||
| logging.c | ||
| marshal.h | ||
| misc.h | ||
| mksrcarc.sh | ||
| mkunxarc.sh | ||
| mpint.h | ||
| network.h | ||
| pageant.c | ||
| pageant.h | ||
| pinger.c | ||
| pscp.c | ||
| psftp.c | ||
| psftp.h | ||
| psftpcommon.c | ||
| psocks.c | ||
| psocks.h | ||
| putty.h | ||
| puttymem.h | ||
| README | ||
| release.pl | ||
| settings.c | ||
| sign.sh | ||
| specials.h | ||
| ssh.h | ||
| sshcr.h | ||
| sshkeygen.h | ||
| sshpubk.c | ||
| sshrand.c | ||
| storage.h | ||
| timing.c | ||
| tree234.h | ||
| version.h | ||
| x11disp.c | ||
PuTTY source code README
========================
This is the README for the source code of PuTTY, a free Windows and
Unix Telnet and SSH client.
PuTTY is built using CMake <https://cmake.org/>. To compile in the
simplest way (on any of Linux, Windows or Mac), the general method is
to run these commands in the source directory:
cmake .
cmake --build .
These commands will expect to find a usable compile toolchain on your
path. So if you're building on Windows with MSVC, you'll need to make
sure that the MSVC compiler (cl.exe) is on your path, by running one
of the 'vcvars32.bat' setup scripts provided with the tools. Then the
cmake commands above should work.
To install in the simplest way on Linux or Mac:
cmake --build . --target install
On Unix, pterm would like to be setuid or setgid, as appropriate, to
permit it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) The cmake install step
doesn't attempt to add these privileges, so if you want user login
recording to work, you should manually ch{own,grp} and chmod the
pterm binary yourself after installation. If you don't do this,
pterm will still work, but not update the user login databases.
Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory. If you aren't using one of our source snapshots,
you'll need to do this yourself. Halibut can be found at
<https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
https://www.chiark.greenend.org.uk/~sgtatham/putty/
If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.
See the file LICENCE for the licence conditions.