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.