PuTTY semi-bug slow-startup-printer

summary: Printer enumeration may cause slow startupclass: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.difficulty: tricky: Needs many tuits.priority: high: This should be fixed in the next release.absent-in: 0.52present-in: 0.53 0.53bfixed-in: 2003-08-22 (0.54) (0.55) (0.56) (0.57) (0.58) (0.59) (0.60) (0.61) (0.62)

There's been a suggestion (ref:
000c01c282b0$c6ae6c90$6e01a8c0@int.psross.net) that the ANSI
printer support added in 0.53 can cause PuTTY to take a long time to
start (~30 seconds) if a printer is configured in Windows that is not
reachable (e.g. shared from a machine that is currently switched off).
This may be intermittent rather than reliable. (Win2K Pro SP3)

We've not reproduced this so far (I've tried on Win2K pro), but a
workaround appears to be to remove the offending printers.

Alternatively, snapshots 2003-08-22 and later try less hard to find
printers and this has been reported to work.

Gory details:
PuTTY calls Windows functions to enumerate all suitable printers
(regardless of whether any attempt is made to use the ANSI
printing functionality):

when a saved session is loaded into the configuration dialog;

when a new panel is selected via the treeview control;

when the config dialog is initially drawn (side effect of above).

This means that this is not done if the configuration dialog
is bypassed (e.g., by loading a saved session directly).

PuTTY is a bit unusual in doing this; we use EnumPrinters (etc)
directly in order to avoid UI issues associated with the concept of
`raw' printing.

I've not been able to reproduce this on Win2K Pro.

This is to some extent not our problem, but perhaps we could do
something to mitigate the problem (e.g. enumerate printers less often
/ only if the user requests the ANSI printing functionality).

Alternative fix: use a different type of printer enumeration
which doesn't try so hard. Patch:
yehhebmmpfq.fsf@ocean.cs.brown.edu. Dependent on Windows
version, so need to ensure the functionality still works across at
least the Win95-series and WinNT-series.

In detail, we should use PRINTER_INFO_4 where possible,
rather than PRINTER_INFO_1 which apparently calls
OpenPrinter() for every printer. However, _4
is only available on NT-class systems; the suggestion is that we
detect the Windows version and use _5 on 95-class systems -
Usenet
corroborates this approach. (We're already avoiding
_5 on NT because we had problems enumerating network
printers.) Yuk.

Update 2003-02-26: verified that PRINTER_INFO_4
on Win2K SP2 and PRINTER_INFO_5 on Win98 work as least as
well for me as what we do currently (PRINTER_INFO_1). All
that remains is the tedious mucking around with version detection.

Update 2003-08-22: finally got round to implementing this, and
got a report that it works.