On Fri, 21 May 2004 12:58 am, Francois Gouget wrote:
On Thu, 20 May 2004, Mike Hearn wrote: [...]
This is no longer true. According to a Red Hat kernel engineer, you can use "setarch i386 wine ...." to switch it back to the 3/1 split while we fix it in the Wine code.
Don't we have the same problem with the 3/1 split? If I remember correctly we can get into trouble if anything gets loaded above the 2G mark, depends on the application.
As one who has been bitten by this for several years I can say that many (Most) windows apps dont care where their pointers point. Simply changing ADDRESS_SPACE_LIMIT does actually work in many cases and making this configurable will make wine usable in these environment even if it breaks some naughty applications that depend on the 3G/1G split!!
From my recollection this limit is only tested for heap allocation which is
specifically provided by and anonymous mmap, presumably for performance purposes.
The proposed solution for this has been to prevent mmap from allocating over the 3GB mark by reserving any free space over that limit with a chain of mmap calls.
At least under Solaris there would appear to be two other "nicer" ways to achieve the same result.
1. Allocate the windows heap with a call to libc malloc which at least under Solaris maps memory from the stack top upward in memory.
2. For each mmap call locate a suitable unmapped memory area and then mmap FIXED that area, a technique already used successfully in the Solaris specific mmap code.
Of course none of this will prevent DSOs being loaded above the top of memory but. from the wine codebase only the heap seems to be at issue.
For what it's worth I can't see Microsoft retaining this architecture since the windows split is not likely to be the same into the future for example with AMD64 and probably was different even for Alpha. I also acknowledge that Alexandre and I disagree on this particular point.
Bob