There are single-threaded apartments and multi-threaded apartments. Well, first there were only single-threaded apartments. No wait, let’s try that again.<\/p>\n
First, applications had only one thread. Remember, 16-bit Windows didn’t have threads. Each process had one of what we today call a thread, end of story. Compatibility with this ancient model still exists today, thanks to the dreaded “main” threading model<\/a>. The less said about that threading model the better.<\/p>\n OLE was developed back in the 16-bit days, so it used window messages to pass information between processes, there being no other inter-process communication mechanism available. When you initialized OLE, it created a secret Meanwhile, the OLE team realized that there were really two parts to what they were doing. There was the low-level object and interface management stuff ( Breaking the low-level and high-level stuff apart allowed the low-level stuff to be used by non-GUI programs, which for quite some time were eyeing that object management functionality with some jealousy. As a result, COM grew two personalities, one focused on the GUI customers and another focused on the non-GUI customers. For the non-GUI customers, additional functionality such as multi-threaded apartments were added, and since the customers didn’t do GUI stuff, multi-threaded apartments weren’t burdened by the GUI rules. They didn’t post messages to communicate with each other; they used kernel objects and Well, yes, everybody wins, but you have to know what side your bread is buttered on. If you initialize a GUI thread as a multi-threaded apartment, you have violated the assumptions under which multi-threaded apartments were invented! Multi-threaded apartments assume that they are not running on GUI threads since they don’t pump messages; they just use That’s why COM objects involved with user interface programming nearly always require a single-threaded apartment<\/a> and why Multi-threaded apartments do not pump messages.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-22603","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" Multi-threaded apartments do not pump messages.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/22603","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=22603"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/22603\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=22603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=22603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=22603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}OleMainThreadWnd<\/code> window, and those secret windows were used to communicate between processes (and in Win32, threads). As we learned some time ago, window handles have thread affinity<\/a>, which means that these communication windows have thread affinity, which means that OLE has thread affinity. When you made a call to an object that belonged to another apartment, OLE posted a message to the owner thread’s secret OleMainThreadWnd<\/code> window to tell it what needs to be done, and then it went into a private message loop waiting for the owner thread to do the work and post the results back.<\/p>\nIUnknown<\/code>, CoMarshalInterThreadInterfaceInStream<\/code>) and the high-level “object linking and embedding” stuff (IOleWindow<\/code>, IOleDocument<\/code>) that was the impetus for the OLE effort in the first place. The low-level stuff got broken out into a functional layer known as COM; the high-level stuff kept the name OLE.<\/p>\nWaitForSingleObject<\/code>. Everybody wins, right?<\/p>\nWaitForSingleObject<\/code>. This not only clogs up broadcasts, but it can also deadlock your program. The thread that owns the object might try to send a message to your thread, but your thread can’t receive the message since it isn’t pumping messages.<\/p>\nOleInitialize<\/code> initializes a single-threaded apartment<\/a>. Because multi-threaded apartments were designed on the assumption that there was no user interface. Once you’re doing user interface work, you have to use a single-threaded apartment<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"