Solved The Real Solution ... Wine Q. --> Good enough to Use, or Nothing but Problems?

Doing my final client build of FreeBSD 13.1 RELEASE amd64.

Went through a big struggle with Wine around a year ago - see these posts:

WINE on FreeBSD 13 - Am I Just Wasting My Time?​


Now, just 8 months after the previous struggle and hard-won solution,
went to install wine and immediately ran into new problems.

Also, I notice my most recent FreeBSD manual does not cover running 32-bit apps on 64-bit FreeBSD / wine.

So, at this point, I'm starting to wonder...

Does wine work on FreeBSD 13.1 RELEASE amd64?
Or is this something that comes and goes, works and then breaks,
and so is not really reliable for production use in a business environment?
It is important to note that I am running an old 32-bit program on a 64-bit operating system, same as a year ago,
which adds complexity to the scenario.

Wondering if I should bother with Wine on FreeBSD or perhaps go another direction,
like some kind of a windows app server with something like remote desktop.
The thought makes me gag, but sometimes we have to do what we have to do.

Please post your own experience(s) with Wine on FreeBSD...
1.) How long you've been using Wine on FreeBSD,
2.) Running on FreeBSD 32 or 64 bit,
3.) Running 32 or 64 bit Windows apps,
4.) Your use-case and overall experience(s).

Thanks!
.
.
 
1. I used it since Summer 2019 so basically it was the first thing that i have tested on FreeBSD before i went to FreeBSD.
2. 64-Bit
3. Both
4. Gaming. Expierence: Quite good but if you need to report a problem it can be quite difficult because FreeBSD is not that popular and you have to investigate things mostly alone. Also for quite a while there a some FreeBSD specific problems (like wineserver or mmap: file_set_error() can't map error: Cannot allocate memory) that can be quite frustating when some apps used to work on linux with the same wine version.

The maintainers are do keep updating Wine which is nice but (correct me if i am wrong and dont want to be mean) it doesnt seem that they actually test or use them on runtime, since even very obvious problems must first be reported by normal users, which I think is a shame since it is self-evident that you tested this before you commit stuff or do I see that wrong? (Imagine doing this with GCC lol)
 
1. Around one year, since 2022.
2. 64-bit.
3. Both, in one case even in one game (I'm talking about you, Guild Wars 2 :p).
4. For gaming, usually everything works with default emulators/wine, emulators/wine-devel or emulators/wine-proton. But to cover more narrow cases (like mentioned in 3) I had to create my own version of wine, with additional patches: https://github.com/thindil/wine-freesbie. Usually, performance is the same or a bit better than on Linux. Comparison with Windows: depends on third party libraries (like DXVK). I'm also using some tweaks for the system, to work around a couple of FreeBSD specific bugs or to gain some performance: https://github.com/thindil/gameboost
 
I've been working on this all night.
Got it to install and run, with errors.
Got it to install my old Paradox desktop database program,
which as of a year ago ran great.
It now runs but with many errors.
No longer usable.

I have easily wasted 300+ hours screwing around with Wine over the past 3 years.
Only to see things that work, now no longer work.

I'm done.

Here is my final solution:

1. Run old MS apps from a windows app server, serve across the network
to a FreeBSD desktop using some kind of remote desktop. Hope to
investigate and implement next week.

If that doesn't work, then run it from a standalone windows box over in a very dark corner.

2. Work hard on getting Microsoft out of my life forever, and don't ever look back.

Isn't that why we're here in the first place?

Dave
 
Last edited by a moderator:
Back
Top