Hi Przemek, In the 4 working days of live testing the GPFs seem to have disappeared and I got no crash reports from users either.
Thanks again. Viktor On 2010 Apr 29, at 11:12, Viktor Szakáts wrote: > Hi Przemek, > > Life saver patch, thank you very much. > > My non-UNICODE app build wasn't installed > yet by users, anyhow now I'll push a new > version using latest Harbour in UNICODE to > continue with live tests. > > As for clipboard encoding I agree to sync, > although the best would be to always use > UNICODE to push/pull from the clipboard > if that's possible. > > 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
