Wine ported to OpenBSD
marc.info
marc.info
Disco Elysium https://video.gamerstavern.online/w/qYjXr8dBauynzvEquJ7cP4
Hollow Knight https://video.gamerstavern.online/w/8tjjFRDtGJQZwxfE4ojVoC
Prey 2017 https://video.gamerstavern.online/w/vNxVThRcpijbT9FAQPcKdz
Death Stranding https://video.gamerstavern.online/w/rzz2TLCxcmneHsydukAFLU
Witcher 3 Remastered https://video.gamerstavern.online/w/oZcTRKL5JMiU4M4FqGKcNH
According to the reddit post:
AMD Ryzen 9 9900X, 16GB RAM, AMD Radeon RX 9070
For those not familiar with OpenBSD, it’s had an accelerated amdgpu driver since 2019, and inteldrm/radeondrm for a few years longer, generally kept up to date with Linux stable throughout that time.
Since many years longer, including the nv(4) driver for old Nvidia GPUs up to the earliest GTX models.
There is no kms drm or 3D acceleration for nvidia on OpenBSD.
Over time there can be periodic drift and out of date drivers until they re-sync, but it usually works pretty well.
But that is freebsd, not openbsd. I couldn't imagine it on OpenBSD because the priorities are very different
Subscription-based licensing requires periodic check-ins, but perpetual product key-based licensing is available, though compared to the subscription versions, the release cadence for new features is slow.
The online component of traditional apps like Excel works best as a means for sharing documents, with the web UIs useful for reading and light editing, and the same documents fully editable in the native apps.
recent only office builds are not quite there, but far superior to office Web.
(Its presentation is so stiff that I refused to play it - it's supposedly a very good game, but I just couldn't bear playing what felt like MS Office)
Current Wine just needs a couple of fixes from upstream libxml2 to be able to use the Retail C2R (Click-To-Run) installer, then the apps themselves work fine with a few Direct2D patches (see the effort to get Paint.NET running).
The real issue is that getting activation (even using MAS tooling) working requires a real Windows kernel running for the Warbird-protected activation system, after two weeks I gave up, 99% of my MSO needs are provided by Artcraft now anyway...
> 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.
It polarizes people to either join the "the LLM is my god" crowd or the "if AI touches the repo, it's all slop" crowd.
The careful balance is rarely discussed, probably because that's the part that still takes work.
Agents and LLM-assisted coding currently work within the confines of already working hand-coded OSes, language frameworks, test harnesses and even CLI tooling. Pull one of those out, and agents become unhinged and they lose direction.
https://events.eurobsdcon.org/media/2026/submissions/ZGDXQR/...
Talked to bluhm@ after that talk in Brussels and the general feeling (from what I can remember from the conversation) so far is that there is a large increase in overall reports (good and bad), but that the severity of what is reported has not really increased. This also mirrors my own experience from reading source-changes@. In essence, it seems like we have known how to build secure software for the last thirty or so years, just that most do not seem to have bothered to do so.
Theo de Raadt would spin in his grave — after the security implications of this to OpenBSD gives him a fatal aneurysm.
Either that, or he'll surprise-launch OpenLLM, a model bundled in the next OpenBSD release that produces driver code free of security bugs.
Isn't he still alive?
you could have the driver code prove it implements a spec, that there's no UB, that hardware invariants are maintained, that routines take a fixed time to execute.
the formal driver spec must still be written by sober, well-caffeinated humans of course.
Posix is more an art form documenting the far gone past rather than a practical tool
We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any macOS machines for testing. But we seem to do well enough with a shared system that Adélie Linux kindly allows the compile farm [1] to use, along with some additional CI machines.
Apple can't distribute them - coreutils is GPLv3, which is incompatible with Apple's immutable system volume.
https://www.gnu.org/licenses/gpl-3.0.en.html#section6
(There are other issues with GPLv3 which make it a dubious choice for companies like Apple, but this one is particularly problematic.)
But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.
I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.
Personally, I'd remove even the POSIX [-u] flag from all cat versions because all of them are un-UNIX-like.
Some GNU tools are particularly ridiculous with the Easter egg features I only know about because LLMs use them all the time —and I have been using Linux for 30 years.
The restarting of the counter on OpenBSD is not what concerns me. The merging of the first file's last line with the second file's first line is.
Someone could have thought it was a good idea and no one was willing to audit all of UCB's scripts to fix the "bug" even if it had been the result of a lazy implementation because ed(1) on a terminal.
So I wouldn't refer to it as "the design". It's not that the methods are unsound, it's that I don't see any method at all.
As for not wanting to break existing scripts, OpenBSD is not even remotely as concerned about backwards compatibility as Linux is. I don't mean that in a derogatory way. It's a perfectly cromulent choice.
Nothing in that post is against using an LLM. It's all about copyright:
>Since every file in OpenBSD has been continually verified to ensure correct Copyright, and we've even deleted code which has incorrect Copyright, the chances of us accepting such new code with such a suspicious Copyright situation is zero.
Once the current bubble pops we're going to see a lot of litigation over copyright enfringement by LLMs. Currently no one wants to rock the boat because everyone hopes to make a trillion dollars from AI, Oracle included, once they see they can't the knives are going to come out and I wouldn't want to be Linux at that point: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America
Also my personal opinion about copyright _in the FOSS domain_ is that I simply dont care. Copyleft as the GNU folks like to call it is just using the copyright laws to achieves certain free software objectives. If that doesnt work anymore there will be another fix
The BSD licences are not copyleft, or indeed part of the GNU copyright regime.
Copyright is dead.
I remember hearing that in 1996 too.
It took a while for the DMCA to happen after Napster. But it indeed happened, and we all know the saying about history repeating itself.
By the time they came for Napster technology had already moved on. I can still download entire albums and movies in minutes 2 decades later. Heck, Usenet is still a bastion of piracy and that's been around for 46 years.
Yeah, but you cannot do so legally; you can't build a business of it. The AI companies are trying to build a business, not download movies for their kids to watch during school holidays!
The 90s young people are familiar with are... way different from the 90s I remember. Their understanding of it is like... if someone asked to AI-gen the decade.
I suppose my point still stands if you are willing to stretch back to Usenet, BBSs, etc. as an inflection point in mass copyright infringement.
You may not care, but if the OS you prefer to run is the defendant in a copyright case, that's likely to impact you in a negative way.
"Those that do not learn history" and so forth.
I mean, it's not like the BSDs stagnated and lost ground to Linux because of copyright lawsuits... oh, wait!
There's only two ways for copyright to go, either by being tightened up or by being loosened.
When has copyright protections ever loosened? We've got hundreds of years of copyright laws in multiple different jurisdictions, and I can't think of when they were, for all practical purposes, loosened.
If they are loosened, then sure, the AI companies win big here. If they are tightened, AI itself becomes almost useless (derivative of current works).
The slop problem is very real. People are spewing reams of bad code that generates entropy faster than humans or LLMs can clean it up. LLM best practices are not yet obvious, and we're still figuring out how best to leverage them while maintaining code quality and human understanding.
... but LLMs are coming whether we want them or not. Models keep consistently improving, the slop keeps getting better, and human-only development is going to struggle to keep up.
In my day job, I'm driving an enormous number of tokens at Astra+Ultramax solving problems in Lean 4 that previously we never would have attempted simply due to the incredible human engineering cost; we review the high-level lemmas and let it prove the rest.
LLMs are the only solution I've seen over these decades that could finally close the feature/usability gap between mainstream and more niche operating systems -- software support, features, drivers, and other broad usability barriers. All of that has historically been far too much work for a much smaller developer community to reasonably undertake.
Hating AI isn't going to make it go away.
Think about how far Linux has/hasn't come in the last 10 years. The user experience is nicer, drivers "just work" more, there's more support for more stuff...but at the end of the day, the actual computing experience is mostly the same today as when I installed Debian back in 2016. It's polish, interoperability, etc that's improved.
Maybe VR takes off and takes over the desktop, and then openBSD can't keep up with that, but I don't think that's likely. So what are they trying to "keep up" with?
In this case, reading the link you're replying under, it's being able to mount a disk formatted with a popular filesystem. The alternative here is waiting for a human to type this relatively "solved" problem, as a procedural requirement, more than anything.
So, it can easily mean "things won't work in this OS". But, that's to be expected with FreeBSD, for legitimately good (from the perspective of FreeBSD) reasons.
Whether you like this new reality or not, it is an objective fact that LLMs are the silver bullet Fred Brooks told us didn't exist—multiplying development speed by 10x or more—and that if you're not using them you are hobbling yourself. This especially goes for a "security-focused" OS like OpenBSD, because AI is more diligent about finding vulnerabilities and can do so without rest. Meaning that if you're serious about security, you are using AI to harden your software... and if not, someone else is using it to hack you.
That is not remotely an objective fact. It's an opinion, and it isn't even an accurate assessment of the tech at that.
I'm sitting here watching astra do in a day what would have taken me at least 3-6 months. The code is verified correct. The model finds, reads, understands, and then integrates the latest literature into its designs and plans. It implements the code, proves it correct, and has come up with its own novel solutions on top of the state of the art. It then refines its implementation to hit the performance goals I give it. This is the reality today.
I've got some bad news for you.
We're solving problems now that we never even would have attempted previously. We couldn't have even staffed them if we wanted to. Even if we had the people, it would be years of development before we saw usable results.
If you can't understand how this kind of work would take a human with a few decades of experience 3-6 months, you're the 0.05 developer in my world.
[[citation needed]]
Ppl praise the stance of OpenBSD/NetBSD and what-not. That's commendable, but then close the tab, open their spotify and get back to agentic programming for their proprietary company source. But God-forbid if OpenBSD turns anything more than a museum OS, full of purity but with a user-base of five. Because the GPU doesn't work properly, the sound drive is clunjy, wifi might work, etc.
LLMs could port huge amount of drivers to both system with a fraction of the effort. Specs can be implemented easily and properly. Then of course, you need to test and that takes time, but it's technically easier and more ppl could contribute.
I get the feeling, but they're not OpenBSD a favor, if anything else I feel the exact opposite is happening.
As someone who has to professionally deal with AWS's feature breadth, this does not hit the way you expect.
Hahaha, fair! I meant feature-wise :-P
Meanwhile OpenBSD will get 9front's GeFS stabilized and it will work on a fraction of what BTRFS needs to function, and don't let me start on ZFS.
Could, but they don't. Latest Linux versions give compiler/linker errors (undefined references) which speaks great lenghts about the code quality.
one of the reasons that BSDs are less popular is because of the community advice of "The best supported machine is a ten + year old thinkpad."
so yeah you're right there isn't a finish line, but you do need to keep up with current stuff enough to give a possible fan base a decent selection of hardware to run the thing on.
in other words : if the companies that the BSDs already had a hard time keeping up with hasten development via LLMs the gap will grow ever wider until a critical point is hit and the thing becomes irrelevant.
if linux is the only show in town that supports flashy-hardware-Z then it's going to drive audience migration.
the thing that has allowed openbsd to adopt new things so slowly is a rock-solid set of core competencies; the amount that bsd is entrenched into the internet itself makes irrelevance hard to imagine -- but it's still a facet.
I still hear people bitch that BSDs don't support WiFi, and that hasn't been true in years and years.
https://www.reddit.com/r/openbsd/s/k0dz2WrkCo
In that thread I suggested he submit it to the ports tree, I'm not sure if he took my advice or came up with the idea on his own. At any rate this is cool.
> I had some success in porting Wine to amd64.OpenBSD. Was able to run a few = games. But that required in memory patching of %gs commands (LLM's suggesti= on and 1st implementation, then I re-did it from scratch - I'm not that sma= rt with amd64 assembly code)
Also, it's not a single author. Other people contributed significantly and their contributions don't seem written by AI: https://github.com/NethIafin/wine/commits/openbsd-master/
[0]: https://marc.info/?l=openbsd-tech&m=179070255546118&w=2
I also respect Wine and OpenBSD and their rules to not have any LLM code in the repo/ports. So my approach was to iterate over solutions, find approach that works, ask AI to "just see if my idea even works", learn what/how/why of that approach, generate some supporting manuals for myself (for example how to decode %gs instructions and how to reencode them) and then write my own code based just on decoding tables (and not LLM code).
I did not know how to work with REX/SIB/ModRM, how to detect prefixes, how to parse every single instruction that contains %gs, how offsets work, how to encode jmp rels, why I want to use JMP *0(%RIP) instead of JMP 32rel on return, why I want to leave stub on SIGUSR (or any other signal). But I do know now.
I was incredibly lucky that patching just these %gs instructions were enough to launch Factorio and play, with broken sound, but anyways! Holy molly this was and is so much FUN!
The approach still feels like cheating, and if it feels the same for you, I perfectly understand.
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?
My guess is they based this on the similar NetBSD port but I don’t know where the repo is.
Edit: sibling commenter found it
[1] https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/wine
On the whole it looks well written to me, especially with how complex & low-level these areas of Wine are. Good work to the author. I'd encourage them to try upstreaming it if they're interested. Some of it looks a little hacky, which upstream will object to, but maybe they could get some help cleaning it up, which will avoid having to maintain a diff and result in an even better port.
Edit: Oh, looks like they already talked with upstream https://marc.info/?l=openbsd-ports&m=179241414029592 It's not a huge diff to maintain, so maybe that is the better route. Great work either way.
Rest is basically ~~two~~ three main issues 1. %gs/gsbase - we trap on %gs instructions because %gs=0 gsbase=0 so all of them illegally point at page zero. So we take the instruction, decode, turn it into %gs-less instruction, and stow it somewhere else. To do conversion we need a scratch register (now two, thanks MINGW32-GCC, you c*nt), we replace whatever gsbase should've been with our TEB pointer, and gogogo (with restore of the scratch register state {or two}). Old instruction (if wide enough) becomes jmp rel32 (I picked it because it is 5 bytes, and short jump branches are too... short). If it isn't, we are just constantly trap on that so we just create a hash between trap location and stub location. Those cases are thankfully rare.
Just this one patch gives us Notepad, Notepad++, Factorio, and many many other games
2. SIGUSR1. Basically Windows lets threads chat thru their thread API, and Electron apps (I really wanted Eve Online to work) and Chromium apps constantly chat and interrogate each other with that thread API. Wine decided to emulate some of the APIs with unix signals. Now the main issue here is that OpenBSD, does not allow one process to signal a thread in another process. So we catch it with the currently active thread, and reemit it now inside of the process as SIGUSR2. Read on SuspendThread, GetThreadContext, ReadProcessMemory, and why Mojo/Crashpad works how they work, very fun! Makes you really enjoy the security OpenBSD gives you. Another dev is making this code better and handle other SIGnals.
3. ReadProcessMemory / WriteProcessMemory (NtReadVirtualMemory / NtWriteVirtualMemory) - this is also for Electron/Chromium but mostly Steam. We only needed it majorly when we started pushing towards steam working. Steamwebhelper, steam overlay, and steam watching you play and tracking your game time, are completely against OpenBSD's security model. Wine processes are not descendants of wineserver, so wineserver cannot ptrace them unless you enable kern.global_ptrace=1. We were trying to keep kernel as stock as possible so...
2 and 3 are very much together and if you ever seen on windows how chrome looks in the Task Manager and how many chrome processes there are, well now you know my pain, haha
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.
[1]: https://man.openbsd.org/nv
It is verifiable and has a clear exit criteria. Functional and performance parity.
Todd Howard probably
There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.
“what is {insert obscure tech thing}”
“why do people typically use {insert obscure tech thing}”
But of course, no one is born knowing, so here you go.
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.