Windows 7 Search-Run

Back in the days when Windows had a project name of “Longhorn”, one of its potential features was a relational database driving the file system, i.e. SQL Server running the command line or “find” window. The complete implementation was tossed out to get Visaster out to manufacturing sooner. Visaster ended up with a neutered search-run window and Windows 7 RC continues it. So at least in Texas, the Windows “Longhorn” refers to the cheese, not the legendary breed of cattle.

Although combining search with command-line execution of a program on fast and powerful hardware might be more time-efficient for the user on high performance hardware, its an overall performance killer on slower or less capable hardware. The performance advantage to users is minimal even on high performance hardware. Considering that the search to index the programs and files has to be done on some sort of schedule to maintain index relevance, the performance hit is on-going and directly related to the index schedule and the power profile in use.

Assuming the user is intelligent enough to only record new files on an alternate drive removed from the index service; that the \User profiles folder for all users has been moved to the same non-indexed alternate drive; that writes to the boot/system C drive are kept to a minimum; otherwise indexes are going to be running constantly. This would have a tendency to drain laptop and net-book batteries for very little gain.

Only desktop installation tests have been performed so far. The best performance enhancement for a Windows 7 desktop system with a load of applications is to leave it turned on at night. The Index Service seems to need the extra time to get caught-up if the system is in constant use. Hopefully the power profiles for laptop operation are very aggressive and limits index behavior rigorously.

Another issue is that using the search-run window to run programs may not make it obvious to the user using Visaster or Windows 7 where the executable is actually located or what version of the program ends up running. Obviously this is not a problem when the executable is unique with a unique filename. If a developer is working on a program and wants to run it outside of the IDE, the “search” function will find multiple versions of the program and offer up and run the last version. That might not be the desired version. Some earlier version or in a different fork might be the desired target. The developer ends up either typing the entire path or uses Explorer to start the program.

It is possible in Windows 7 to execute unknowingly a program residing on a remote drive share. Assuming that you have log-on and execute privileges on the share, it doesn't matter where the program is stored. Outside of experiencing a possible slow-down while it is copied to the system RAM, and then is run, the user may not be aware that a remote program is running. However this is an especially annoying problem when drive-mapping is done as part of group policy. Unless the user has the rights to delete a mapped drive, the index service will find the executable on the mapped drive sometimes in preference to a local copy.

This is not really anything new except that in XP Pro and previous Windows versions the path had to be explicit either through an Explorer window with a left click or a fully delineated path at a command prompt.

Using the Search window as the Run applet also ends up dropping performance due to the number of support programs that need to be running. Obviously the Index Service has to be running. On older hardware, running the Index service is a sure way to provoke users into complaining about their systems. This has been recently compounded by Windows Updates pushing Windows Search version 4.0.

Application Compatibility services, and/or “side-by-side” assemblies are needed to keep the DLL-hell from returning. Depending on the application mix running on the computer while running in “side-by-side” mode it is possible to have 4 or 5 of the “same” DLL loaded. The obvious differences between the libraries only being version number or release date.

As an illustration, Windows programmers need to get out of the habit of naming the installation program for their application setup.exe. A search-run for setup.exe is practically useless on any Visaster or Windows 7 computer with more than 2 or 3 applications on it.

DotNet applications seem to get through the version chaos fairly well. One VS2005 application had to be re-compiled while running Windows 7 to fix a subtle glitch in one program. However anything using older DLL's or ActiveX components end up getting a “wrapper” if its anything faintly “legacy”. That would include dotNet 2.0 and earlier and anything done in earlier versions of Visual Studio. This wrapper behavior seems to be started up even if the appropriate runtime is installed on the system.

If your company has a legacy Windows application that is a profit-maker for your company, convert it to dotNet 3.5 as soon as possible. Considering the issues Windows Updates had with the various dotNet version 1.1 run-times, dotNet 2.0 run-time support may have similar events in the future.