>> Now let's see how we can use it to implement Unicode support. >> If it's possible in reasonable time to replace all string related >> functions in the whole Harbour SVN code to work with Unicode items >> then we can think about replacing also other functions and switching >> to new API. >> Harbour is not my fulltime job so I do not want to start global >> modifications which I cannot finish in reasonable time so it's >> possible that it will never happen :-( > > I'm not sure if this could be done and that way, but it would be nice to have > some better cooperation in development. I think more developers can help, if > large modifications can be divided into smaller pieces and the road of > reaching the final goal is clear for more developers.
That's very true. Many times I feel that it's only me who wants some changes, which makes me slowly but painfully advance alone (for the most part). Not very efficient and even I wonder for how long I can keep it up. I can see two large areas which are pending / in progress and can easily be split into multiple / parallel steps: - "type cleanup" - The goal is simple: Replace all Windows types present in portable Harbour code with native Harbour types (HB_*). - Harbour native "unicodization". (perhaps joint with API reform) Plus two shorter term tasks: +1 Windows .dll handling both 32-bit and 64-bit. +2 hbwin/hbqt issues with GC reference counting. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
