epoll, LSB (was: Re: Problem roundup)

[Shachar Shemesh]

Dmitry Timoshkov wrote:

>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.
>  
>
I think the source of the problem is a small misunderstanding about what 
LPK.DLL does on windows. It's not where the reordering algorithm is. 
That's in uniscribe. What's there is how this reordering algorithm is 
used for ExtTextOut, DrawText, EditControl and so on. As such, I think 
it's best if we did the same in Wine. Since the interface to LPK.DLL is 
undocumented, I think it's best to use something with similar 
functionality but different name, say "WINELPK".

As for the algorithm itself, I have no objection to it being implemented 
in wine_unicode. I'm just questioning the wisdom of that DLL. What does 
Windows use for the same functionality? If it's not there, where is it 
and why not put it there for wine too?

As for the reordering algorithm, that should be implemented in USP10.dll 
under (ScriptLayout, ScriptStringGetOrder etc.). I don't see anything 
wrong with Uniscribe depending on ICU for the time being, in any case.

>>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.
>  
>
The reasons I stated against ICU are exactly what's haunting us now. 
It's too big, it depends on the C++ runtime, and you can't dynamically 
link it. Other than that, it's a great library. I'm just hoping that if 
another DLL had these problems rather than GDI, end users would suffer 
less. Particularly if that new DLL was a soft dependency, (as LPK is in 
Windows, BTW).

Fribidi would have been great, if only it supported UTF-16. It doesn't, 
and adding UTF-16 support is non-trivial. There were structural changes 
that were meant to take place to make UTF-16 support easier, in which 
case I was planning on implementing it upstream. It is also easy to 
dynamically link fribidi. However, these changes are taking their time 
in happening, so we use ICU for the time being. None of this translates 
to "we'll write our own".

As for taking one of those code's and making them our own, I simply 
don't see what's there for us to gain. ICU is C++, nothing we can 
reasonably do will change that. Fribidi is difficult to add UTF-16 
support to at the moment, so we gain nothing there too. Writing our own 
is a headache of magnitudes I don't want to even think of.

>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.
>  
>
Because BiDi already has a well determined place in Windows. That place 
is uniscribe. Uniscribe does a little of the other things as well, but 
quite frankly, not much. At least not that I could make out. As such, I 
vote for implementing stuff where it should be. This also has the extra 
benefit of making uniscribe the one depending on ICU, not GDI. Assuming 
GDI's dependence on Uniscribe is through LPK, and that LPK is a soft 
dependency, this means that users that don't have the right C++ runtime, 
don't want the extra size, or can't get ICU depending DLLs loaded for 
whatever other reason will still be able to use Wine (though not 
Uniscribe, which I think is only fair).

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/