mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-05-28 23:34:49 -05:00
8bd75b85ed
The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
This is the README for 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), run these commands in
the source directory:
cmake .
cmake --build .
Then, 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.