#617 Full unicode support for Dde


When Tcl communicates with other applications like
Word or Excel, it communicates using the CF_TEXT
clipboard format using utf-8. This goes wrong if
the other application doesn't assume utf-8 but
the system encoding, as Word and Excel do.

Nowadays, Word and Excel communicate in
the CF_UNICODETEXT clipboard format.
If Tcl starts using that, it would immediately
solve the encoding problem mentioned
in TIP #106.

The "-binary" option will still be needed
in order to communicate with external
programs which don't know
CF_UNICODETEXT, and for test-cases
that check upwards compabitbility.


  • Jan Nijtmans

    Jan Nijtmans - 2012-05-16

    First implementation committed to branch frq-3527238.

    Although all tests cases pass, it still has a big TODO:
    In line 789, I have no idea how the XTYP_EXECUTE
    request can now whether the incoming string is
    Unicode or UTF-8. So I put in a simple test which
    asumes that the first character is ASCII, but
    obviously that's not how to do that.

    Ideas, anyone?

  • Jan Nijtmans

    Jan Nijtmans - 2012-05-23

    This FRQ definetely needs a TIP: just discovered that
    in order to make the "handler" accept other encodings
    than Unicode or utf-8, a "-binary" option is needed
    for the [dde servername] command. Looks like an
    oversight in TIP #106

    This "-binary" option now added in the frq-3527238
    branch. Test case still missing, but all current tests
    pass. doc is updated too.

  • Jan Nijtmans

    Jan Nijtmans - 2012-05-29

    Merging this with trunk [Bug 3525762] break
    test winDde-9.4, but it works fine running
    winDde-9.4 individually. The reason for
    this is that when an application connects
    with Dde using the UNICODE API, it
    cannot re-connect any more using
    the WINANSI API. This means that
    - The test-case needs to be re-written
    such that the server uses UNICODE,
    connecting with a WINANSI client.
    - The "dde servername" should give
    an error if the -binary option is used
    while the dde connection is already

  • Jan Nijtmans

    Jan Nijtmans - 2012-06-11

    It turns out that implementing the "-binary"
    option for [dde eval] and [dde servername]
    is not trivial. But the real question is: Is it
    really necessary. The [dde eval] and [dde
    servername] are meant to be used for
    two tcl interpreters to communicate. If
    both use UNICODE or both use
    WINANSI, there is no problem at all. So
    the only possible problem exists when
    Tcl 8.5 interpreters access Tcl 8.6
    interpreters, and they each use a different
    dde version. But why should they
    do that?: dde 1.4 works fine in Tcl 8.5,
    and dde 1.3 works fine in Tcl 8.6 too.
    Just use the same dde version at both
    ends of the communication.

    Conclusion: Implement the UNICODE
    protocol for DDE, without implementing
    additional "-binary" options.

    So, there is a potential incompability:
    Any Tcl8.5/dde1.3 client accessing a
    Tcl8.6/dde1.4 server will handle
    characters outside of the ASCII range
    incorrectly: In this situation, Windows
    detects that Tcl8.6/dde1.4 handles
    UNICODE, and wil automaticially
    transform the data from WINANSI to
    UNICODE. Only .. the original data
    is UTF-8, not WINANSI.
    The other way around is no
    problem, assuing that dde 1.3.3
    is present implementing [Bug 473946]

  • Jan Nijtmans

    Jan Nijtmans - 2012-09-19

    Branch frq-3527238 updated to the state of Tcl 8.6b3, and
    increased the dde version to 1.4.0b2

    Testcase winDde-4.3 shows the advantage of using
    CF_UNICODETEXT: "dde request" now can handle
    unicode characters in variable names, something
    that was not possible with dde 1.4.0b1

  • Jan Nijtmans

    Jan Nijtmans - 2012-09-20
    • summary: implement CF_UNICODETEXT --> Full unicode support for Dde
  • Jan Nijtmans

    Jan Nijtmans - 2012-09-20

    Committed to trunk.

  • Jan Nijtmans

    Jan Nijtmans - 2012-09-20
    • status: open --> closed-fixed