"Tcl is mostly in good shape for 64-bit platforms. The 'mostly' comes because anyone wanting any individual entity larger than 2GB (which is still a definitely humongous string!) will be in trouble. There is a major piece of clean-up still required to fix that (it's bug 219196, and as you can see it's been known about for a long long time), but I'm planning to put that off until Tcl 9.0 because it is totally incompatible with preceding API versions at the binary level on 64-bit platforms (might also require source changes, but it's the binary-level stuff that's the problem)." (Quote is from [dkf] on comp.lang.tcl) [DKF]: The remaining major issue is Tcl bug #219196[https://sourceforge.net/tracker/?func=detail&aid=219196&group_id=10894&atid=110894]. As you can tell from the number and a little knowledge of SF, we've known about that particular fault/misfeature for a good few years now. [AMG] finds "it's been known about for a long long time" to be a horrible, horrible pun. [jcw] - bug #219196 is titled "size_t != unsigned int". That could perhaps be resolved by changing the relevant "int" uses to "intptr_t" in the Tcl codebase (intptr_t is an int, guaranteed to be large enough to hold a pointer). The intptr_t typedef is defined in "stdint.h" or "unistd.h". [AMG]: But [DKF] says his concern is with binary compatibility. [LV]: And this change is '''SO''' incompatible that even at the move from 8.4 to 8.5 we can't make it? 64 bit computing is here now - with Oracle 10 now defaulting to 64 bit libraries, people are going to be able to retrieve huge values from databases, so this is going to be a growing concern to people. ---- [RS] 2008-09-10: Are there binary downloads for 64-bit [Windows] available? ---- [[ [Category Internals] ]]