epoll, LSB (was: Re: Problem roundup)

Dmitry Timoshkov dmitry at baikal.ru
Sun Nov 21 03:18:18 CST 2004

"Shachar Shemesh" <wine-devel at shemesh.biz> wrote:

> >We don't really have to write it from scratch, porting an existing code
> >would suffice, but a difference between unicode char width (16 vs. 32 bit)
> >makes it impossible to use any system unicode APIs.
> >
> Lost you there. We are currently using ICU precisely because it does 
> have UTF-16 support.
> > Another reason to have
> >an internal implementation is to not depend on possible differences between
> >implementations, differences in collation tables is an obvious example here.
> >  
> >
> Lost you there again. There is no dependence of BiDi on collation, or we 
> would use ICU for a lot more than only BiDi. ICU is an entire Unicode 
> solution, and does have all of those things.

That's my point here: we don't need an external unicode solution, we already
have one, we just need to add missing parts, and we really don't want to depened
on ICU or anything else.

> Seriously, I don't see anyone here volunteering to maintain the BiDi 
> code, and I don't have the resources to chase Unicode around. I really 
> think using an external library is the right thing to do.

I don't understand you: you were arguing some time ago that ICU is too
bad as an external library and freebidi is not ready to be used in Wine.
Now you want to use that approach anyway. It's really time to rethink
your stance and either import an existing bidi code to Wine and use it as
a base for further improvements, or find a replacement for ICU and start
to use it.

String folding, case mapping, character types, collation, decomposition,
code page conversions are already implemented in wine_unicode, I don't see
why bi-di can't added there as well. If we would think in terms of laziness
Wine would be nowhere these days.


More information about the wine-devel mailing list