epoll, LSB (was: Re: Problem roundup)

[Dmitry Timoshkov]

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

> 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".

One of the reasons why Alexandre decided to add unicode support in wine_unicode
is that it's completely not documented how it's done in Windows, especially
since it's implemented differently in different Windows platforms. It would be
plain stupid to create another custom Wine dll while already there is a place
for that stuff.

> 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?

See above.

> 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.

As soon as you or anybody else implement uniscribe APIs you can start
arguing where to place core of it. But still, personally I don't see
nothing wrong to implement it in wine_unicode and use that as a backend,
as currently done for everything else like FoldString or CompareString.

> 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".

What do you mean by that? Why adding UTF-16 is not trivial? For the starters
we can completely ignore surrogates, and Windows does not have unicode chars
above 0xffff anyway.

-- 
Dmitry.