Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

support.microsoft.com

Post reply on HN
Print view View original

101–110 of 168 posts

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

#101

Post by lafar6502 »

overgard wrote: post #98
pea wrote: post #95

Earlier quoted context omitted.

COM hates MTA threading, most of the Office object model actually insists on STA single-threads sitting in the main UI thread to even work (i.e. you cannot use BackgroundWorker() )! Some guy @ MS even released this byzantine code to deal with the situation ( http://blogs.msdn.com/b/andreww/archive/2008/11/19/implement... ) which unfortunately doesn't work. It's completely nuts how bad the object model is.

As much as I make fun of java developers for over complicated solutions, I've never quite seen anything as over-engineered and byzantine as COM. I remember at my last job we had legacy COM objects that inherited from about 5-7 different templated objects, and that was... normal. COM is the worst. I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much t…

But COM has been adopted by Linux world too, and renamed to Bonobo. In fact, if you throw away all VB-specific stuff, COM and its C++ implementation is a great programming exercise and is imho quite elegant.

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

#102

Post by dmbortz »

Many moons ago I had a dual Pentium Pro and had installed Slackware with one of the early linux kernels to include SMP. And, when clicking on a link in mozilla (or it might have been netscape back then), the new website would only be rendered after I jiggled the mouse. I just figured it was some race condition with the SMP kernel that got broken when the PS2 interrupt fired. It went away with some kernel upgrade, but I still jiggle the mouse every now and then in the hopes a page will render faster...

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

#103

Post by lafar6502 »

lisper wrote: post #92
asveikau wrote: post #74

Earlier quoted context omitted.

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 hel…

I am familiar with the design of message queues, though not specifically with the design of Windows message pumps. > If you violate the run loop's threading requirements it's not totally inconceivable that a mouse event could affect behavior. That's true. But the possibility remains that the design of Windows message queues is so byzantine and imposes so many arcane requirements on the developer that it is easy to mi…

You overlooked the fact that programming model of windowed/GUI applications is quite complex and very sensitive to non-cooperative code - a thread that frequently blocks for 100 ms can cause very unpleasant hiccup. Introduction of OLE/COM interprocess communication mechanism made things worse as one unresponsive application could block other programs and halt their message loops. But it was quite efficient and you didn't have to spin up multiple threads to have multitasking in your application.

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

#104

Post by frik »

overgard wrote: post #98
pea wrote: post #95

Earlier quoted context omitted.

COM hates MTA threading, most of the Office object model actually insists on STA single-threads sitting in the main UI thread to even work (i.e. you cannot use BackgroundWorker() )! Some guy @ MS even released this byzantine code to deal with the situation ( http://blogs.msdn.com/b/andreww/archive/2008/11/19/implement... ) which unfortunately doesn't work. It's completely nuts how bad the object model is.

As much as I make fun of java developers for over complicated solutions, I've never quite seen anything as over-engineered and byzantine as COM. I remember at my last job we had legacy COM objects that inherited from about 5-7 different templated objects, and that was... normal. COM is the worst. I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much t…

Similar to COM, are (beside OLE, DCOM, ActiveX) Gnome's "Bonobo" (component model) [1], KDE's KParts, Mozilla's XPCOM and CORBA.

Apple choose KHTML over Gecko for it's Webkit fork [2] because of the various cons of such component models.

[1] Bonobo is officially deprecated: http://en.wikipedia.org/wiki/Bonobo_(component_model)

[2] http://en.wikipedia.org/wiki/XPCOM

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

#105

Post by Shog9 »

Freestyler_3 wrote: post #15

How does this work? What makes mouse movement relevant to this... this is computers, not magic.

The exact cause would be a question for (old, probably retired) members of the Excel team at MS, but bugs like this were fairly common when working with Windows apps that mixed interprocess communication with UI updates.

Raymond Chen has a great example of a similar bug here: http://blogs.msdn.com/b/oldnewthing/archive/2005/02/17/37530...

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

#106

Post by Nilzor »

ryen wrote: post #90
kyberias wrote: post #45

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.

Whats crazy is Microsoft believing this is an acceptable solution rather than fixing/patching it.

They don't. It's listed as a workaround. The fix is Excel 2000.

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

#107

Post by frik »

throwawaykf03 wrote: post #96
crazygringo wrote: post #67

Earlier quoted context omitted.

In your experience, is OSX or Linux graphical software any better? Genuinely curious. I feel like interface freezes happen on all major platforms, and always assumed it had more to do with the applications than with the platforms. I mean, writing interfaces that never block is a lot more work. But I don't have a lot of cross-platform experience to know if some platforms make it easier than others.

Not in my experience. I use IntelliJ IDEA (and previously used Eclipse) on OS X and Linux on a daily basis. Anytime they start indexing or re-indexing a huge code base in a "background" thread, they end up locking the machine to varying extents. Linux is not as bad, as it only tends to lock up instances of the offending application... But that maybe because the Linux PC is a beefy workstation. OS X is on a much less…

I noticed that too with IntelliJ IDEA on Windows 7 :(

IntelliJ IDEA should run such background threads with lower priority! All common OS support that, and also Java supports this: http://stackoverflow.com/questions/1617963/setting-priority-...

Can someone file a bug for it?

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

#108

Post by yuhong »

frik wrote: 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…

Office 97 did not have italic title bars. Office 95 did. And I am not sure if Excel ever used fibers.

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

#109

Post by asveikau »

overgard wrote: post #98
pea wrote: post #95

Earlier quoted context omitted.

COM hates MTA threading, most of the Office object model actually insists on STA single-threads sitting in the main UI thread to even work (i.e. you cannot use BackgroundWorker() )! Some guy @ MS even released this byzantine code to deal with the situation ( http://blogs.msdn.com/b/andreww/archive/2008/11/19/implement... ) which unfortunately doesn't work. It's completely nuts how bad the object model is.

As much as I make fun of java developers for over complicated solutions, I've never quite seen anything as over-engineered and byzantine as COM. I remember at my last job we had legacy COM objects that inherited from about 5-7 different templated objects, and that was... normal. COM is the worst. I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much t…

I actually like COM. Sure there are historical accidents like STA. But if you are free of that legacy and keep it simple there are some nice features: reference counting, QueryInterface, consistent error codes across components, abstraction away from linking, not having to worry about which allocator an object uses. (Though last one is only important on Windows since different DLLs can end up using different heaps.)

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

#110

Post by lcrs »

crazygringo wrote: post #67
foobarian wrote: post #14

Earlier quoted context omitted.

I'm always fascinated by how tightly bound various software is with UI code in Windows. It's the equivalent of random shell scripts having Xlib or Gnome dependencies just to show a progress meter. I guess if it's an event loop thing one could also alternate 'z' and 'x' as fast as possible :-)

In your experience, is OSX or Linux graphical software any better? Genuinely curious. I feel like interface freezes happen on all major platforms, and always assumed it had more to do with the applications than with the platforms. I mean, writing interfaces that never block is a lot more work. But I don't have a lot of cross-platform experience to know if some platforms make it easier than others.

I recently came across similar behaviour in Linux - if you are waiting in XNextEvent on one thread and you call glXSwapBuffers on another, it never returns. If you move the mouse, XNextEvent returns with a MotionNotify event and glXSwapBuffers can grab some internal X11 lock and complete. It then gets stuck on the next frame. The result is that you have to keep moving the mouse or nothing is drawn.

X11 is supposed to be multithreaded enough to allow this and it worked fine on older versions of Xlib, before the libxcb transition.

Fixed by using select() in the event loop for the curious: https://github.com/lcrs/6ilk/commit/d5c39abde09e0467a8a4d17d...

Post reply on HN