I can only imagine this is taking advantage of the fact that Windows task scheduling gives higher priority to threads which are currently receiving user interaction.
In certain cases, doing this would allow the process to handle returning data faster, especially if it was having to communicate with Excel a great deal and there was a lot of context-switching/waiting between the processes and you wanted to favor Excel's processing of the returned data over a background task with high CPU usage.
Perhaps the problem is that pieces of the Excel side were timing-out and causing all the returned data to be lost.
I think that's the opposite scenario.
In what you linked, what happens is, you hold the mouse down on the window which prevents it from refreshing, which makes the actual task go faster (since its no longer trying to refresh the progress bar)
Our OS Prof. told us that some programs for Windows NT like compilers display progress bars to look more interactive (to the kernel, not the User) and to generate I/O completion events to get stuff done faster.
Gosh, I used to have a couple of games which would hang forever unless I wiggled the mouse a bunch at critical points, I wonder if that was the same principle? I had no idea task scheduler took interaction into account.
When we were developing a VB product at a previous company, we ended up throwing in the towel and calling the LockWindowUpdate function to improve our applications performance so that it was acceptable.
>LockWindowUpdate Function
The LockWindowUpdate function disables or enables drawing in the specified window. Only one window can be locked at a time.
This isn't just a Microsoft thing. I've seen the same behaviour in OS X when running huge Applescript jobs. The entire script would excecute consistently faster if I sat there and wiggled the mouse around.
I've never really considered why that may be the case. This makes a lot of sense.
I find interesting, here we see the structure in RAM becoming almost as complex as the physical world (Or at least very dam complex.). This starts to make the heap react in way similiar to those in the physical world. We get a "mechanic" solution to a digital problem.
Don't forget the warning at the top, "This information is preliminary and has not been confirmed or tested by Microsoft."
So while it's funny to say, "haha, isn't this typical of stupid M$," they apparently didn't produce this advice. More likely, some support tech recorded the mouse bit from the customer just to be complete, and 7 years later it still hasn't been verified...
"NOTE: Depending on your query, it may take several minutes to return the results of your query to the worksheet."
First thought: this has got to be a parody.
Second thought: Oh Cthulhu, it is for real.
Third thought: Just by mentioning this link almost anywhere, it'll be excoriated as "just another baseless attack on Microsoft (which I, being a technologically fair and balanced soul, will admit to having less than stellar practices)"
You still can't name a file or folder "con" (even in Win7) because it's a reserved word used for keyboard input on the command line. When Windows 9x was popular, you could bluescreen any machine on a local network by trying to access the share \\machinename\con\con, which was great if you lived in a dorm :)
You can do it with Cygwin though, and Explorer will still have trouble dealing with it after it's been created. You can also create files with a trailing period or leading/trailing space, which usually isn't allowed.
I just verified that the =rand(200,99) one does still exist (in Word 2008 on Mac anyway). As brunov said, this looks more like an easter egg than a bug though.
I can verify that stuff like this works. I once wrote a Ruby script that imported drawings into Visio from XML. It took a while as you sat there and watched the boxes and lines move around and adjust themselves, but you could speed it up by a factor of two just by grabbing and holding the scrollbar with the mouse.
Yeah, press ctrl-alt-esc to bring up the Task Manager. Go to the Processes tab, then right-click on a process. Choose a priority form the Set Priority submenu. Options are Realtime, High, Above Normal, Normal (default), Below Normal, and Low.
A similar-looking symptom I've seen with IE6 is that links won't "take" if I click and then move the cursor away. IE will display a message in the status bar when I click, but for some reason it is noticeably less likely to actually load the page if I don't keep the mouse on the link. This was particularly bad on dialup.
In certain cases, doing this would allow the process to handle returning data faster, especially if it was having to communicate with Excel a great deal and there was a lot of context-switching/waiting between the processes and you wanted to favor Excel's processing of the returned data over a background task with high CPU usage.
Perhaps the problem is that pieces of the Excel side were timing-out and causing all the returned data to be lost.
To read more about UI thread boosting in Windows, this article is a pretty good one: http://www.sriramkrishnan.com/blog/2006/08/tale-of-two-sched...