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?
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.
I'll add one more point to the above.
There is a true dependancy problem between different DLLs here. When calculating reordering, certain character order information is needed, that is not returned by GetCharacterPlacement. This means a new interface must be defined.
The way MS solved that problem was to implement a totally new DLL, that has everything (both EDIT control and reordering), and have all relevant DLLs dynamically load it (because statically loading it would cause circular dependancies).
If Alexander rules that no new DLLs be added at this stage, I can put the new code as non-exported functions into GDI.DLL, but it will only hold until BiDi Edit control is necessary. I think we might as well add the new DLL now.
Shachar
Shachar Shemesh wine-devel@shemesh.biz writes:
If Alexander rules that no new DLLs be added at this stage, I can put the new code as non-exported functions into GDI.DLL, but it will only hold until BiDi Edit control is necessary. I think we might as well add the new DLL now.
I think you should start by putting that stuff into GDI, yes. It's easy to move it off to a new dll later on if this turns out to be necessary; and depending on what you need, libwine_unicode may actually be a better place for the character information than a Wine-specific dll. I'm not saying we can't have a dll, but I'd like to see some working code first.
-
Alexandre Julliard -
Dimitrie O. Paun -
Shachar Shemesh -
Shachar Shemesh