here's what i can tell you about the fix to shortcuts,
there is a windows API command called ShellExecute (google will find you lots of pages).
it can be used to start programs from within other programs, and can be used to tell windows to open an arbitrary file,
in which case windows is supposed to go looking for the program that handles that type of file and open it.
so basically ShellExecute does it all.
by default, F&R was invoking ShellExecute on the files selected for launching, whether they were exe files, other documents, or shortcuts to exes or documents (ie .link files).
apparently there were 2 problems with this.
the first was this policy i didnt know about which says the ShellExecute essentially hangs while waiting for the parent application of a document to start up and be ready to take input. this was causing F&R robot to just sit on screen waiting and helpless.
the second problem was the fact that it seems on some computers, when ShellExecute is called with a ".lnk" file (shortcut file), it refuses to launch it. i'm still not sure why certain machines do that and others don't. it sounds like it could be a security issue but i've never heard it discussed before.
the solution to these problems were, first, to manually decode the shortcut file inside the program to recover the file being pointed to, whether it be an exe or a document. then the second was to write a tiny like 1 line helper windows utility that basically just takes the name of a document on the command line, and calls ShellExecute on it to have windows open the appropriate program. By using a separate helper to call ShellExecute, and by invoking that helper with a *different* kind of spawning api call (CreateProcess) i was able to hand off the "waiting for ShellExecute" responsibilities to a separate process and thereby let F&R get back to its job of minimizing or exiting after a launch.
probably more info than you wanted to know, but there it is
hehehe, well as i was telling someone before,
find&run is not really a competition for the desktop search engines which can actually look INSIDE files, find and run just works on file names, and because it actually searches for files on demand, its probably not ideal for searching entire hard drives over and over; in such cases its better to have a large database-driven constantly updating indexing system like one of those desktop search things.
