No subject

I see isn't documented. From the documentation, I would have expected 
the Wine code to work - it doesn't seem unreasonable to me.

I think the FreeBSD kernel code needs to change. If this is to happen, 
it will only be in the FreeBSD5 tree. It is too late in the FreeBSD4 
branch to make that sort of change since it's not really a bug fix.

To get Wine to work on FreeBSD4, there needs to be a way of making the 
reservation code optional. A simple mmap test in configure which 
snaffles memory above 0x80000000 and then tries to mmap some more memory 
without specifying a fixed address would detect if mmap is behaving in a 
way that would allow the Wine reservation code to function.

For FreeBSD5, which will become the stable branch sometime soon, I think 
the kernel code needs to change. I have a FreeBSD src commit bit, but 
I'm not a vm person, so I can only prototype a change and submit it for 
review. I'm not sure if the other developers will regard this change 
favourably, though. They may take the attitude that if Wine can be made 
to work with the FreeBSD kernel code as is, then Wine should be coded 
accordingly.

If the Wine code was restructured to make the reservation code optional, 
that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap 
algorithm was to change in the future, the build could start using the 
reservation code at that time.

Alexandre didn't want that fix for FreeBSD4, Well, there's a reason for 
that reservation code, and it's that some Windows apps require it; so 
unless you find some other way to ensure that FreeBSD never allocates 
anything above 0x80000000, the reservation code can't really be made 
optional.

So... that was the status last month and no one has mailed the list to 
report any updates since then. If you're on FreeBSD 4.9, things will 
break if you upgrade to 4.10. If you're on 5.2 things are broken.