Huw D M Davies wrote:
[snip]
> > You should not use malloc and friends at all because they are not
> > thread-safe. These functions should map to windows-equivalents. However,
> > these functions are, in principle, available in wine, but cannot be
> > accessed due to name conflicts with libc. Using the windows/process heap
> > would solve these issues.
>
> You have to be careful here though. X assumes that image data is
> allocated by malloc and will try to free it in XDestroyImage using
> free. In principle we can free any image data ourselves (or define
> our own DestroyImage function and hook it into the image function
> pointers). We must then not use XGetImage but XGetSubImage instead.
>
> There's also going to be a problem with XListFonts.
Yes, I know. The way to solve this once and for all is to provide
malloc() and friends in the core wine and make sure that the objects
containing then are linked *before* libc. We then write malloc,...
against wine's allocator (systemheap and whateverheap or map to
VirtualXXX()). The X-libs will then also automatically use our versions.
-- mymalloc.c --
void *malloc(size_t s) { return HeapAlloc(..., s, ...); }
void free(void *p) { HeapFree(..., p, ...); }
..calloc..
..memalign..
etc...
--
Then link with:
ld -o wine mymalloc.o <any>.o -lwine ... -lc
This works and is portable. It does involve carefull linking and not
juggling with link-order.
Greetings Bertho
