Windows panosunda CF_TEXT formatından CF_OEMTEXT formatına yapılan otomatik metin dönüştürme işleminin neden beklenenden farklı bir yol izlediği, Microsoft'un eski blog yazılarından birinde detaylıca inceleniyor. Yazar, bu dönüşümün doğrudan gerçekleşmek yerine, CF_TEXT'ten CF_UNICODETEXT'e, oradan da CF_OEMTEXT'e dolaylı bir yoldan yapıldığını fark ediyor. Bu durum, panonun otomatik metin dönüştürme şemasının "değişmeli olmadığını" (non-commutative) ve dönüşümün izlediği yolun, diğer uygulamaların panodan ne okuduğuna bağlı olarak değişebileceğini ortaya koyuyor.
Bu "yola bağımlı" davranışın ana nedeni, panoya kopyalanan CF_TEXT içeriğinin, başka bir uygulamanın CF_UNICODETEXT formatını talep etmesiyle CF_UNICODETEXT'e dönüştürülüp önbelleğe alınmasıdır. Yazarın kendi deneyiminde, bu "aracı" uygulamanın Windows'un Pano Geçmişi (Clipboard History) özelliği olduğu ortaya çıkıyor. Pano Geçmişi, CF_TEXT kopyalandığında CF_UNICODETEXT'i okuyarak geçmişe ekler ve bu da panonun CF_UNICODETEXT içeriğini önbelleğe almasına neden olur. Daha sonra CF_OEMTEXT istendiğinde, pano CF_TEXT yerine önbelleğe alınmış CF_UNICODETEXT'ten dönüştürmeyi tercih eder.
Yazar, Pano Geçmişi'ni kapattığında CF_OEMTEXT sorgusunun beklenen şekilde çalıştığını, yani CF_TEXT içeriğine AnsiToOem fonksiyonunun uygulandığını belirtiyor. Bu durumdan iki sonuç çıkarıyor: Birincisi, eğer OEM text önemliyse, yola bağımlı dönüşümleri önlemek için CF_TEXT'in LOCALE_USER_DEFAULT olarak ayarlanması gerektiği. İkincisi ise, günümüzde neredeyse hiç kimsenin OEM text ile ilgilenmediği. Bu keşif, Windows'un pano mekanizmasının karmaşıklığını ve farklı formatlar arasındaki etkileşimlerin beklenmedik sonuçlar doğurabileceğini gösteriyor.
Windows panosundaki metin formatı dönüşümlerinin, Pano Geçmişi gibi özellikler veya diğer uygulamalar nedeniyle dolaylı yollardan gerçekleşebileceği ve bu durumun beklenmedik sonuçlar doğurabileceği anlaşıldı.