Hi,
On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation.
Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area.
This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it.
There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this:
wine: unable to create process heap
Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes.
thanks -mike
On Wed, May 19, 2004 at 09:46:50AM +0100, Mike Hearn wrote:
Hi,
On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation.
Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area.
This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it.
There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this:
wine: unable to create process heap
Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes.
Could it be that Redhat is trying to deliberate break WINE every half year ;)
Ciao, Marcus
On Wed, 2004-05-19 at 11:46 +0200, Marcus Meissner wrote:
Could it be that Redhat is trying to deliberate break WINE every half year ;)
Heh, you have to wonder don't you? :)
The annoying thing about this one is that the 4G/4G layout is actually harmful to desktop users (ie anybody who doesn't have 16gig+ RAM) as it causes anywhere between a 0-30% performance hit!
Given the total uselessness of this option to the people Fedora is targetted at I can only assume they're testing it for RHEL ...
On Wed, 19 May 2004 09:46:50 +0100, Mike Hearn wrote:
There is currently no known workaround for this problem short of recompiling your kernel.
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.
thanks -mike
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.
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
-
Francois Gouget -
Marcus Meissner -
Mike Hearn -
Robert Lunnon