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
