3 comments

Discussion is closed. Login to edit/delete existing comments.

• 

  Igor Levicki December 17, 2025 0

  Collapse this comment Copy link

  > Clipboard History is waking up when the first test program copies ANSI text to the clipboard and reading out CF_UNICODE­TEXT to add to the clipboard history. This triggers the conversion CF_UNICODE­TEXT, and the result is cached back onto the clipboard.

  That’s just horrible design of Clipboard History.

  When I place something on the clipboard I don’t expect it to be silently mutated by some OS component.

• 

  Simon Farnsworth December 17, 2025 0

  Collapse this comment Copy link

  This path dependency looks like a consequence of history, and therefore something that might matter to backwards compatibility in niche use cases.

  I'm assuming that CF_TEXT and CF_OEMTEXT existed back in the Windows 1.0 days - certainly Win16 era, before Unicode was a thing at all, and the respective conversions existed then, too. This gives you a nice simple table: "If I have CF_TEXT, and the consumer wants CF_OEMTEXT, use AnsiToOem, if I have CF_OEMTEXT and want CF_TEXT, use OemToAnsi". You might well handle the conversion by adding the missing format on demand, and thus caching the fact that a conversion...

  Read more

  This path dependency looks like a consequence of history, and therefore something that might matter to backwards compatibility in niche use cases.

  I’m assuming that CF_TEXT and CF_OEMTEXT existed back in the Windows 1.0 days – certainly Win16 era, before Unicode was a thing at all, and the respective conversions existed then, too. This gives you a nice simple table: “If I have CF_TEXT, and the consumer wants CF_OEMTEXT, use AnsiToOem, if I have CF_OEMTEXT and want CF_TEXT, use OemToAnsi”. You might well handle the conversion by adding the missing format on demand, and thus caching the fact that a conversion happened.

  Then CF_UNICODETEXT is added in Win32, and the people doing the work for this use the “obvious” conversions between UCS-2 and OEM/ANSI code pages. But that creates your path dependency; it just doesn’t show up for them, because CF_LOCALE != LOCALE_USER_DEFAULT is an unlikely setup in cases where all the files you use are created on machines with the same setting for LOCALE_USER_DEFAULT.

  And by the time you’re at risk of CF_LOCALE != LOCALE_USER_DEFAULT, most applications use CF_UNICODETEXT or CF_TEXT anyway – it’s only the deep legacy applications that still use CF_OEMTEXT, because it mattered when they were on Win16. But those were rare cases to begin with, and many won’t have survived the compulsory port to Win32 to run on 64-bit Windows.

  Read less
  • 

    Stephan Leclercq December 18, 2025 0

    Collapse this comment Copy link

    It seems to me that this dependency is a consequence of the KISS principle trying to avoid unavoidable complexity, and failing miserably as usual ;-)

    The natural solution is that clipboard should not synthesize additional content based on whatever is already present in the clipboard, but based on what the user (ie program that called OpenClipboard()) initially provided as data. If the user provides CF_TEXT, then the clipboard synthesizes CF_UNICODETEXT on demand from the clipboard history, then someone asks for CF_OEMTEXT, the synthesis should consider only CF_TEXT because that's the only thing that was initially provided.

    The implementation would be...

    Read more

    It seems to me that this dependency is a consequence of the KISS principle trying to avoid unavoidable complexity, and failing miserably as usual 😉

    The natural solution is that clipboard should not synthesize additional content based on whatever is already present in the clipboard, but based on what the user (ie program that called OpenClipboard()) initially provided as data. If the user provides CF_TEXT, then the clipboard synthesizes CF_UNICODETEXT on demand from the clipboard history, then someone asks for CF_OEMTEXT, the synthesis should consider only CF_TEXT because that’s the only thing that was initially provided.

    The implementation would be more complex indeed, but it simply did not embrace that complexity in order to avoid the need to store that additional “automatically synthesized” flag. YAGNI is a cool principle until you reach the point where you realize that you actually needed it all along, and it’s too late to add it without introducing breaking changes.

    Read less