Live data from Hacker News

If you move your mouse continually the query may not fail. Do not stop moving

support.microsoft.com

71–80 of 168 posts

Re: If you move your mouse continually the query may not fail. Do not stop moving

#71

This is a 11 year old knowledge base article for a bug in a product (Excel 97) that saw the light in 1997, that is 17 years ago. Yes, the second workaround is kind of hilarious, but let's not draw too many far-fetching conclusions from it. I believe many of us have seen crazier bugs.

This is by far craziest I've seen: "Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords" [1] [1] https://support.microsoft.com/kb/276304 Edit: typo

"Note that the number of required characters changes from 17,145 to 18,770 with the installation of SP1."

Wow. The story behind the extra 1625 characters must be good.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#72
post #59
post #53

Excel codebase is very old, most is still in recent versions. Excel 2010 still relies on WinAPI's Fibers [1] (lightweight threads). In recent years the idea got popular again with Lua's co-routines and GO's goroutines. So it is manually scheduled by the application, instead of relying on the OS. In 2014, there is a lot of code in Excel that dates back to Excel 3 (1990). Excel 2010 still relied on the outdated MDI con…

A few years ago I had to look at two Excel spreadsheets fullscreen side by side each open in their own window (two monitor setup) and this was...not easy!!! I eventually found some hack online to open up multiple instances of Excel at once. Still was bizarre that is a simple use.

Agreed that it's dumb behaviour, but it's not exactly a complicated hack - just run excel again (from start menu, from win+R, etc.) and it creates a new instance.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#73
post #59
post #53

Excel codebase is very old, most is still in recent versions. Excel 2010 still relies on WinAPI's Fibers [1] (lightweight threads). In recent years the idea got popular again with Lua's co-routines and GO's goroutines. So it is manually scheduled by the application, instead of relying on the OS. In 2014, there is a lot of code in Excel that dates back to Excel 3 (1990). Excel 2010 still relied on the outdated MDI con…

A few years ago I had to look at two Excel spreadsheets fullscreen side by side each open in their own window (two monitor setup) and this was...not easy!!! I eventually found some hack online to open up multiple instances of Excel at once. Still was bizarre that is a simple use.

I've had this trouble. I think the way around it is to open Excel itself multiple times, and then open your files from each instance of Excel. Or something like that, I'm not at work and don't have access to a Windows box ATM.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#74
post #69

Earlier quoted context omitted.

When I acquire a mutex inside my callback, it deadlocks. Microsoft wrote the calling function and the mutex implementation! Stupid Microsoft! Never mind that my callback violated the caller's threading model and that mutices introduce deadlocks when used incorrectly... They should fix the bug! Edit: I guess what I was trying to say is that this part needs a huge "citation needed": > was almost certainly built ... acc…

When was the last time you saw a mutext deadlock that could be worked around by moving the mouse? You're right that this discussion is light on details, but there is one relevant detail from which reasonable conclusions can be drawn: there is a workaround that involves moving the mouse around continuously. I can't think of any plausible scenario that could produce that behavior that does not involve some blatantly ho…

Elsewhere on this thread there is the suggestion that this could have to do with improper use of message pumps... Message pumps as a concept has equivalents in pretty much every UI framework I've looked at. (Some examples: run loops in Cocoa, g_main_loop in glib/Gtk+) If you violate the run loop's threading requirements it's not totally inconceivable that a mouse event could affect behavior.

I suggest it might be helpful to learn how the system works before you bash it.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#76
post #59
post #53

Excel codebase is very old, most is still in recent versions. Excel 2010 still relies on WinAPI's Fibers [1] (lightweight threads). In recent years the idea got popular again with Lua's co-routines and GO's goroutines. So it is manually scheduled by the application, instead of relying on the OS. In 2014, there is a lot of code in Excel that dates back to Excel 3 (1990). Excel 2010 still relied on the outdated MDI con…

A few years ago I had to look at two Excel spreadsheets fullscreen side by side each open in their own window (two monitor setup) and this was...not easy!!! I eventually found some hack online to open up multiple instances of Excel at once. Still was bizarre that is a simple use.

Thankfully this is no longer a problem in Excel 2013. (I believe it was still a problem in 2010.) The trade-off seems to be getting help/documentation is worse than ever. :(

Re: If you move your mouse continually the query may not fail. Do not stop moving

#77
Coworker had this at a dayjob recently - it involved a full screen Windows Remote Desktop run from a Citrix Remote Desktop, on a bad day run from another remote desktop. If you didn't move the mouse enough: the connection did indeed fail. The connection took 4-5 minutes anyway, so quite annoying.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#78

Earlier quoted context omitted.

>I believe many of us have seen crazier bugs. Might be, but is it a good sign for computer industry as a whole?

It's a sign we're having trouble in handling the complexity of our computer systems. Programming is mostly human-mind-bound now (and has been for many years); we need better tools and better abstractions.

I think we need to remove that complexity and find a simpler approach to things, not just "better" (more complex) tools to layer even more complexity on top of complex.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#79
post #72
post #59

Earlier quoted context omitted.

A few years ago I had to look at two Excel spreadsheets fullscreen side by side each open in their own window (two monitor setup) and this was...not easy!!! I eventually found some hack online to open up multiple instances of Excel at once. Still was bizarre that is a simple use.

Agreed that it's dumb behaviour, but it's not exactly a complicated hack - just run excel again (from start menu, from win+R, etc.) and it creates a new instance.

IIRC, older versions of Excel didn't work that way. The OP talks about "a few years ago", so it may have been with an older version that didn't work that way.

I have never been able to remember how Excel and Word for Windows handle multiple windows, as it changed in subtle ways (can you alt-tab between Excel documents. Between Word ones? Do documents appear in the taskbar, or windows, or just Excel?) between versions, as Word and Excel within an Office version do not appear to behave 100% the same, and I as I tended to encounter different versions, for example when helping a friend, or when using RDP to a different server (yes, we had servers with Office installed, and we didn't even use them for COM controls) at work.

Re: If you move your mouse continually the query may not fail. Do not stop moving

#80

Earlier quoted context omitted.

This is by far craziest I've seen: "Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords" [1] [1] https://support.microsoft.com/kb/276304 Edit: typo

"Note that the number of required characters changes from 17,145 to 18,770 with the installation of SP1." Wow. The story behind the extra 1625 characters must be good.

My $0.02 is on a dull explanation: the max length and #remembered parameters must be configurable and/or depend on the access method, and the printf-like call that creates the message string must have passed erroneous pointers pointing into some DLL. When that DLL changed, or when another DLL changed in size, causing the DLL to move, the pointers pointed to different, but still constant data.
Post reply on HN