This blog posting applies to Microsoft Office SharePoint Server 2007.

To modify SharePoint’s default search behaviors, it’s important to understand how the user interface elements for search work together to specify a query, execute a search and display the results.  The following high-level overview shows how searches are executed and displayed.

1.       The search box near the upper right of most pages is a control that accepts search keywords and scope from the user, and passes them to the search results page using a query string and HTTP GET.

2.       The search controls on the advanced search page accept keywords, scopes, languages and properties from the user, and passes them to the search results page using form variables and HTTP POST.

3.       The search results page calls an internal class with the inputs it receives, which builds the query, issues the query against the index and receives the results.  The internal class is implemented as a singleton: Microsoft.Office.Server.Search.WebControls.SearchResultHiddenObject

4.       Web parts on the search results page retrieve their portion of the results from the internal class to render their specialty: core results, high confidence results, page number, summary or statistics.

This architecture provides a very powerful and flexible way to configure different types of search results.  Unfortunately it is restricted to Keyword Syntax queries and is not possible to take advantage of the search engine's ability to use SQL Syntax queries, without development effort.  The development effort could be rather significant, because the internal class that performs the keyword syntax search is not available for custom class derivation.

For the form fields used from the Advanced Search page, here's a table of form fields that I came across.  It was constructed using reflector and reverse engineering of search and search result pages.