<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>fractaled</author><text>I think the core of COM is sound (pure interfaces, QI, refcounting, IDL).&lt;p&gt;I think the ugliness is due to threading issues and being welded on to Win32 message pumps. If you have a dedicated COM thread&amp;#x2F;pool you&amp;#x27;ll mostly be fine (security stuff can still get complicated). But on the other hand if you start doing COM things on a thread you own where you share control of the message pumping, you open yourself to a world of mental anguish.</text><parent_chain><item><author>overgard</author><text>As much as I make fun of java developers for over complicated solutions, I&amp;#x27;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.&lt;p&gt;I actually like windows as a user, but I&amp;#x27;m amazed that it won as much developer mindshare as it did considering how much the win32 api sucks. It&amp;#x27;s brutal.</text></item><item><author>pea</author><text>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 (&lt;a href=&quot;http://blogs.msdn.com/b/andreww/archive/2008/11/19/implementing-imessagefilter-in-an-office-add-in.aspx?Redirected=true&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;blogs.msdn.com&amp;#x2F;b&amp;#x2F;andreww&amp;#x2F;archive&amp;#x2F;2008&amp;#x2F;11&amp;#x2F;19&amp;#x2F;implement...&lt;/a&gt;) which unfortunately doesn&amp;#x27;t work. It&amp;#x27;s completely nuts how bad the object model is.</text></item><item><author>asveikau</author><text>The rule of thumb as I always heard it is that a window is &amp;quot;owned&amp;quot; by the thread that created it. You can send and post messages from a different thread, but do much else and you&amp;#x27;re asking for trouble. (And Send instead of Post is often problematic since it will block until the target thread processes it.)&lt;p&gt;Draining the message queue from a thread that doesn&amp;#x27;t own it makes absolutely no sense to me ... Does that actually work? Wouldn&amp;#x27;t you see the messages on the original thread&amp;#x27;s pump too? I thought the way it worked is each thread with ui objects has a queue, and SendMessage et al. will insert into the owning thread&amp;#x27;s queue. It took me a while to parse what you are saying, did you pass the hwnd into GetMessage from the other thread and that somehow convinced it to peek at another thread&amp;#x27;s queue?</text></item><item><author>zbowling</author><text>I had this bug once about 10ish years ago when I was still a windows dev. Creating a 2nd window on a thread with a window already but then pumping it&amp;#x27;s main loop on a background thread can cause this. If you do that the loops get hooked to each other regardless of the thread pumping it. The child window has to wait until the parent window forwards the event for the second thread to pop it off. A mouse move will send a WM event and keep the child windows loop on the other thread spinning. My WM_TIMER on the child window was stuck as well.&lt;p&gt;It happened to me because I had a hidden window on the background thread to get WM events for USB disconnect and reconnect messages from the system. The bug report was funny. &amp;quot;Connecting USB data collection probe doesn&amp;#x27;t work unless the user moves the mouse after connecting.&amp;quot; and the follow up bug &amp;quot;Data collection only works when moving the mouse.&amp;quot;</text></item></parent_chain></comment><story><title>If you move your mouse continually the query may not fail. Do not stop moving</title><url>http://support.microsoft.com/kb/168702</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>asveikau</author><text>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.)</text><parent_chain><item><author>overgard</author><text>As much as I make fun of java developers for over complicated solutions, I&amp;#x27;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.&lt;p&gt;I actually like windows as a user, but I&amp;#x27;m amazed that it won as much developer mindshare as it did considering how much the win32 api sucks. It&amp;#x27;s brutal.</text></item><item><author>pea</author><text>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 (&lt;a href=&quot;http://blogs.msdn.com/b/andreww/archive/2008/11/19/implementing-imessagefilter-in-an-office-add-in.aspx?Redirected=true&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;blogs.msdn.com&amp;#x2F;b&amp;#x2F;andreww&amp;#x2F;archive&amp;#x2F;2008&amp;#x2F;11&amp;#x2F;19&amp;#x2F;implement...&lt;/a&gt;) which unfortunately doesn&amp;#x27;t work. It&amp;#x27;s completely nuts how bad the object model is.</text></item><item><author>asveikau</author><text>The rule of thumb as I always heard it is that a window is &amp;quot;owned&amp;quot; by the thread that created it. You can send and post messages from a different thread, but do much else and you&amp;#x27;re asking for trouble. (And Send instead of Post is often problematic since it will block until the target thread processes it.)&lt;p&gt;Draining the message queue from a thread that doesn&amp;#x27;t own it makes absolutely no sense to me ... Does that actually work? Wouldn&amp;#x27;t you see the messages on the original thread&amp;#x27;s pump too? I thought the way it worked is each thread with ui objects has a queue, and SendMessage et al. will insert into the owning thread&amp;#x27;s queue. It took me a while to parse what you are saying, did you pass the hwnd into GetMessage from the other thread and that somehow convinced it to peek at another thread&amp;#x27;s queue?</text></item><item><author>zbowling</author><text>I had this bug once about 10ish years ago when I was still a windows dev. Creating a 2nd window on a thread with a window already but then pumping it&amp;#x27;s main loop on a background thread can cause this. If you do that the loops get hooked to each other regardless of the thread pumping it. The child window has to wait until the parent window forwards the event for the second thread to pop it off. A mouse move will send a WM event and keep the child windows loop on the other thread spinning. My WM_TIMER on the child window was stuck as well.&lt;p&gt;It happened to me because I had a hidden window on the background thread to get WM events for USB disconnect and reconnect messages from the system. The bug report was funny. &amp;quot;Connecting USB data collection probe doesn&amp;#x27;t work unless the user moves the mouse after connecting.&amp;quot; and the follow up bug &amp;quot;Data collection only works when moving the mouse.&amp;quot;</text></item></parent_chain></comment><story><title>If you move your mouse continually the query may not fail. Do not stop moving</title><url>http://support.microsoft.com/kb/168702</url></story>