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
