The Old New Thing

Isn't that (trying to) solve the problem at the wrong leven? To me, the real question is: why does it take so long for the remote computer to find out if it has printers to share?

getTimeBack Method

Returns the time wasted

function getTimeBack() : Number Remarks

The getTime method returns an integer value containing the time wasted, in milliseconds.

So Explorer has finally gone multithreaded in Vista?

@Karl De Pesser:

"Why does it take so long for the remote computer to find out if it has printers to share?"

It's like asking a question to a person and wait for the answer. The time it takes depends on that person you asked, not you. All you can do is wait up to a maximum amount of time.

Yes, I always thought that it took suspiciously long for a computer on our 100 MB/s local area network with a whopping 8 computers connected, and the domain controller which is pretty much always idle and is on the same local area network, to say that there are, or are not, any printers to share.

While I agree with this decision, I am wondering what other resources that could be shared (now or in the future) that could result in such a "Shared_Resource_Folder_Placeholder".

IMHO it's not a good way to return false/erroneous/misleading information to the user just because <here a lot of "good technical reasons">.

People, when they face a computer, want to get reliable information. If an information doesn't exist it must not be displayed. You can display it "just in case it's valid". The information has no more any value.

All the reasons you're presenting are technical excuses, not valid user experience reasons.

What we can say is "Windows, being XP or Vista, has a big problem reporting easily and quickly such a basic information". The way shared printers are scanned is simply not the good one. When a PC is returning its network name it should return a bit saying "I have at least 1 share printer" or "I do not have any shared printer". So shared printers icon should displayed of hidden according the real situation at the same time the PC name is displayed.

The answer to the shared printer icon must be technical cause it's a technical problem. It must not be "pushed" to the user interface while washing one's hands of it.

Because of this kind of "solution" a software (and an OS is like any other software) becomes slowly unusable as time is passing. A lot of such little "details" become numerous and the user experience is degraded, full of incoherences (as XP "start button" that must be used to "stop" the PC! crazy choice!).

Microsoft is doing big efforts to enhance the "user experience", new OS interface, new UI engine like WPF, etc. It will be a bad idea to keep old bad habits when we get now beautiful tools to create unique user experiences...

@odahan

Grow up. Writing an OS is complex business. Anybody who tries is going to make mistakes. MS have made one here with the printer enumeration code. Now its either too hard to fix, not important enough, or not worthwhile. Raymond is doing us a service by explaining how things work and why they made the decision they did.

If you're unhappy enough with the decision, stop spending your money on the OS and then stop following a blog on programming an OS that you don't use. Otherwise, I suggest you give us your thoughts on how this should work _after_ you've implemented them in your own perfect OS.

Quote from odahan: 'When a PC is returning its network name it should return a bit saying "I have at least 1 share printer" or "I do not have any shared printer".'

Assuming you mean "A PC responding to a name query should return a structure containing flags about basic network information, and one such flag should be whether or not the are any printers shared", that still only solves the problem for clients who know about the new structure, and then only for calls to computers who happen to have this feature support.  

The explorer UI has to support any computer that could possibly share a printer, not just computers which return nice flags.  If you could make up the rules by which other people implement their systems, then you can have a solution like what you suggested.  Since you can't, you still have to handle the case where the computer you're connecting to takes a long time to return any printer shares.

Personally, I don't think showing a printers folder that will be empty is a problem.   It just says "This is where any shared printers will be, if there are any", and while it used to say "There are shared printers here" and changing that meaning is probably bad, in the long term people will become acustomed to the new meaning and then the problem won't exist.

@Bogus,

Grow up. Designing an useable OS is a complex business. The most important factor in staying competitive is listening to customer feedback. If you'll keep saying "if you don't like it, switch to another <product>", your customers (if you have any) will do exactly that. So far, Microsoft customers seem to be losing brand loyalty. One of the factors is such an arrogant attitude.

@odahan

I don't think that showing that folder is such a terrible choice: the local Printer and fax folder is always shown, even if there's no printer installed; there's nothing wrong in showing an empty folder. Moreover, personally I prefer to save the time needed to enumerate the printers if I don't need to access them (and accessing remote printers is quite an infrequent operation, usually if you need to use a remote printer you add it to the local printer folder, thus enumerating the remote printers just when you do this).

Since y'all are being so serious about this...

How often do you browse to a remote machine, care about the printer, and yet have no idea if a printer is attached? 99% of the time (according to numbers I just made up, but seem reasonable), you either aren't after the shared printers, or you know the machine has a shared printer!

Chasing it any farther then it already is would be optimizing for an edge-case.

I do have a question about Odahan's suggestion- Would that "flag" be set after you confirm that the printer is online, the user has rights to see the printer, etc? Or would it just be a quick "I have a printer", and then that other stuff is checked when the goes to to the printer folder?

What kind of compatibility concerns were there with making this change?  I bet there is some random application out there that relies on the previous behavior.  I am going to find it and install it on every Vista machine I can find.

I, for one, applaud this change. It is definitely better for the vast majority of cases. I even remember some "XP optimization guide" which set a registry to disable printer enumeration.

I also wonder why it's so slow. Actually, there are many things in Windows File&Printers sharing that in inexplicably slow - try "net use" with a mistyped password, for one.

This was a good change. As noted above, most of the time, you're not going to care about whether there is a shared printer or not.

There are lots of commenters on this blog who believe they have a superior solution to almost every Windows behavior. I believe they are mostly writing from the luxury of complete ignorance.

[Well, for one thing, it has to a security check, and that requires communicating with the domain controller, which might be connected via a slow link. And even if you somehow magically fix all that, it works only if the remote computer is running a version of Windows that has the fix. Heck, the remote computer might not even be running Windows! -Raymond]

Which is different in what way from the security check that has to be run for each shared folder displayed in the same window?

Of course, by extending the user interface just a wee bit, it could become obvious to everyone that the Printers icon needs to be displayed even when the other computer has none.  Just add "Add New Printer at Remote Computer Wizard" and "Start Sharing Remote Computer's Printers Wizard" icons into the Printers folder.  Naturally these will, if double-clicked, display an error message if:

(1) You aren't an administrator on the remote computer.

(2) Printer sharing isn't installed on the remote computer.

(3) Remote configuration of the computer is disabled (Remote Registry service disabled or admin shares deleted).

Of course for the sake of performance, the icons will be displayed to all users and the checks run only later.

I've always wondered what is taking so long, even on a full Vista network over 100 MB or more ethernet.

When you map a drive to a nonworking location (think corporate logon script) explorer becomes almost unusuable, even for C:.

My gues was it tried to find new plug and play printers on every computer.  If that's not it, I wonder what it is?

If the network (or disk) traffic makes enumerating the IEnumIDList interface possibly slow, why not provide an asynchronous version rather than spawning threads. I like to write my apps to use asynchronous IO and the thread pool rather than creating my own threads (I'm also a .net guy but hey).

It's stuff like this that makes that approach really tough.

Koro: Guh?  I'm pretty sure it's always been like that.  At least I'm sure it's like that in XP.

Yeah, just opened a folder, icons loaded after the file list was displayed.  I'm pretty sure that icon loading isn't happening on the main UI thread.  It could be but WHY?  They'd basically be implementing their own threading system anyway in order to keep the UI responsive.

(I don't have any network shares on hand to check that specific example ATM.)

Jonathan: Wrong passwords seem to take longer to kick back an error than right passwords kick back an "it worked!" response on some programs... Windows and Linux based alike.

My theory is that it's a simple deterrent to dictionary/brute force attacks.  Even with just a delay of 1s between password attempts (and without any other security mechanisms against dictionary attacks), you've ensured that someone trying a dictionary of, say, 50,000 words is going to find their attack takes almost 14hrs longer than without that delay.  Most password rejects are a few seconds that I've seen.

@Dan: On XP, the 'My Computer' view that lists your drives definitely locks up the explorer UI (with just a grey screen for company) whilst slow network drive enumeration takes place. At my workplace this takes 6-8 seconds first time, and is quite frustrating. 'Map Network Drive' also takes ages, and also locks the UI.

Icon loading does happen as a background task, but the initial enumeration of names and drive characteristics doesn't.

And I like your wrong password delay theory. Explains something that's vaguely puzzled me for a while.

(BTW, hope everyone here had a great Christmas.)

I think that asking for Printers folders to only show up if there's a printer you can access on a given computer is like asking for a telephone book to only show entries for people who are home.

Is this the RemoteComputer/NameSpace registry entry?

If yes, is it the problem or the "fix"?

Well, sooner or later the system is going to figure out whether any printers are actually shared or not, at which point you've got option of hiding the folder even if you started out showing it just-in-case. I don't know how Vista handles this case but either way the rationale behind that decision would be rather interesting as well.

I think always showing the Printers folder is a pretty elegant solution to a hairy problem. I think it'd be much worse to have a situation where the remote computer sends along a bit saying "I have a printer" only to have it process security details/printer status/etc. in the background and resultingly take the printer it once displayed out of the dialog.

I can easily imagine a situation where the printer appearing, then disappearing would result in the user continually refreshing the window, thinking that there was a display bug or something.

It's actually a security breach if a user can determine if a server has any printers when he/she doesn't have access to any of them.

What if the printers true presence would be shown to clients with sufficient rights, not taking longer than a split of a second.

For queries that take longer, show an icon that indicates "I'm still waiting/getting feedback" from the peer.

Not to mention that the Explorer still remains responsive.

But heck, if it is that rocket science I can live with the current approach.