I have checked the Wine spec files against the list of APIs exported by the various Windows libraries and started on resolving the discrepancies.
One of the (smaller) things I found is that in Win2000 and WinXP the LZ API is implemented in kernel32 and lz32 only contains forwards that point to kernel32. In all other Windows version however, the LZ API is not available from kernel32 and is implemented in lz32.
What should we do? Should we have kernel32 import lz32 and forward the LZ functions it? Or should we do like Windows, which means moving the LZ APIs to kernel32, and turn all the entry points in lz32 into forwards pointing to kernel32 like on Windows?
On Tue, Dec 10, 2002 at 01:06:54AM -0800, Francois Gouget wrote:
I have checked the Wine spec files against the list of APIs exported by the various Windows libraries and started on resolving the discrepancies.
One of the (smaller) things I found is that in Win2000 and WinXP the LZ API is implemented in kernel32 and lz32 only contains forwards that point to kernel32. In all other Windows version however, the LZ API is not available from kernel32 and is implemented in lz32.
What should we do? Should we have kernel32 import lz32 and forward the LZ functions it? Or should we do like Windows, which means moving the LZ APIs to kernel32, and turn all the entry points in lz32 into forwards pointing to kernel32 like on Windows?
If the LZ APIs are exposed from kernel32 ... Then I would say yes.
Will the forwarding work for the 16bit version too?
Ciao, Marcus
On Tue, 10 Dec 2002, Marcus Meissner wrote: [...]
What should we do? Should we have kernel32 import lz32 and forward the LZ functions it? Or should we do like Windows, which means moving the LZ APIs to kernel32, and turn all the entry points in lz32 into forwards pointing to kernel32 like on Windows?
If the LZ APIs are exposed from kernel32 ... Then I would say yes.
Will the forwarding work for the 16bit version too?
I'm not sure. I don't have the export tables of the 16bit libraries so I don't know what XP does. I'm hoping that if krnl386.exe does not export the lzexpand API then we can cleanly separate it in lzexpand by just calling the 32 version.