Re: Wine and mmap

On Sunday 12 September 2004 10:50 am, you wrote:
> On Sat, Sep 11, 2004 at 07:54:55PM -0400, Anish Mistry wrote:
> > On Saturday 11 September 2004 05:26 pm, you wrote:
> > > On Sat, Sep 11, 2004 at 05:07:13PM -0400, Anish Mistry wrote:
> > > > On Saturday 11 September 2004 02:00 pm, you wrote:
> > > > > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote:
> > > > > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote:
> > > > > > > [ John, sorry for the duplicate message; this is the correct
> > > > > > > one. ]
> > > > > > >
> > > > > > > On Fri, 27 Aug 2004, John Birrell wrote:
> > > > > > > > Anish Mistry <mistry.7_at_osu.edu> has developed a patch to
> > > > > > > > choose an appropriate mmap address. He posted it to -current.
> > > > > > > > I haven't had time to test it.
> > > > > > >
> > > > > > > Thanks for the note.  Will you have time to test/commit this
> > > > > > > before 5.3?
> > > > > > >
> > > > > > > Anish, do you have any news on this patch?  (Wine has been
> > > > > > > broken for a couple of months now, and it would be great to
> > > > > > > have at least 5.3 fixed.)
> > > > > >
> > > > > > Well I guess this is my lucky day.  Apply the attached patch for
> > > > > > vm_mmap to your kernel and patch the August wine sources with the
> > > > > > wine-mmap.patch and compile and install wine (be sure to use
> > > > > > gmake). This is working on my dev system with 6-CURRENT as of
> > > > > > Saturday night. The wine mmap patch just doesn't reserve the DOS
> > > > > > area so DOS programs may not work.  This seems to just work
> > > > > > around a side effect of the kernel mmap patch. I still think that
> > > > > > the kernel mmap patch has issues so I'm hoping Alan can give us
> > > > > > some feedback.
> > > > > > Anyway this worked for me, YMMV.
> > > > >
> > > > > Do these combined work for you, minus any modifications to mmap(2)?
> > > > >  I do not feel that the kernel mmap(2) should be modified in this
> > > > > manner, that it is a strictly userland problem.
> > > >
> > > > With only these applied I get old message that wine can't mmap it's
> > > > address space.
> > >
> > > Oh, I'm sorry for not explaining the last step.  You need to set the
> > > environment variable "LD_LIBRARY_LOW_ADDR" to some address, like after
> > > the first megabyte, or something like that, but before the first "data"
> > > address.  Try, say, 1024000.
> >
> > Ok, I've tried that, with several different numbers and I either get
> > something like:
> > wine: failed to initialize: /usr/local/lib/libwine_unicode.so.1: mmap
> > returned wrong address: wanted 0xc350000, got 0xc3bd000
> > or just the normal:
> > wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: mmap of
> > entire address space failed: Cannot allocate memory
> >
> > Any other suggestions?
>
> Oops, can you try this instead?  Can you share with me exactly how you
> run this "regression test" with WINE (what program, what .wine/config)?
>
Ok, this instead of getting the wrong address, wine just bails out with:
wine: failed to create the process heap.  The other message still appears if 
the load address is high enough.

This is how I'm testing:
I've downloaded the August (20040813) version of wine applied the patch to 
comment out the reservation of the dos area in a previous email (attached 
again, idealy we shouldn't apply this since having the stock wine work would 
be much better), and did a ./configure && gmake depend && gmake && gmake 
install.  I've attached my wine config file.  Then I just end the 
environmental variable you said and run wine.  I'm using Diablo 2 as my test 
app.

-- 
Anish Mistry