From: SourceForge.net <no...@so...> - 2010-03-08 15:04:52
|
Feature Requests item #2965056, was opened at 2010-03-07 14:13 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=2965056&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 52. Portability Support Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Jan Nijtmans (nijtmans) Summary: Windows build with -DUNICODE Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2010-03-08 15:04 Message: 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? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2010-03-08 14:44 Message: ??? How can you "phase out" something that was abandoned years ago? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-03-08 12:08 Message: > 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. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-03-08 09:42 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=2965056&group_id=10894 |