Portable PuTTY patch comments

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I've created a patch to allow PuTTY (Windows) to read settings from file
instead of the registry.

WHY: Although the workaround suggested in the docs (4.2.1 Storing  
configuration in a file) works well, I accidentally overwrote then
deleted a friends HKCR\Software\SimonTatham\PuTTY registry entry when
running PuTTY from an admin CDROM I use.

I had sent the developers a detailed proposal that I was planning to
implment several months ago, but never heard back.  So, I'm looking for
user feedback. My objective is to modify/patch as few files as possible
in the hope that the patch will actually get included

Right now I have putty.exe working, using the same methods for
reading/writing that the ux source does.  Actually it's a copy of the
code, with a few modifications.  I would have liked to use the uxstore.c
code, but that would have involved too much refactoring, which, although
simple, might lessen the chances the patch would ever get implemented in
the main tree.

So, I'm looking for feedback on the following: Should the patch store
files in the same way the unix code does (multiple files in a config
dir), or should it be in a single file, like an INI?  As I see it, pros
and cons of both:

INI Pros
- One file, easy to grab and go
INI Cons
- Could get big, depending upon how many sessions/keys are saved
- If it is big, and run from a floppy (who does that?) could be slow to
  read and write.
- Can't share/distribute a single session with someone.

UX Method Pros:
- Much easier to implement since 99% code comes from uxstore.c
- Can share/distribute a single session file
UX Method Cons:
- When taking PuTTY on the road, must copy config dir instead of one

Factors in making a decision (in order of priority)
1) PuTTY dev team rules
2) Lots of responses: majority rule
3) Few responses: whatever is easiest rules
4) No responses: my own Personal Portable Putty Patch mmm.. PortaPuTTY

When completed, I guess I'll post the patch here since I think email to
PuTTY dev team goes to /dev/null. Or should I post somewhere else?

Finally, if anyone has comments on the randomseed file:
I'm not really sure why this is stored; it gets changed everytime
you run PuTTY anyway.  I'm thinking of not storing it (since, you
won't be able to if running from CDROM anyway).  Thoughts?

Charles Appel

Re: Portable PuTTY patch comments

Quoted text here. Click to load it

The PuTTY development team do read all the email we get, and we reply
to a significant proportion of it.  However we cannot guarantee
replying to any email because we get so much of the stuff, and have
other important things like full-time jobs, social lives, and sleep to
fit into our lives.

Revamping the config to be able to use the Registry and config files
is something we want to do for a future release.  See:


...for some of the things we think are important for the settings

Quoted text here. Click to load it

Perhaps you should read the code to find out what it's used for?


Re: Portable PuTTY patch comments

owend@chiark.greenend.org.uk says...
Quoted text here. Click to load it
Sure, I understand.  I'm sure you get a lot of emails and I take no
offence.  That's why in my original email to your team, I read and
referenced sections B3 and B4 or the user manual, as well as section
4.2.1 and config- locations.html in which I provided potential answers
that seemed to address the issues listed.  I figured a well written,
well researched email was the best way to get a response as well as the
responsible thing to do.

Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it

In all the links you posted, they are classified as priority medium:
once again, I understand.  If there had been many responses to my
original posting, it would have given me a sense for it's demand.  
Apparently, not much, which is sufficient for me to decide to implement
it however I see fit without consideration as to whether or not it will
be placed in the CVS tree.

Quoted text here. Click to load it

Yes, looking at the code is an important part patching (or, at least
patching well).  grep random.*seed on .c and .h files doesn't give too
much information, with the exception of some info in macstore.c. The faq
in the doc directory is most helpful, but I was unable to find a
reference as to why it was being saved, just that if on a public
machine, you probably want to run -cleanup, which is sufficient
information for me to complete my implementation; just thought I'd
solicit comments.  Thanks for yours.


Site Timeline