Re: Towards a working "wine". [long]

On 6/23/05, Martin Cracauer <cracauer_at_cons.org> wrote:
> > > Have you seen Martin Cracauer's mail ("My hacks to make the memory map
> > > fit") on emulation_at_ which deals with the memory map? Maybe it's of help
> > > here...
> >
> > No I hadn't seen them, thanks for the reference.
> > These won't help in this case: It's almost the opposite problem. I think.
> > Martin's hack leaves a gap between the data segment and the area that
> > mmap starts looking in for address space. However, because of the
> > format of the wine binary, it's data segment is very high in memory,
> > and the area required by wine's mmap actually falls inside it. i.e.,
> > Martins fix pushes out the starting point for mmap searches, but wine
> > needs hit dragged in.
> 
> If this is still a problem, can you be more specific what you would
> like to have mapped where?
> 
> I think I can force anything to map anywhere but I know zero about
> Win32 or how Wine works.
> 

I'm not sure if you've seen the original message, but the problem
arises from a combination of Wine trying to map a windows heap at
location 0x80000000, while locating the executable up at 0x77f00000.
My Win32/wine foo is also very weak, but I recall from debugging
windows code that the address space in that area is reasonably heavily
populated.

On FreeBSD the gap between the executable's end (where the data
segment is) and 0x80000000 range becomes the maximum extent of your
heap, because you can't extend the break beyond the mapped 0x80000000
area, which is too small for practical use with Win32 programs, given
that malloc() allocates its space via sbrk().

As I said, I'm not particularly strong on Win32 address layout, so
I'll defer to the wine authours' choice on what's best for Win32
compatibility. The problem is that they interact badly with our
malloc().

I suspect the ideal solution would be for wine to provides it's own
version of malloc(), given it is so sensitive to the mechanism used to
carve up address space, but malloc() is probably a better thing to
hack on than mmap() from the FreeBSD side in this case, removing the
dependency on sbrk() for those executables that need it (although my
previous hack is obviously woefully inadequate) I'll see if I can roll
some more acceptable patches for malloc().