Hi Przemek,

Okay I'm trying, but it's nearly impossible to
test everything in multiple versions after each
change.

Yes, I know and understand the reason. I only signal
problem. For my own use I have mk_all.sh script which
creates over then different Harbour builds and I run
it from time to time to test current code status.

I can create quite some of them under Windows, but
without any automatism, so generally it's a PITA
to deal with it.

I wish I could switch to GNU make, but for some
reason I hate it for everyday use. (I think because
it's building /tests too and it takes forever, and
also difficult to control contrib list to include)

Fully switching to GCC is also on my TODO list, but
here, 'rmake' is the blocking piece.

I wonder though, what are the disadvantages and
advantages of a UNICODE build on plain Windows,
at the stage we are?


UNICODE is the only one choice for WinCE builds so
we have to keep it. Now we are only translating
from/to CP character strings when calling unicode
functions. After 1.0 I'll add set of extended API
functions to oprtate on unicode strings, f.e.:
  hb_parc_utf8()
  hb_parc_u16()
  hb_retc_utf8()
  hb_retc_u16()

Sounds great. BTW I'm not suggesting the slightest
that UNICODE mode is a problem, I'd actually like
to switch to full unicode even under plain Windows.

IMO in the future we should step into full Unicode,
if that has any base of reality.

[ See some random thoughts on this in a mail from a few days before. ]

Which will make all necessary translation internally
respecting current HVM CP. Please note that such API
allows to introduce unicode string items without updating
3-rd party code. If 3-rd party code will need unicode
string then it simply call hb_parc_u16(1) and and HVM
will make all necessary translation or it will return
raw string pointer if the item already contains string
in U16 unicode representation. It will be invisible
for user. Also when user code will make hb_parc( 1 )
and string item will be in U16 representation then
reverted translation will be done respecting current
HVM CP. It will alow us to introduce UNICODE in small
steps.

Very nice!

Brgds,
Viktor

_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to