Re: Question about libwine_unicode functions and others in WINE

[Jonathan Wilson]

> Ahhh forget the HeapAlloc stuff. That was my fault. Someone decided in
> a very drain-bamaged way to forward all the Heap* calls to the RtlHeap
> calls in the spec file rather than in the source so anytime we try to
> port Winehq sources for kernel32 that use HeapAlloc I was running in to
> problems using it internal.
No, thats not brain damaged.
Thats the way Microsoft does things. (at least on XP)
HeapAlloc doesnt exist at all, all it is is a forwarder to NTDLL.
Therefore, all the code in kernel32 should just call RtlAllocateHeap.
Given that kernel32.dll is very much linked to ReactOS and wont run 
anywhere else there should be no problem.

Any other code that needs HeapAlloc can just call it and will pull it in 
from kernel32.dll.

Problem solved :)
If there is an issue with code from kernel32.dll of wine that uses 
HeapAlloc, the solutions are:
1.implement ntdll.dll on wine and add RtlAllocateHeap to it. Then modify 
WINE kernel32.dll to call RtlAllocateHeap and also to forward HeapAlloc to 
RtlAllocateHeap. Since kernel32.dll of wine is not going to need to run on 
systems without RtlAllocateHeap, this shouldnt be an issue.
But, if there is some objection to this, you could:
2.add a macro to a rectos-only header that gets yanked into the WINE ported 
kernel code like this. #define HeapAlloc RtlAllocateHeap
That way, WINE can keep their HeapAlloc calls inside kernel32 (which one 
would assume they need for some reason otherwise point 1 above would be a 
valid solution) but things will compile on ReactOS without a need to make 
changes. Still, going the right way (i.e. adding RtlAllocateHeap to wine) 
is preferable.