I could compile wine 1.1.19, 1.3.37 and 1.5.3 (with several patches) in my OpenBSD 5.0, but it's not run. Only run in the old wine version (1.1.19).
Qemu is very slow but if you install kqemu (QEMU accelerator module):

pkg_add -vi kqemu

If you want to load this kernel module at boot time, add the following
lines to /etc/rc.securelevel :

Necro and blatant advertising aside, I'm gonna say something that probably won't go over well with a lot of people but it needs to be said.

The next time you feel the need to complain about OpenBSD not having a port/package for something, don't. Instead, go read the Porter's Handbook and write up the port yourself. It's really not all that difficult and it's OK if your first couple of ports really aren't that good. You will get helpful comments back and you will get better at writing up ports. And then, magically, that thing you were gonna complain about will be supported by OpenBSD.

Anybody can write up a port. Yes, it's work. But anything worthwhile is work. And you just might find that you enjoy it. And at least then you can say you tried, even if it fails. That's a lot more useful than just complaining. And maybe, just maybe, you'll prevent someone else from complaining in the future.

The next time you feel the need to complain about OpenBSD not having a port/package for something, don't. Instead, go read the Porter's Handbook and write up the port yourself. It's really not all that difficult and it's OK if your first couple of ports really aren't that good. You will get helpful comments back and you will get better at writing up ports. And then, magically, that thing you were gonna complain about will be supported by OpenBSD.

Anybody can write up a port. Yes, it's work. But anything worthwhile is work. And you just might find that you enjoy it. And at least then you can say you tried, even if it fails. That's a lot more useful than just complaining. And maybe, just maybe, you'll prevent someone else from complaining in the future.

Wine will be difficult.

I took a stab at it years ago, fixed a couple superficial compile errors but then it got hard. I don't recall the details, but someone else who was working a little on it wrote something about differences with mmap and wine wanting to put things at a fixed address or something like that. Windows makes assumption about how virtual memory is laid out IIRC (e.g. > 2GB belongs to kernel, depending on certain settings, including settings compiled into the application binary!). Seems to me there were issues then with lack of kernel threads then too, which shouldn't be an issue now (though maybe there's some work to port to OpenBSD's threads?).

FreeBSD did it because someone did the work for FreeBSD. You can probably look at their mailing lists to gauge how much work it is. Then again there may be things in OpenBSD that make it harder, I don't know.

I've had the thought to try again sometime, but now I'm running amd64. I'm not sure 64 bit windows support is worth anything to me. For that matter, I'm not sure how well wine works with 64 bit programs. Running win32 wine on amd64 I think will always be impossible. Unless I'm mistaken, OpenBSD has made the design decision never to support 32 bit programs on amd64 arch. IMO that's good. When I used slackware I found annoying little complications and clutter caused by the need to support both kinds of binaries, e.g. the names of the library directories. Why even bother when you have the source and can recompile/port? I can see it if all you have is binaries but that's not a use case worth spending much effort to support IMO.

But by all means give it a shot. If you do make sure to scan the ports mailing lists for past efforts and make sure you're starting with all patches done before. I don't know if everything is in the current port or not.

Sure. I don't necessarily disagree with that. Virtualization is definitely difficult but that doesn't mean it's impossible. Personally, I'd prefer to see someone port Virtualbox over Wine, but that's just my opinion. My original point was that fly-by complaints without work attached are better off unsaid.

Quote:

Originally Posted by thirdm

FreeBSD did it because someone did the work for FreeBSD. You can probably look at their mailing lists to gauge how much work it is. Then again there may be things in OpenBSD that make it harder, I don't know.

Right: my post is to say the same thing applies for OpenBSD. OpenBSD will do it when someone does the work for OpenBSD.

Quote:

Originally Posted by thirdm

But by all means give it a shot. If you do make sure to scan the ports mailing lists for past efforts and make sure you're starting with all patches done before. I don't know if everything is in the current port or not.

I wasn't advertising that I am going to do anything. I have a long-standing policy of not taking port requests. Wine/virtualization isn't my itch.

My original post was designed to slow people down from knee-jerk complaining. Instead of complaining, think: "hey, maybe I can do something." And then do that something.

Blah, this is probably too off-topic. So let's get back on topic with the next post.

Porting Wine to OpenBSD would require introducing unsafe third party changes into OpenBSD kernel. The topic has been discussed to dead couple years ago on various mailing list and is closed. It is not going to happen ever.

Btwn if I could get M$ Office to work correctly under Wine on RedHat we could literally be 100% Windows free in my Lab.

Porting Wine to OpenBSD would require introducing unsafe third party changes into OpenBSD kernel. The topic has been discussed to dead couple years ago on various mailing list and is closed. It is not going to happen ever.

It doesn't look hopeful, but I'm not seeing quite that take on it looking at either the ports mailing list or the cvs history:

... only that the credible people working on it aren't anymore, and therefore the port's been removed from source control.

Where's the discussion saying they wouldn't take a port if someone somehow managed one, or that base changes are required that wouldn't be accepted?

I believe I have seen that discussion on Wine mailing list among Wine developers who were making Wine changes to enable OpenBSD compilation. Only one or two OpenBSD developer were CC if I recall correctly. Beat me up if I could remember the names.

The #1 reason why the Linux team has not commited this by default
is because it breaks Wine, which wants to play with page 0 -- so
basically they are resisting this for Windows binary compatibility
Ironic, isn't it? If anyone else tells you that is not the #1
reason, they are lying. We decided we don't care about Wine.http://lwn.net/Articles/360312/

... but here is the suggestion that perhaps allowing processes to map their own zero page isn't really required except for Wine's DOS emulator (and if you need DOS there are better solutions than Wine)...