{"id":111873,"date":"2025-12-16T07:00:00","date_gmt":"2025-12-16T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111873"},"modified":"2025-12-16T10:59:08","modified_gmt":"2025-12-16T18:59:08","slug":"20251216-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20251216-00\/?p=111873","title":{"rendered":"Why is the Windows clipboard taking the scenic route when converting from CF_TEXT<\/CODE> to CF_OEM­TEXT<\/CODE>?"},"content":{"rendered":"

Our investigation of why the CF_OEM\u00adTEXT<\/code> clipboard format is not being created from CF_TEXT<\/code> via Ansi\u00adTo\u00adOem<\/code> led us to the realization that the Windows clipboard automatic text conversion diagram is non-commutative<\/a>. And the conversion we’re observing is consistent with Windows deciding not to do the direct conversion of CF_TEXT<\/code> to CF_OEM\u00adTEXT<\/code>, but rather converting from CF_TEXT<\/code> to CF_UNICODE\u00adTEXT<\/code>, and from there to CF_OEM\u00adTEXT<\/code>.<\/p>\n

It took a day before I realized what was going on. Let’s look at the graph again.<\/p>\n\n\n\n\n\n\n\n
 <\/td>\nCF_TEXT<\/td>\n<\/tr>\n
(CF_LOCALE)<\/td>\n\u21c5<\/td>\n <\/td>\n\u2191<\/td>\n(LOCALE_<\/td>\n<\/tr>\n
 <\/td>\nCF_UNICODETEXT<\/td>\n <\/td>\n|<\/td>\nUSER_<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2196\u2198<\/td>\n\u2193<\/td>\nDEFAULT)<\/td>\n<\/tr>\n
 <\/td>\n(CF_LOCALE)<\/td>\n <\/td>\nCF_OEMTEXT<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If we start with CF_TEXT<\/code> and somebody asks for CF_UNICODE\u00adTEXT<\/code>, it will be converted via the CF_LOCALE<\/code> clipboard format to Unicode (which for Windows means UTF-16LE). And then if we ask for CF_OEM\u00adTEXT<\/code>, the diagram above shows that Windows will prefer to convert from CF_UNICODE\u00adTEXT<\/code>, so the string ends up being converted through CF_UNICODE\u00adTEXT<\/code> after all.<\/p>\n

The fact that the conversion diagram is path-dependent means that what you get is now influenced by what other applications read from the clipboard. After our test program copied text to the clipboard in ANSI format, the fact that another program requested CF_UNICODE\u00adTEXT<\/code> influences what a future CF_OEM\u00adTEXT<\/code> request will produce.<\/p>\n

And it’s not like the interloper program can do anything about it. There is no way to ask, “Hey, like, I know that you say that you have CF_UNICODE\u00adTEXT<\/code>, but do you really<\/i> have it? Or are you just pretending to have it?”<\/p>\n

And how do these interloper programs know when you changed the clipboard? Because they have registered clipboard format listeners. But what program do I have that has registered a clipboard format listener?<\/p>\n

And then it occurred to me: I have Clipboard History enabled.<\/p>\n

Clipboard History is waking up when the first test program copies ANSI text to the clipboard and reading out CF_UNICODE\u00adTEXT<\/code> to add to the clipboard history. This triggers the conversion CF_UNICODE\u00adTEXT<\/code>, and the result is cached back onto the clipboard. This means that when you ask for CF_OEM\u00adTEXT<\/code>, the clipboard sees that it has a choice of CF_TEXT<\/code> and CF_UNICODE\u00adTEXT<\/code>, and from the diagram we see that it prefers converting from CF_UNICODE\u00adTEXT<\/code>.<\/p>\n

I turned off Clipboard History, and the query for CF_OEM\u00adTEXT<\/code> started behaving as expected: The OEM text was generated by applying Ansi\u00adTo\u00adOem<\/code> to the CF_TEXT<\/code> contents.<\/p>\n

So I came to two conclusions.<\/p>\n

First, if you care about OEM text, then you should set your CF_LOCALE<\/code> to LOCALE_USER_DEFAULT<\/code> to avoid path-dependent conversions.<\/p>\n

Second, pretty much nobody cares about OEM text.<\/p>\n

Next time, we’ll look at another consequence of the above diagram.<\/p>\n","protected":false},"excerpt":{"rendered":"

Something is forcing it down an alternate path.<\/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-111873","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Something is forcing it down an alternate path.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111873","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=111873"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111873\/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=111873"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111873"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111873"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}