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
