"Windows Search" automation by COM?

[orbs]

problem:

DOS find & findstr are useless for non-text files (like MS Office files, etc.), and unreliable when it comes to non-English characters. this seems to be the case also in PowerShell (Select-String cmdlet).

now, "Windows Search" handles it all very well, even without the indexing service.

 

even greater problem:

the term "Windows Search" is not search-friendly... you get every result in the web, except anything related to "Windows Search".

 

solution?

so, how scary is it to try and control "Windows Search" by COM? Microsoft has an SDK for it. but i'm not that much of an expert.

note:

if it's any easier, using the index is not a must. actually i prefer to ignore the index, because the search location is likely to not be indexed.

[water]

Can you provide a link to the MS SDK for Windows Search?

[orbs]

Can you provide a link to the MS SDK for Windows Search?

 

http://www.microsoft.com/en-us/download/details.aspx?id=7388

[water]

I'm not sure but it look like MS only supports managed code. If you find an example for Visual Basic then it should be easy to convert to AutoIt.

I haven't been lucky so far.

[Starg]

$oShell = ObjCreate("shell.application")
$oShell.FindFiles

... but what should we do next?

[orbs]

$oShell = ObjCreate("shell.application")
$oShell.FindFiles

... but what should we do next?

 

 

that is equivalent to

Send('#f')

which is not what we are looking for. although the GUI can be automated, but that is not robust, and will not work for scheduled tasks, server scripting, remote calls, or anything that has no GUI.

[orbs]

I'm not sure but it look like MS only supports managed code. If you find an example for Visual Basic then it should be easy to convert to AutoIt.

I haven't been lucky so far.

 

i did not find VB examples too, as far as i understand, Windows Search programming is .NET based.

maybe this will be helpful: http://msdn.microsoft.com/en-us/library/bb266516%28VS.85%29.aspx

[orbs]

i took an extremely long shot in the direction of reading the contents of the files and trying to get a notion on how Windows Search is reading the text in files, to see if this can be done by AutoIt.

.

i took as examples, the new Office XML format (2007+) and the old compound format (97-2003).

for the compound file, you can ignore the structure and extract the text as unicode, but the results will include text from all fields, not just the main text of the document.

the XML is actually a zip file, containing simple text files in XML structure. ref:

http://www.forensicswiki.org/wiki/Word_Document_(DOCX)

so it's quite simple for AutoIt to unzip and search, but that will be slow, and the results will be much much more than the text.

and that's just two examples, there are many more file types, with different structure and formats. but Windows Search seems capable of dealing with any file, regardless of type.

it does not seem logical (to me) that it simply have a huge set of algorithms, from which it can select the appropriate one for any file it encounters depending of the file type. that would mean that (ideally) Windows Search is aware of all existing file structures and formats,

the other option is some kind of a generic algorithm (or a few of them) that gives good enough results for whatever file it encounters.

this was a bit of under-the-hood research, but now, closing the hood and trying to start the engine, i see that the only code examples that are available (on the web and in the SDK) are only handling the index db, not the search function. i did not encounter any example, any language, that instructs Windows Search to go and search a location.

but that must exist, right?