> I doubt much will be merged upstream. Many updates we have can technically
run on other OSes (%gs stubs won't be built on Linux because %gs is correctly set, SIGUSR1 will work but less optimally, etc). However I picked an approach where everything that is done for OpenBSD is just marked as OpenBSD only. I did that purely to simplify my life while I was working on it and clearly mark the changes.
> When I was talking to Wine maintainers a month ago, they were hesitant to accept even patching Wine so it compiles for OpenBSD, mostly because it's another OS they will have to support and keep operational, while the %gs stub fix is something they definitely cannot take upstream. They are very hesitant to take anything that is changing the "emulated" application code.
RunSettoday at 2:57 PM
Especially welcome news now that OpenBSD is shaping up to be a refuge from slopcode.
That has a static import from 13 hours ago. Anyone know if this wine port has its own repository somewhere else tracking the history of the development effort?
yass0today at 7:09 PM
I am sure this has something to do with all the PS5 jailbreak work that is massively happening recently.
Bluescreenbuddytoday at 2:51 PM
Good lord this is awesome
CodeComposttoday at 2:51 PM
That is awesome. I take it I can't run this with nVidia.
throwaway27448today at 2:48 PM
Out of curiosity, how much work/what sorts of openbsd-specific details must be addressed to get such a port working?
kogasa240ptoday at 7:16 PM
Impressive! Wonderful to see that the BSDs are getting love these days.
ericfrederichtoday at 2:51 PM
My first thought was this must have something to do with the development momentum around the PS5 but that apparently runs FreeBSD not OpenBSD.
imagetictoday at 3:32 PM
Yes. More of this.
shevy-javatoday at 4:04 PM
Now the BSDs are not so popular compared to Linux, but
I think this is great news as more eyes help here. Let's
have EVERYTHING from windows portable towards linux.
(I struggled with the 32-bit versus 64-bit stuff; this
should also be a prime goal for wine to make this a
trivial super-easy to solve thing for linux in general.
Back then when I ran into this issue, it was not trivial
to solve.)
raverbashingtoday at 3:40 PM
I wonder what's the state of 3D/OpenGL support on OpenBSD or if the games run into too many problems here
j45today at 3:36 PM
I remember reading once how far away something like this way to work - for all the time that BSD has kept servers and networks safer than other options, it's nice to see things like WINE making it there as well.
Its hard to not think of the possibility that BSD might offer new or different advantages to keeping legacy windows applications safe until there is a willingness to adopt or develop alternatives.
saurilabstoday at 3:22 PM
This is awessome!
athrowaway3ztoday at 9:06 PM
[dead]
ndbetoday at 2:42 PM
Insane work!
There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.
curatedmcptoday at 4:17 PM
[flagged]
hahahootoday at 3:16 PM
[flagged]
rskeenstoday at 3:03 PM
[dead]
qwe-se-123today at 4:52 PM
[dead]
ryanschneidertoday at 8:04 PM
Semi-related, but I was just thinking today I wonder what sort of performance improvements, if any, one could see by having one of the frontier models build a operating system from scratch that targets the subset of imports WINE uses as the standard library? Basically, build whatever syscalls (or shims) WINE and the open source vulkan drivers need and nothing more.
Probably outside the scope of what an individual could pull off on thier own in a reasonable time, but I could totally see for example Valve considering that approach for a later iteration of SteamOS.