Dimitrie O. Paun wrote:
On Thu, 15 May 2003, Shachar Shemesh wrote:
The attached patch is adding a new DLL, called "winelpk". This DLL is meant to replace a Windows undocumented DLL called "LPK.DLL", or Language Pack. LPK.DLL implemented the BiDi for GetCharacterPlacement, DrawText, EditControl and so on and so forth. As the interfaces there are undocumented, however, I changed the name of the Wine DLL, to avoid confusion and attempts to replace one with the other.
This doesn't make sense. If we're not compatible with LPK, why add a DLL in the first place, and not implement those functions in their respective DLLs?
It makes a LOT of sense to implement it in a different DLL. It just doesn't make sense to rev-eng their interface. They missed up an important flag on GetCharacterPlacement, which means it is practically impossible to use it as is. This, in turns, creates strange dependancies, that can only be easily solved by placing unrelated stuff into a single DLL.
When I started working on GetCharacterPlacement, and found out about that incompatibility, I was a bit confused as for how Windows did it. The answer is that it concentrates everything into a single DLL, and does everything in there using undocumented interfaces. We don't want to replicate the interfaces, but putting everything into a single DLL does make sense.
The idea is that all the GDI APIs are complete without this DLL, except they don't support BiDi. All BiDi operations are done in winelpk.dll. Plugging out this DLL will leave you with a functionally complete Wine. My original idea, though it may still be amended, was that this DLL will fail to load if the supporting libraries are not present on the Linux/Unix enivironment, leaving Wine BiDiless, but functional. Because of the fact that LPK uses GDI and User32 functions, I don't think dynamic loading can be avoided anyways, so we might as well take advantage of this.