Possibly crazy idea to deal with memory layout problems once and for all

[Vitaliy Margolen]

Friday, February 17, 2006, 8:57:06 PM, Troy Rollo wrote:
> I have been looking at a problem that has arisen in recent versions, 
> particularly when using some D3D games, in which the virtual address space
> above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you
> get an out of memory condition, even though you still have well over a 
> gigabyte free (even in a contiguous block!). This has led to some people
> using the attached hack (first attachment) to get their D3D games to work.

> After considering a lot of approaches to this problem that did not seem to get
> anywhere productive, it seemed that the only way to resolve it would be to
> get in between the application and any libraries, and the kernel. The 
> solution I came up with is somewhat rude, but if we assume that any libraries
> that Wine uses only call mmap() and associated calls via the C library, then
> it may well do the trick, plus make it possible to implement other virtual
> memory APIs more effectively (and in a couple of cases eliminate calls to
> wineserver).

> If wine_preloader were extended to have its own implementation of all the
> friends of mmap(), and to have its own implementation of the dynamic linker,
> then in principle it could make sure only its mmap (and not the C library's)
> is called. An even more aggressive approach might be to load the C library
> and stick jumps into its mmap that redirect to the preloader's versions. The
> preloader's mmap would keep track of mappings on its own and when it receives
> an mmap with a start address of "NULL", decides on its own what base address
> to use.

> Any thoughts?

You sure this patch has anything to do with the problem that you
describe? It looks to me that all it does is shrinks available amount of
memory for only one particular class of VirtualAlloc calls. Can you me
more specific about what is the real problem here? From what I know this
patch is to fix WoW (Blizard's bad assumption about place where memory
will be allocated). And possible few other games (that make the same
exact assumption).

So far I have not see a single explanation to exact reasoning behind this
hack. Also I haven't seen any comparison to native - what does it do?
When I tried to test this on windows - all my allocated blocks were
starting from the stack and up.

Vitaliy