Tcl Source Code

This issue is inspired by some remarks by Kevin Kenny in private mail:
(3) I'm particularly puzzled by the way that tclWinProcs->getTempPath
   has been defined to accept a WCHAR string rather than a TCHAR
   string, in light of the fact that 'asciiProcs' still fills
   it in with GetTempPathA. This strikes me as a type
   mismatch that can only lead to trouble.
(4) I see new code that does TclpNativeToNormalized on a WCHAR string
   (cast to a ClientData). Is it true that -DUNICODE is now the
   only configuration we support, and that TCHAR and WCHAR are
   always one and the same?  If so, I thoroughly approve, but
   in that case, I'm still puzzled by asciiProcs.

My conclusion is that all functions in tclWinProcs should have
TCHAR in it's signature, not WCHAR. However, this leads to
constructs like:
    TCHAR nativeSrcPath[MAX_PATH*2];
The reason for this is that the default build of
Tcl is still ASCII, not UNICODE.

So, I propose to make UNICODE the standard
build method, changing the above construct
to:
    TCHAR nativeSrcPath[MAX_PATH];
Still, everything will function the same as now,
only the right size if allocated for UNICODE,
without the need for multiplying with 2
everywhere.

Patch upcoming.

allow_comments - 1

Since this is all done for some time in trunk, let's close it, unless someone wants to evaluate it.

First part checked in HEAD.

Kevin, please evaluate. This patch does some clean-up of
old Win95-ish constructs (*2 in array allocations). The
-DUNICODE is necessary to force all API calles which
don't use the A or W variant, to use the W variant
by default. I think this is a right step in the
cleaning up of Tcl, but if you find any problem
with it feel free to revert ;-)

File Added - 372779: 2965056-2.patch

Second patch, which still does nothing. It just
makes sure that tclWinTest.c, tclWinReg.c and
tclWinDde.c never are compiled in UNICODE
mode. Eventually, they can, but first let's prove
that compiling the core library in UNICODE
mode does not cause ANY source or binary
incompatibility before going on.

File Added - 367518: 2965056-1.patch

>Assigning back to nijtmans, in lieu of marking 'Closed/Rejected'

Here are two examples, tclWinSock.c and tclWinNotify.c, which
show how it should be done. In stead of using WCHAR, and calling
the ..W() functions directly, I prefer much more to use TCHAR
and compile with -DUNICODE -D_UNICODE. It makes the
code more readable, and it encourages developers to
use the UNICODE interface, instead of falling in the trap
of using the ASCII interface without it being visible in the code.

So, here is the first small patch.

I'm afraid that I'm really confused by the series of changes, except that they have been leaving a steady trail of broken builds.

In any case, let me agree: Win9x is dead. Bury it. 

But I'd also think that we'd have no need of -DUNICODE or -DMBCS. Just call the ...W interfaces directly (or, I suppose the ...A interfaces if for some reason we need ANSI instead of Unicode). And ... whatever tclWinProcs does, it's working. Don't mess with it. Just steadily replace calls through its pointers with direct calls to the appropriate API's. Don't bother trying to clean it up when the long-term objective is to eliminate it entirely.

And similarly, a project to support MSLU seems misguided. Such an effort would have made sense back in 2002 or so, which is when I recall first proposing it.  But back then, Win9x was still alive.  Today, MSLU is a waste of effort.

Assigning back to nijtmans, in lieu of marking 'Closed/Rejected'

This is sounding really wrong to me, and I think a number of other developers would also rather you did not work in this area. Your comments are just raising lots of red flags. PLEASE DO NOT COMMIT ANYTHING RELATING TO THIS ISSUE WITHOUT SOMEONE ELSE EXPLICITLY AGREEING THAT THE PATCH IS GOOD. Sorry about shouting, but I want to be totally clear here.

Assigning to kbk as he's very sensible.

In that case, my upcoming patch will not meet
very much resistance.

That was my thought too. We don't (to my knowledge) support any platform that does not use the WCHAR-based interfaces on any version of Tcl that we plan to release in the future. Who uses Win98 or ME any more?

???

How can you "phase out" something that was abandoned years ago?

> Please give it at least a day or two before committing anything on this,
> just to give the North American Tclers a chance to comment.

Sure. Currently, I'm only cleaning up the current mess a little bit :-)
Then I'll put a patch here before committing anything. This has
potentially high impact, although I agree fully with Kevin.

This change is NOT meant to phase out Win95/98/ME!
Everything should work exactly the same when
compiled with -DUNICODE. However, after this
change, Tcl compiled without -DUNICODE
should only be run on Win95/98/ME. Tcl compiled
with -DUNICODE can run anywhere.

Please give it at least a day or two before committing anything on this, just to give the North American Tclers a chance to comment.