Hacker News

I'm really surprised VKD3D works out of the box. So many abstraction layers stacked on top of each other feel like a jenga tower on the brink of falling.

Whoa, openbsd has 3d hardware drivers? Only open source i guess, no official drivers?

What about the most difficult game of all, Microsoft Office?

Yes, unfortunately OpenBSD maintainers will have to keep this running for now. NetBSD is apparently in a similar situation. Perhaps their efforts can be pooled at some point if the patches don’t diverge too much.

OpenBSD will probably fall even further behind

Wow, I honestly didn't think HN would succumb to the AI := Slop perspective.

how do you think they made this wine port lol?

It's ironic that it looks like "frown"

I came here looking for your comment!

Probably being reserved for the OpenBrandSherryDaquiri rebranding.

I was (and partially probably still am) hoping that it will go upstream in some shape or form so I kept the original name.

I feel like there was some WINE-related thing called Port.

You don't know what OpenBSD or WINE is? I'm afraid that is on you.

Still waiting on 64-bit BonziBuddy...

Kaspersky though

"Still uses CVS", I mean, CVS worked twenty years ago and it still works today for all the platforms OpenBSD supports. If you prefer something else, that is all right, but here is emulators/wine on CVSWeb:

https://cvsweb.openbsd.org/ports/emulators/wine

In their official CVS they link to this repo: https://github.com/NethIafin/wine/tree/openbsd-master

They mirror to GitHub regularly, but development still happens in CVS. They are building “got” as a potential replacement that allows git-driven development while following OpenBSD’s idiosyncratic approach: https://gameoftrees.org/goals.html

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

The port itself doesn't mirror the wine code. It is just the recipe on how to build in on OpenBSD + necessary patches.

Nvidia support for OpenBSD is not really a thing [1]. With AMD and Intel, you have support for modern hardware in the tree [2,3].

[1]: https://man.openbsd.org/nv

[2]: https://man.openbsd.org/amdgpu

[3]: https://man.openbsd.org/intel

You can download the attachment and take a look at the patches. Wine already supports FreeBSD and macOS, so it's not tooooo crazy hard to add another BSD/Unix to the pile. Looks like there's a few Unix APIs that have drifted, so the patches add some #if OpenBSD style stuff to avoid using some symbols that don't exist on OpenBSD. The gs register stuff is by far the most complex bit. IIRC that register is used for thread-local storage on Windows, but for other purposes on other OS's, so handling access from win32 binaries to the gs register is a big problem when porting to a new OS.

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.

There are some basic OpenBSD-isms like ucontext, stack mapping, mmap, fix trap context so rest of the %gs patching logic even knows where to work.

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

> And one of the great things of having a Wine port is that It just works.|

Todd Howard probably

There's been hardware-accelerated OpenGL in OpenBSD for ages.