Hi All, If that simplifies things (which it definitely does), and the majority of developers agree with it, we can drop non-UNICODE mode altogether from Harbour source code.
It's unlikely we shall ever support Windows 3.x or Win32s, and unicows solution works just perfect now to cover Win9x/ME host versions, so I can see no hard reason to maintain duplicate code paths for both UNICODE and non-UNICODE Windows API support. Having only UNICODE path could greatly simplify code in many crucial points, making it easier to maintain, extend, debug and keep bug free. Especially if we want to move towards internal (HVM) unicode support in the future. Any opinions on this? Viktor On 2010 Apr 29, at 10:51, dru...@users.sourceforge.net wrote: > Revision: 14412 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14412&view=rev > Author: druzus > Date: 2010-04-29 08:51:41 +0000 (Thu, 29 Apr 2010) > > Log Message: > ----------- > 2010-04-29 10:51 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/vm/strapi.c > * harbour/include/hbapistr.h > + added new C function hb_wstrnlen() > > * harbour/include/hbdefs.h > * harbour/src/common/hbwin.c > ! fixed possible buffer overflows in hb_mb*() and hb_wc*() functions > * removed danger hb_mb*() and hb_wc*() functions which were wrongly > used in core code and corresponding HB_TCHAR_*() macros > + added hb_mbntowccpy() function and HB_TCHAR_COPYTO() macro > it always sets trailing 0 after passed buffer just like hb_strncpy() > + added hb_wcntombcpy() function and HB_TCHAR_COPYFROM() macro > it always sets trailing 0 after passed buffer just like hb_strncpy() > > * harbour/src/rtl/gtclip.c > ! fixed wrongly calculated size of string extracted from clipboard > (when unicode string was in clipboard then number of unicode characters > were used instead of number of multibyte ones) > ! added protection against possible memory corruption if some external > process sets clipboard text without trailing 0 > * changed hb_gt_winapi_[sg]etClipboard() functions parameters to use > PHB_ITEM as buffer > Question to windows users: different Win GTs use different encoding > for the clipboard buffer. Maybe you want to normalize it? > > * harbour/src/vm/cmdarg.c > * harbour/src/vm/extrap.c > * harbour/src/common/hbgete.c > * harbour/src/common/hbffind.c > * harbour/src/common/hbtrace.c > * harbour/src/rtl/gtwin/gtwin.c > * harbour/src/rtl/fstemp.c > * harbour/src/rtl/filesys.c > * harbour/src/rtl/gtgui/gtgui.c > * harbour/src/rtl/gtwvt/gtwvt.c > * harbour/include/hbgtcore.h > * harbour/include/hbapistr.h > * harbour/include/hbwmain.c > * harbour/contrib/gtwvg/gtwvg.c > * harbour/contrib/gtwvg/wvggui.c > * harbour/contrib/gtwvg/wvgcuig.c > * harbour/contrib/gtwvg/wvgutils.c > * harbour/contrib/gtwvg/wvgcore.c > * harbour/contrib/gtwvg/wvgwing.c > * harbour/examples/gtwvw/gtwvw.c > ! fixed possible buffer overflows and GPF traps due to wrongly used > HB_TCHAR_*() macros and/or corresponding hb_mb*()/hb_wc*() functions > Seems that some problems were potentially exploited even in non UNICODE > builds. > > Modified Paths: > -------------- > trunk/harbour/ChangeLog > trunk/harbour/contrib/gtwvg/gtwvg.c > trunk/harbour/contrib/gtwvg/wvgcore.c > trunk/harbour/contrib/gtwvg/wvgcuig.c > trunk/harbour/contrib/gtwvg/wvggui.c > trunk/harbour/contrib/gtwvg/wvgutils.c > trunk/harbour/contrib/gtwvg/wvgwing.c > trunk/harbour/examples/gtwvw/gtwvw.c > trunk/harbour/include/hbapistr.h > trunk/harbour/include/hbdefs.h > trunk/harbour/include/hbgtcore.h > trunk/harbour/include/hbwmain.c > trunk/harbour/src/common/hbffind.c > trunk/harbour/src/common/hbgete.c > trunk/harbour/src/common/hbtrace.c > trunk/harbour/src/common/hbwin.c > trunk/harbour/src/rtl/filesys.c > trunk/harbour/src/rtl/fstemp.c > trunk/harbour/src/rtl/gtclip.c > trunk/harbour/src/rtl/gtgui/gtgui.c > trunk/harbour/src/rtl/gtwin/gtwin.c > trunk/harbour/src/rtl/gtwvt/gtwvt.c > trunk/harbour/src/vm/cmdarg.c > trunk/harbour/src/vm/extrap.c > trunk/harbour/src/vm/strapi.c > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
