Steven Edwards wrote:
Hello,
We are looking at porting more code from WINE to ReactOS and I am
having trouble understanding the need for libwine_unicode as a shared
library. Some of the functions that it exports such as CompareString
are implemented in ntdll as RtlCompareString and then also used in
shlwapi as per a recent patch. Wouldnt it better to import the function
from ntdll and hide libwine_unicode or make the parts that we need to
share a static library? In ReactOS we have created NT compatible NLS
files. Could WINE do this also and dump libwine_nicode?
We won't drop libwine_unicode (because we use it other pure unix
programs, so using only ntdll isn't a solution). However, as the process
of separating ntdll and kernel32 isn't over yet, NLS functions haven't
looked on so far. So, removing wine_unicode from kernel32 and using only
ntdll's exports could be a target. But, this isn't obvious and may
require some tweaking (especially at process startup time).
Also I was looking at the HeapAlloc stuff in WINE and code we have
ported from ReactOS such as the FormatMessage function in kernel32.
Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc?
Can we submit patches to WINE so that everything just calls
RtlHeapAlloc so we dont have to change the sources?
That would be doable yes (at least in kernel32). In other DLLs, it's
more arguable, especially if we want to test them on non NT systems.
A+
--
Eric Pouech
