[desc]

Can't say I ran into this particular bug, but I tend not to trust the search on Windows much anyway. I myself have implemented better text/prefix matching and ranking using a very simple SQLite database schema, on a far larger dataset than 'the local machine', yet Microsoft repeatedly fail at a task which should succumb easily even to brute-force approaches.

They don't get to claim that it's a harder problem than indexing a hard disk without first explaining why they think they should retain the use of their fingers for continuing to send search terms over a network after I, as the owner of the hardware and 'owner' of the OS instance have made a concerted effort to turn that shit off.

[jodrellblank]

Jeffrey Snover[1] likes to say that "Microsoft is incapable of sustained error", yet they've been incapable of building a good search for at least 15-20 years that I've experienced. Bing search is no competitor to Google, Explorer filesystem search is slow and untrustworthy, the search which integrates desktops to Windows server indexing of fileshares is slow and untrustworthy, on-premises SharePoint search has never worked well for finding documents for me, Start Menu search is the worst at matching plain text strings in short names year after year, Windows version after Windows version, local Outlook Search wasn't great, Outlook search backed by Exchange isn't great, and it goes easily back to Joel on Software's blog post[2] of 2004 where he says

> Just do me a favor and search the damned hard drive, quickly, for the string I typed, using full-text indexes and other technologies that were boring in 1973.

That's still what I want, and still what they don't do.

[1] PowerShell originator, now "Chief Architect for the Azure Infrastructure and Management Group" at Microsoft.

[2] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

[jiggawatts]

Here's the thing: I've built, back in 2005, a full-text search for 60 GB of small-text data that would typically return results in under 15ms. This was using 100% Microsoft-native technology, like C# and SQL.

How much data does the Start Menu search have to index, total? A few 100KB? Something like that. This is assuming a fresh install, no documents, no third party apps.

A modern CPU can simply brute force through that amount of data and perform nearly arbitrary subtext matching, without any fancy indexing techniques, in something like a handful of microseconds. Even in an absolute worst-case of cross-process pointer chasing out into uncached main memory, you're talking a few tens of milliseconds, max.

Yet, a fresh install of any version of Windows, including Server editions, simply flat out fails to find control panel items or shortcuts even if their names are typed exactly. Many hours later it'll find some of them, not necessarily all. Days later, perhaps it'll reach a 100% match, but that's certainly not guaranteed.

For me, often having to use freshly installed Windows VMs, I see a nearly 100% failure rate for this component.

It's just absurd that this passed QA.

[JeffreySnover]

The second half of the quote is, “but sometimes it takes us a couple decades to get right”. :-)

Seriously though, have you checked out the search in O365? It is starting to get really good and wait till you see how this progresses in the next couple of years.

I think I’ll be proven right. :-)