The Old New Thing

This post was a real eye-opener in two respects:

1. It suddenly made sense to me why I was temporarily disoriented on my home pc (vista) when searching for something... because all my work PC's have XP, and I didn't explicitly notice that search had gone away...  I would click Start, be lost for a split second, and then find another way to do what I needed to do.  Now I understand why I had that odd feeling that something was missing...

2. As a power user, I hated the new XP / Vista dialog with the dog and the questions...  but based on this post I actually opened the dialog with a different purpose - To LOOK at it, rather than find something.  Normally when I am searching, I am too busy "in the moment" to go off task to find out why I hate this dialog.  But now, in taking the time to look, I found the Change Preferences, and now have managed to set it up with the more classic look and feel.

Hopefully I have learned something - to take a bit of time to familiarize myself with the newer layouts - instead of trying to teach this old dog new tricks while I am trying to accomplish a different task.

I thought it was Google/DOJ/EU related?  SP1 also wiped out the "Search" context menu entry on folders (but you can get it back: http://msmvps.com/blogs/bradley/archive/2008/02/17/have-sp1-want-your-search-back.aspx).

I'm also curious for the rationale behind the address taskbar deskband being "anticompetitive" (http://support.microsoft.com/kb/951448).  I'm glad they haven't taken that away from Vista yet.

No dowpdown history (need to run regedit or cmd? type it each time!) and slower than Run. Not sure about other people, but that's one thing I'm using less on vista now.

Gabest: I use the run dialog all the time in Vista, still, but that's mostly because I always hit Windows Key + R. However, if I'm running something that isn't in the path, like a standard application, I usually just type the name in to the search box.

My only gripe is that it doesn't weight recent usage (or at least, not correctly) so the 'So and So Application Help' shortcut comes up before the application itself most of the time, forcing me to navigate down instead of just hitting enter.

More interesting questions are:

1. "What happened to the guy who decided to put the poor dog to XP search box". Was he let go because of electronic animal abuse or is still creating more screwups for Microsoft?

2. Why new XP Search 4.0 is still CPU and memory hog? Raimond, please fire the guys a email to educate them about existense of FILE_FLAG_NO_BUFFERING (would make up for poor VM vs file cache memory allocation in XP), and SetThreadPriority/SetPriorityClass, which would give the OS its responsiveness back. Not everybody runs dual proc.

@Mark:

Yeah, that strikes me as a little odd too.  Why pick on the Address taskbar, when it just invokes URLs using the default browser anyway?  (It's not IE-specific -- at least not as far as I know.)

Although some things could do with a little more IE-specificity -- namely the Windows Update link in XP, which invariably opens in My Other Browser despite refusing to actually work without IE.  And since it instantly redirects to a "refusal to run" page, if I tell my other browser to open it in IE instead then I get the "refusal to run" page in IE.  Sigh.  (Things are a bit better under Vista, since it uses a dedicated program instead of just jumping to an URL.)

And if you certainly need the Search command, you can replace "Run" or "Help and Support" with search using a hack.

http://www.winhelponline.com/blog/restore-the-start-menu-search-link-in-vista-service-pack-1/

@Doug - There is no dog on Vista.

@Alex - The indexer developers are very, very aware of every performance / citizenship optimization, and have very carefully chosen which ones make sense.  Setting process or thread priorities is trickier than you might think.  Just look up "priority inversion" on Wikipedia.

If you're having performance problems with WS4 on XP, you're most likely hitting a compatibility problem.

Memory management is also very, very well tuned in Windows Search.  Looking at the commit size isn't going to be useful because it includes memory-mapped files, and each of the different Search processes will likely show more memory use than they really have because they share memory-mapped resources.  If you're seeing a high working set for Search you're likely hitting a bad filter / plug-in.

The dumbest thing with Search is the plugin support. Please remove it and implement a byte per byte comparation of the characters typed in instead. Plugins are stupid, noone understands why search misses content in files.

Indeed, a bad IFilter can wreak havoc - a while ago (on XP, with the old-school indexing service) I had installed the pdf IFilter and apparently it had a hidden window that didn't pump messages because DDE was totally messed up.

Of course, the manifestation was simply that explorer would hang for a minute when starting the PC, links would not launch from Outlook, etc etc (remind me why these things still use DDE?)

Fortunately with the help of a program posted in the comments here which enumerated all windows that were hung, I figured it out, and thus another case was solved that manifested itself as Windows being hopelessly broken when it was actually a 3rd party (some people pay attention, Raymond).  Of course, the question remains why DDE is still in active use (obviously I know why it's still /supported/) but alas.

Yeah, "idiot feature," why don't you open up a pdf in notepad and look at what's there to pull out.  You're hopelessly naive to think that every file has useful character information in it.

Windows Search always seemed like an untested product to me.  If you put "hello" in a file called "welcome" in c:\, Windows Search does not find it.  Reading this blog I learned it only searches files with the specific extensions.

Can Windows search index files with no extension?  Or with an unknown extension?  Like files called hardware.computername.

Brandon,

Thanks for paying attention.

Windows XP has the following annoying flaw. As soon as a lot of _cached_ I/O starts happening, it starts stealing pages from applications, to use them for file cache. For some reason it doesn't just steal pages least recently used. It's very likely steal a page just paged-in for a memory-mapped EXE or DLL. This causes excessive pagefaulting for other applications, even though the're just trying to stay in their message loop. It's hard faults, that cause disk read, which is illustrated by continuous disk thrashing and the third application sluggishness. Using FILE_FLAG_NO_BUFFERINGalleviates such bad behavior. Reasonably large read sizes (for example, 1 MB) also help to redice thrashing if another disk-intensive application runs.

Regarding priority inversion, it's not of a big concern for background non-time-critical application. If you're concerned about cross-process inversion in the kernel, KMUTEX has protection against invertion - it will boost owning thread priority to the highest of waiting thread.

I'd rather had the indexer running slower, than the rest of my desktop brought to standstill. The less it affects other applications, the better.

Alexander Grigoriev:  EXACTLY!  I hate how XP (&2000) have out-of-control file caching that "displaces" pages from applications without bound.  I never understood how somebody could think that was a good idea.  Down with over-eager file caching!

Adding to a priority inversion concern: If you suspect that the filesystem is using fast mutexes internally (that don't protect against priority inversion), just temporarily raise thread priority before calling CreateFile/CloseHandle. I would think, though, that NTFS.SYS developers knew better to protect against starvation caused by inversion.

All other concerns about priority inversion don't apply to such an application like the indexing service. Just give it lower priority and everybody will be happy. It's not the most important in the whole system; nobody sits at the screen, waiting for it to finish.

This is too hidden.

I just showed this to a couple of co-workers.

How were we suppose to guess that we could search email with Windows+F ?  How else could we get to that Windows+F window?

I use WinKey + F all the time.

I have had to configure the start menu to only search programs. I simply don't like having my documents there. For programs it's great.

It gets too crowded.

I must admit, I never noticed that search button, so I can't have used it much.

[Type your search into the search box and click "Show all results." Windows+F is just there for backward compatibility. -Raymond]

And if you have stopped the start menu from searching everywhere, it says "Search everywhere" instead.

Man, I like Vista. How anyone can seriously compare it to Ubuntu is beyond me. It's like a BMW and a kit-car.

Yeah, you can type in the Start menu to start a search.  

But what if you want to search mails, or one of the other subset. You need to start a full file search to get the Search window, and then start the search again with the scope you want.

It's very weird UI design.  IMHO the search in the start menu should just search the start menu.  And there should be an entry to get to that Search window directly without doing a 'fake search' to get it.

Funny request, that. "Implement a byte per byte comparation of the characters." Not character per character? Because I would very much like "ü" to match "ü", even though I entered one in Explorer and the other is in a textfile.

@ IFilter - Microsoft should have learned by now to use separate processes, especially when indexing. Explorer should not hang on that kind of bad plugins. The overhead of an extra process is not that bad.

Michiel: "IFilter - Microsoft should have learned by now to use separate processes" -

that's what SearchFilterHost.exe process is for. It also runs with restricted privileges.