Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi, I see no problem for Win 3.x and Win32s, we still have customers with Win9x. Many of the projects are contained in the only .exe file, so requirement of extra .dll is not nice. One more thing is that my libraries are non-UNICODE, but I do not see a big reason to do rewrite a working piece of code until HVM internals does not allow to contain multi-language strings and rewrite do not add new fuctionality. Maybe some macros like HB_PARSTR() can help to implement a good layer for UNICODE/non-UNICODE versions of app. It can help to make code clean and easy maintainable. Regards, Mindaugas On 2010.04.29 15:13, Viktor Szakáts wrote: 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? ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Mindaugas, I see no problem for Win 3.x and Win32s, we still have customers with Win9x. Many of the projects are contained in the only .exe file, so requirement of extra .dll is not nice. One more thing is that my libraries are non-UNICODE, but I do not see a big reason to do rewrite a working piece of code until HVM internals does not allow to contain multi-language strings and rewrite do not add new fuctionality. Pls remember that you may well need other extra .dlls/packages anyway f.e. to run Harbour apps on Win95/Win95b and other combinations, like mingw/msvc builds and Win95-98. Chances are high though that unicows.dll and these other extra packages are already installed by now (had 12-15 years to do that), if not, there are simple MS packages users can install on these PCs. My point is that it's unavoidable anyway to deal with the extra package issue when running Harbour apps (and many other apps) on Win9x, and that such issue is not very hard to deal with, since there exist official MS package for all of them, and the packages are well documented even in our INSTALL doc. Other libs and local code are unaffected by Harbour core's UNICODE mode. So while I see your point, this is not something which has any technical influence on our decision. Maybe some macros like HB_PARSTR() can help to implement a good layer for UNICODE/non-UNICODE versions of app. It can help to make code clean and easy maintainable. It covers part of the problem, but doesn't cover other 200 code sections, where these functions cannot be used. These are usually code sections which deal with the conversions on the low level (as opposed to simply accept/return Harbour function parameters, like with HB_PARSTR() and friends). Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Viktor, It turns out that my tests of doing the devout calls to the screen in Win9x with the unicows solution is about 2 or 3 times slower than non-unicode compiled .EXEs on the same machine. And this is with Przemek's SET CURSOR OFF trick as well for Win9x machines... So this simple test and its performance hit would leave me to conclude that the unicows solution isn't 100% perfect. Just my two cents. If it cannot be solved, then I suppose my vote would be to still keep the non-unicode mode...? I don't know enough about Harbour to see the implications :[ On Thu, Apr 29, 2010 at 5:13 AM, Viktor Szakáts harbour...@syenar.huwrote: 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, ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Update: well I did a raw DEVOUT for loop test, and it was a only about 10% slower. The 2 or 3 times slower claim was in the ap we use itself, where we have another test which does almost the same thing, and it is about 2 or 3 times slower... not sure what really is responsible, only thing I know of that changed on my end was the non-unicode / unicode build... *confused* On Fri, Apr 30, 2010 at 2:01 PM, smu johnson smujohn...@gmail.com wrote: It turns out that my tests of doing the devout calls to the screen in Win9x with the unicows solution is about 2 or 3 times slower than non-unicode compiled .EXEs on the same machine. And this is with Przemek's SET CURSOR OFF trick as well for Win9x machines... -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Removal of non-UNICODE Windows codepath?
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=14412view=rev Author: druzus Date: 2010-04-29 08:51:41 + (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
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Viktor, What is special about non-unicode Windows in compare to other non windows OS that are currently supported by Harbour? Can't it be just considered another type of Os? (I know that in maintanance therms, it is best to have less variations as possible) Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Chen, Viktor, What is special about non-unicode Windows in compare to other non windows OS that are currently supported by Harbour? Can't it All Windows API calls that has to do anything with strings have two versions: one which deals with ANSI (8-bit) string types and another flavor which deals with WIDE (UTF-16 aka. UNICODE) string types. Every time Harbour has to call a Windows API function, which has two versions, we need to take care of both types to maintain compatibility with both normal (non-UNICODE) and UNICODE builds. F.e. when we call GetCurrentDirectory(), it will be translated to either GetCurrentDirectoryA() in non-UNICODE (= ANSI) call, or GetCurrentDirectoryW() UNICODE (= WIDE) call when '-DUNICODE' compile-time option is used. The two modes will return different string, so we need to deal with it differently to convert it to Harbour string. We have a quite sophisticated set of functions and macros to deal with the issue. In pure UNICODE mode, we could either define -DUNICODE as static option, or replace all Windows API call to WIDE flavor (f.e. GetCurrentDirectory() with GetCurrentDirectoryW()) and drop all the code which deals with the ANSI type. On WinNT and newer Windows OSes, the ANSI Windows API function (*A() calls are wrappers to native WIDE ones, so they are slower than direct WIDE calls. On Win9x/ME there are no WIDE functions implemented, so there the ANSI versions are the native ones. This means that apps built in UNICODE mode won't work by default on these OSes since the requires WIDE function calls are missing from system libraries. Microsoft developed a solution though, which is UNICOWS.DLL, and this .dll provides WIDE wrappers to native ANSI ones, when the executable is run on such old OS version. On NT and upper OSes, it's invisible and doesn't cause any overhead. be just considered another type of Os? Could be, but it would require lots of duplicate code, and such solution would be in essence a reworked way of keeping two parallel versions of every code which calls the Windows API. Overall, we wouldn't gain much at the end after a painful conversion process. (I know that in maintanance therms, it is best to have less variations as possible) Yes. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
On Thu, 29 Apr 2010, Szak�ts Viktor wrote: Hi, 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. I would like to keep support for non unicode windows builds. I do not see anything what give noticeable simplification in Harbour core code because we will still have to keep support for other platforms which do not use unicode. For me native Win9x support is as important as WinCE port and I want to be able to create application which can be executed on Win9x without any overhead due to dummy emulation layer and I do not plan to fight with any more or less important problems or incompatibilities in libunicows and look for workarounds or send patches to the authors. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Przemek, 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. I would like to keep support for non unicode windows builds. I do not see anything what give noticeable simplification in Harbour core code because we will still have to keep support for other platforms which do not use unicode. For me native Win9x support is as important as WinCE port and I want to be able to create application which can be executed on Win9x without any overhead due to dummy emulation layer and I do not plan to fight with any more or less important problems or incompatibilities in libunicows and look for workarounds or send patches to the authors. libunicows is just an open source, compiler portable variant of the unicows import lib + load code to be able to use the actual wrappers in unicows.dll (shipped by Microsoft) with all compilers (not just MSVC). So there is nothing which you need to fight with here. It just works and the code stable since long years. As I mentioned already, but maybe it wasn't clear, the whole wrapper logic (or dummy calls) is completely inactive on WinNT and above platforms, so for any apps that are designed to run on these platforms in the first place (using UNICODE), there is _no_ _overhead_ when using unicows. On Win9x, you indeed need to go through the wrappers, but given that these systems are much of an exception these days, it looks a much better compromise for an app than having the go through ANSI to WIDE wrappers on all modern ( WinNT) operating systems, which are the waste majority. BTW I expect the overhead to be minimal for GTWIN/GTWVT apps, as there is not too many UNICODE sensitive calls used in normal app operation, and practically none when doing processing using pure Harbour code. Pls correct me if I'm wrong with that assumption. To put this issue into wider Win9x perspective, most Harbour apps, even when using non-UNICODE builds, will need to have these extra Win9x components to be able to run properly or at all: 95/95B/98/ME/NT: http://download.microsoft.com/download/vc60pro/update/1/w9xnt4/en-us/vc6redistsetup_enu.exe 95B: ftp://ftp.microsoft.com/softlib/mslfiles/vrdrupd.exe 95: http://download.microsoft.com/download/0/e/0/0e05231b-6bd1-4def-a216-c656fbd22b4e/w95ws2setup.exe [ all listed in INSTALL. ] BTW, can you tell some examples where you still need to design apps to run specifically on Win9x? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Viktor, Sorry but I do not understand why do you want to delete already working code. In longer terms it may cause that we will create problems for platform which do not use Unicode forcing Unicode everywhere reducing Harbour functionality to current Java or Phyton level. For me it will be end of this project. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Przemek, Sorry but I do not understand why do you want to delete already working code. In longer terms it may cause that we will create problems for platform which do not use Unicode forcing Unicode everywhere reducing Harbour functionality to current Java or Phyton level. For me it will be end of this project. Perhaps you misunderstood me, but I'm not saying to force unicode everywhere. Only on Windows API calls in Windows specific code parts. This has nothing to do with Harbour core functionality, which can continue to support everything it supported thus far. The reason for my initiative is that we have quite limited resources, and if you ask me, I used to spend lots and lots of time to make code work in both modes (not to mention the other variation on Windows platforms). Even this lots of time is not enough to test it properly, as practice shows. I'd assume the same is even more true in your case. We have 200 '#ifdef UNICODE' branching in Harbour codebase, which is quite a lot. Not to mention other developers who'd like to contribute; very few ppl can provide code which doesn't need local tweaking and retesting. When in the future Harbour will have internal UNICODE support, we will have to face the problem again, since we will need to support 4 types of conversion when interfacing Harbour HVM with Windows API (8bit-ANSI, 8bit-WIDE, UNICODE-ANSI, UNICODE-WIDE, plus the same in reverse direction). Which doesn't seem like making things simpler. I'm sorry if this is the end of the project for you, but I had preferred to see some real argument from your side, it's possible I'm missing something or my assumptions or general view of the topic is wrong, and in this case I'm happy to be corrected, so that at the end we make the best decision based on real facts and discussion. For sure you have something, if keeping non-UNICODE support is such important issue for you. All this has nothing to do with becoming Java and Python, it's only a technical detail which doesn't change much fundamental from usability or portability POV. [ BTW, unicows usage support could even be made simpler, or fully transparent, if needed, but it's already extremely simple, so I didn't even think about it. It was enough to spend quite a few days on the topic to actually making it as simple as it is now. ] Still awaiting for your actual arguments, as your time allows. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi, On Thu, Apr 29, 2010 at 5:13 AM, Viktor Szakáts harbour...@syenar.huwrote: Hi All, 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. I have still not yet found an explanation as to what the unicows solution is, despite reading all the unicode threads. Perhaps I am not seeing something right in front of my eyes, but as far as I know, now one has said this is the solution, in unmistakable steps... all i have heard of is one word: unicows, and not any steps to take. I tried sticking the unicows.dll where I was executing the .EXE file on a Win9x machine and our program just hung doing nothing. Compiled without the unicode, the .EXE then works on Win9x. So the thought of moving in this direction worries me. When I compile Harbour for our use, we turn off UNICODE mode with a compiler switch everytime to avoid all this confusion. If the solution is having to run a packaged unicows installer on the Win9x machine, then this will become a nuisance for a few hundred people. If a .dll can be simply placed somewhere, then that is okay... but as I've said, this didn't solve anything when I tried doing it. PS: I could care less about Win 3.1x, but some people (surprisingly) still use Win9x with our program. Perhaps they are afraid of technology? 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. It definitely sounds like a good idea that would save a lot of time for the Harbour project, so obviously it has my vote provided I can find a simple solution my concerns above. :/ Any opinions on this? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi, 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. I have still not yet found an explanation as to what the unicows solution is, despite reading all the unicode threads. Perhaps I am not seeing something right in front of my eyes, but as far as I know, now one has said this is the solution, in unmistakable steps... all i have heard of is one word: unicows, and not any steps to take. I've written down detailed steps at least three times on this list, last time in this very thread. There is no special thing in it though. I tried sticking the unicows.dll where I was executing the .EXE file on a Win9x machine and our program just hung doing nothing. Compiled without the unicode, the .EXE then works on Win9x. So the thought of moving in this direction worries me. When I compile Harbour for our use, we turn off UNICODE mode with a compiler switch everytime to avoid all this confusion. I wouldn't promote a solution if it didn't work. Here it works, the way I described it. The components are also listed in INSTALL. Quote: in quite simple way. All you need to do is adding -lunicows to your hbmk2 make file and bundle unicows.dll with your app. Works with all supported Harbour compilers. Get prebuilt libunicows binaries from here: http://libunicows.sourceforge.net/; [ Forgot to mention here that this requires recent Harbour version, 2.0.0 release won't work. Maybe worth to note that ] If the solution is having to run a packaged unicows installer on the Win9x machine, then this will become a nuisance for a few hundred people. If a .dll can be simply placed somewhere, then that is okay... but as I've said, this didn't solve anything when I tried doing it. Both can be done. The .dll by itself is not enough though. PS: I could care less about Win 3.1x, but some people (surprisingly) still use Win9x with our program. Perhaps they are afraid of technology? I also have clients using Win98. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi again, On Thu, Apr 29, 2010 at 3:21 PM, Viktor Szakáts harbour...@syenar.huwrote: The components are also listed in INSTALL. Quote: in quite simple way. All you need to do is adding -lunicows to your hbmk2 make file and bundle unicows.dll with your app. Works with all supported Harbour compilers. Get prebuilt libunicows binaries from here: http://libunicows.sourceforge.net/; [ Forgot to mention here that this requires recent Harbour version, 2.0.0 release won't work. Maybe worth to note that ] I have not found that in the INSTALL doc... G:\ver10\harbour-devgrep -in unicows INSTALL 630: UNICOWS solution to support Win9x/ME system s. 1411: Windows UNICOWS .dll [win, free, closed-source] 1414: Windows UNICOWS runtime/import library [win, free, open-source] 1415: http://libunicows.sourceforge.net/ Not even the hint that -lunicows is in there. I am not sure where you got that quote from, perhaps you are quoting something you said in the past. In either case, I have found that produces an hour when I compile harbour devs with win-make myself (which is my only choice, as 2.0.0 is the last stable bundled released, afaik). hbmk2: Linking... ../latest/bmd.exe c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot find -lunicows collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 my cmd: ..\harbour-dev\bin\hbmk2 -lunicows -icon=BKMNGR.ICO -strip -ustd.ch-kc -lhbct -lhbtpathy -lhbnf -inc -o..\latest\bmd.exe bm.hbp *sad face* ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Ooopsies... I meant to say error in the line below. On Thu, Apr 29, 2010 at 3:48 PM, smu johnson smujohn...@gmail.com wrote: I have found that produces an hour when I compile harbour devs with win-make myself (which is my only choice, as 2.0.0 is the last stable bundled released, afaik). -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
[ Forgot to mention here that this requires recent Harbour version, 2.0.0 release won't work. Maybe worth to note that ] I have not found that in the INSTALL doc... G:\ver10\harbour-devgrep -in unicows INSTALL 630: UNICOWS solution to support Win9x/ME system s. 1411: Windows UNICOWS .dll [win, free, closed-source] 1414: Windows UNICOWS runtime/import library [win, free, open-source] 1415: http://libunicows.sourceforge.net/ Not even the hint that -lunicows is in there. I am not sure where you got that quote from, perhaps you are quoting something you said in the past. In either case, I have found that produces an hour when I compile harbour devs with win-make myself (which is my only choice, as 2.0.0 is the last stable bundled released, afaik). The components are listed there, not the step by step guide. I've simply e-mailed the latter 4 times already to the list. The method consists of downloading a lib (unicows) and adding it to the liblist. hbmk2: Linking... ../latest/bmd.exe c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot find -lunicows collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 my cmd: ..\harbour-dev\bin\hbmk2 -lunicows -icon=BKMNGR.ICO -strip -ustd.ch -kc -lhbct -lhbtpathy -lhbnf -inc -o..\latest\bmd.exe bm.hbp *sad face* You are missing the component 'unicows' library. Download it from above link, unpack and copy to one of the existing lib dirs, or point to it using -L (libpath option). Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Thank you! On Thu, Apr 29, 2010 at 4:00 PM, Viktor Szakáts harbour...@syenar.huwrote: You are missing the component 'unicows' library. Download it from above link, unpack and copy to one of the existing lib dirs, or point to it using -L (libpath option). Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
