https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #6 from Adrien Fernandes adrien_fernandes2@hotmail.com ---
This is actually a somewhat infamous issue and it's much older than that.
Yes, I meant 3 years of Wine on FreeBSD FOR ME and always had this issue so I suppose it is older than 3 years.
Is there a noticeable difference in virtual memory allocation?
Since it always worked like a charm on GNU/Linux, I never investigated it at that time. I remember making a Call of Duty World at War server on Arch Linux and playing it with my cousin and my brother for hours on maximum settings. It was back in 2013 and it was already working well.
But what I remember too is that I already wondered why FreeBSD was acting like that with Wine in 2016. I remember I booted up a Debian live to check and my physical memory for 32-bits was something like 3,0G, not 4,0G (I can confirm if it's an important detail). Wine is not the only affected software. PCSX2 on FreeBSD is also crashing because of "out of memory"
By the way, I forgot to mention my CPU :
- CPU - CPU: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz (2394.51-MHz K8-class CPU)
The usual workaround involves either setting LARGE_ADDRESS_AWARE flag on the executable (which tells Wine to apply a different memory allocation limit) or patching Wine to the same effect. Proton even has a convenient >PROTON_FORCE_LARGE_ADDRESS_AWARE environment variable for that matter.
So what's the next step ? Is there any chance Wine sees the LARGE_ADDRESS_AWARE included in its code for BSD projects (because I suppose NetBSD and OpenBSD experience the same) ? Is the patch available somewhere ? My computer would gladly be used for test purpose. I'm a daily Wine user of FreeBSD.
In my experience this workaround results in lower virtual memory allocation by roughly 700 Mb - 1 Gb. It's not clear to me how it does that, it's really not supposed to.
It lowers the virtual memory allocation, yet it is supposed to make the games not crashing due to memory allocation ? That's an upside down situation !