PuTTY semi-bug slow-startup-printer

summary: Printer enumeration may cause slow startup
class: 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.52
present-in: 0.53 0.53b
fixed-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.

Audit trail for this semi-bug.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2004-11-16 15:27:00 +0000)