ReactOS “Open-Source Windows” Manages to Run Some Battlefield Games | Hacker News Reader

ReactOS “Open-Source Windows” Manages to Run Some Battlefield Games

phoronix.com

138 pointsmarcodiego67 comments

On another thread an HN comment complained that Win32 was becoming standard API for games instead of Linux native, thanks to Wine.

The reply kind of opened my eyes. If Wine/ReactOS do continue the trend of becoming better more stable platform than Windows itself, thanks to Microsoft hell bent on destroying their reputation, eventually, Wine/ReactOS can even Embrace-Extend-Extinguish Windows itself.

A man can dream..

I really do believe it's possible. 10 years ago it would have been a pipe dream, but the dedication people put into making Wine and DXVK function properly is nothing short of astounding. Aside from high-performance studio software like NLEs and DAWs, you can pretty much expect everything to "just work" through Wine these days. From Bonzi Buddy to Battlefield, nothing seems to escape it's compatibility.

We need to implement WM_POINTER* support in the input stack somehow, though. If we had that, Clip Studio Paint would work fine with a graphics tablet. Probably even Photoshop.

Some hacking on Wine was able to get SAI2 running, but SAI1 is elusive due to the design of Wine’s wintab32 implementation; XI2 events only go to the window that is being interacted with, whereas wintab32 events can and often are pumped to hidden background windows (for reasons unknown to me, though I guess if the window is on a different event loop it probably helps to mitigate events lagging. WM_POINTER magically coalesces events when the loop is tied up, and lets you grab the coalesced events, so it has less of this problem.)

I’ve thought about it a lot, but… The Wine input stack is fairly complicated and I haven’t grokked it all. I do have some projects I made for (clean room) examining behavior of the WM_POINTER events though. (Also, testing for this will suck.)

>you can pretty much expect everything to "just work" through Wine these days

Oh... if only...

I can't remember the last time I tried to run a non-game application and it actually worked. And I try often - I can think of three instances in the past few weeks alone (if you want to know - Fusion 360, an internal .NET app from 2010 that by rights should have worked perfectly, an old DVD of Altium Designer).

Don't get me wrong, I'm extremely grateful for Wine. But perfectly compatible it ain't, not even close.

Something I found pretty interesting, in that same line of thought, is that the VKD3D developer apparently added a specific hack [0] to work around a game bug that causes heavy stuttering even on Windows systems, effectively making Wine/Proton a better platform to play this game than Windows itself.

[0]; https://github.com/HansKristian-Work/vkd3d-proton/commit/f39...

I thought graphics driver vendors often did the same for big titles?

they do, but this solution affects all cards (or hopefully does) across all card driver versions.

One example is folks stuck with the legacy nvidia driver. If the game can still run, they can still get fixes this way. It's nice when we can sidestep the process of waiting on nvidia or whoever in the various closed source drivers on both linux and windows.

Yea well for business users of Windows in the enterprise it’s very attractive to have a service and support contract with them.

On the other hand if ReactOS and or wine try to do the same thing then we could see some shift but I don’t think it is likely.

Eventually, there will be businesses offering support contracts. And if history is any indication, MS cannot out-litigate that future. RH/IBM rose despite SCO lawsuite. If the code is there and it works, people will make use of it.

Perhaps those creating developer tools etc can aid this scenario by making their "cross platform" story Linux/MacOS/ReactOS or Linux/MacOS/Linux.Wine, rather than Linux/MacOS/Windows.

This might also facilitate developing cross-platform support for the Win32 option in a VM rather than on a live Windows machine -- e.g. a ReactOS VM. Besides avoiding licensing issues, some kinds of developer on-boarding could be facilitated by just pointing them to an available VM, rather than a gauntlet of environment setup.

In a sense, all this points toward an alternate reference implementation for Win32, or at least some subset, for some purposes. And/or a possible phrase: "ReactOS-First" development on Win32.

I did notice this first hand when trying trying to play an older game under Linux natively (Enemy Territory: Quake Wars). The Linux binaries refused to function (IIRC due to incompatible user space ABIs), but the Windows binaries worked perfectly using Wine.

Ever since upgrading to Windows 11 on my relatively modern desktop, I have been tempted to replace it with ReactOS. I do not expect the 100% stability or compatibility, but my question is, what should I expect from it as a "daily driver" in a home (i.e. non-critical) setting? I do not intend to use any software from Microsoft (which is known to sometimes rely on some undocumented features and assumptions).

Unless you're content with a severely outdated browser and notepad for your productivity, ReactOS is not even close to a daily driver.

In my opinion, for production use it's currently best suited for use as a free virtual machine for old software that no longer runs natively on Windows. If enough APIs are covered, it can be an excellent replacement for an XP VM to run some ancient tools.

Do you mean that Firefox will not install or work in ReactOS?

Only the Firefox releases that supported Windows XP work on ReactOS, which was dropped in Firefox 53 in 2017.

Modern versions don't. There was an LTS version for XP that was updated up until relatively recently that still works, but I wouldn't recommend using that for a daily driver anymore.

In theory someone could take modern Firefox, figure out what essential APIs are missing, and contribute a set of fixes to get the latest LTS version of Firefox working again, but that's quite a complicated process.

JFYI, there is some work in this space:

https://msfn.org/board/topic/182647-my-browser-builds-part-3...

Don't want to be that guy, but honestly, what you are describing is exactly what Linux has to offer. Its a modern OS with modern tools unlike ReactOS, and its only downside is that it is not compatible with all Windows software, which you seem to be okay with. I recommend you give Linux a try, specifically Linux Mint.[0]

[0]: https://linuxmint.com/

Linux Mint is the one i always recommend for linux beginners

But why go to linux when alternatives are available?

FreeBSD is a great option for a modern stable OS that can run pretty much everything linux can. Desktop system is also easy to install via DarkMate[0] on vanilla FreeBSD or then go to e.g. GhostBSD[1] that has all the bells and whistles from GUI installation onwards.

[0]: https://github.com/broozar/installDesktopFreeBSD/

[1]: https://ghostbsd.org

> But why go to linux when alternatives are available?

Why go to alternatives when linux is available?

The question works both ways.

>FreeBSD is a great option for a modern stable OS that can run pretty much everything linux can

If you compile your own user space software or it's already ported, then yes. But it doesn't have the same driver or virtualization support Linux has. I haven't tried any of the BSDs on a laptop for about 4 years but power management was abysmal then.

Most of these projects - ReactOS, Haiku and even Hurd badly needs a 1.0 release. That would get them enough developer attention to achieve their more ambitious goals faster. They should aim for simple bare-metal booting reliably on 1.0. Get this done at least on hardware with open specifications. With this in mind, take them into beta with the intention of stabilizing bootup.

Haiku seems to be headed that way, though.

A lot of these projects require the rare resources of people willing to do the work for free.

HaikuOS is a hobby project, it doesn’t have the industry relevance to be serious enough for a solid release.

Gnu Hurd’s only benefit is having a micro kernel. Minix, QNX, and possibly other actively developers OS’s have that market. It hasn’t been updated in 6 years and will fade. There’s already Linux anyway.

Developer mindset is a finicky thing. Haiku has been around for 20 years, actually boots on large amount of hardware, now even has ports for Qt, GTK, X11, Wine and loads of other applications people are already familiar with. This year I handed over old Acer Aspire to a friend in need, slapped Haiku on it and he has a working computer. By all fairness, Haiku is already actually 'useable'.

But majority of indie OS mindset was suddenly captured over past couple of years by SerenityOS. It is a good project in itself, but goes to show 1.0 does not matter for capturing Dev mindshare.

SerentityOS really shows the power of community engagement. The project is extremely open and welcoming. The project releases often. There are official demos videos of progress both from the project leader and a community showcase of other contributors. There are developer interviews, office hours, and an active discord server. The founders now famous opening catch phrase is “hello friends” and other contributors now mirror that in their videos. The founder says that he is building the system primarily for himself but he very clearly sees the value in the community and comes as as extremely grateful for the attention and engagement. There are major contributors that basically learned C++ to contribute to the project and the founder trumpets that like a proud father.

ReactOS on the other hand is very opaque and unfriendly. The website goes without updates for months. There is a sparsely populated forum that is filled with hostility and frustration from the inner circle. The current release ( made not that long ago ) is based off a branch that the main development moved off of years ago. There is a wiki that shows what is appearing in the next release but it has not been updated since June 28. Most of the project discussion happens at chat.reactos.org but I am not sure how you are to know that even exists. To me, it feels like the project attitude towards the community is that they are useless freeloaders. People better than you are busy doing important work that you would not understand. Don’t bother them.

Another aspect of the end-user focus is that SerenityOS has an emphasis on producing working software that is useful. Despite its alpha state they are redesigning dialogue boxes and controls to be easier to use. Animations and subtle GUI effects are celebrated as are small usability features in applications. Despite it being a project goal to build everything from scratch, there is a large ports collection and some of the most notable live streams show the founder porting popular programs and games. While ReactOS cannot even bother to get a browser working, SerenityOS is creating one from scratch.

I have a huge respect for the ReactOS achievement but it is no great mystery why a project like SerenityOS has had more momentum. In my view, the way the ReactOS project is managed has absolutely held it back. I could say the same for projects like GNUstep unfortunately.

Projects like Haiku have not bottled quite the same magic as Serenity but Haiku is very community friendly and it shows. Haiku is also pragmatic and, while the goal is to mimic BeOS and to offer an alternative app platform they have built compatibility layers in order to port over apps. They even run WINE. Haiku also has a browser ( not totally from scratch ) and there is already a port to RISC-V. Despite not being at 1.0 yet, there has been a lot of emphasis on creating a working end-user experience.

I just realized that ReactOS is only 5-7 years younger then the Linux kernel. Both projects that feel like they have always been there. And while ReactOS will never catch up with the current version of Windows, Microsoft has made ReactOS and Wine a lot more important in recent years when they decided that it wasn't worth it for them to keep backwards compatibility forever.

I would expect even better compatibility in the future as they work closely with the WINE team. Months ago I played Far Cry 5 at medium settings on my AMD 4300GE (no external GPU) using WINE and it ran perfectly: graphics, sound, everything.

I've tried to set up some modern games in ubuntu with wine for a friend and it was pretty much impossible. Old games, yes, new games, a nightmare.

That was my experience at least.

Note that wine in ubuntu repositories is quite old. Try with a specialized tool like bottles.

What's the TL;DR; setup for bottles on Ubuntu? Get bottles from official Ubuntu repository, and let it install latest Wine version?

Bottles did not work very well for me. I'd suggest Lutris - it does a lot of things to ease the pains and has reasonable defaults. But if your game is on Steam - then just install Steam and let the game run through Proton, you don't need to do anything else

I've just finished playing through Elden Ring via Valve's Proton and now moving onto Hitman 3 from Epic Games Store via regular Wine. Somehow it works even better than the Windows versions (Elden Ring has noticeably less stutters, for example)

VR games however, especially with Oculus Quest, are extremely problematic

Take a look at Playonlinux; it does wonders in contexts where game A needs say WINE 64 bit version x and game B needs WINE 32 bit version y, and that applies to different versions of various libraries too (DX, NET or VC runtime, etc.). It creates separated (not sandboxed however) environments in which every program sees its own version of WINE and related libraries/tools.

https://www.playonlinux.com/en/

The only problem I have encountered so far, which I believe is a limitation of WINE that could be solved with a patch, is fooling very old XP programs into seeing smaller disks and less free storage. Some installers refuse to work then report negative free storage, which very likely means their old code uses shorter types to store the free space that are overloaded becoming negative when a longer type containing the actual size of a modern disk is assigned there. Patching WINE to offer an option to solve this shouldn't be very hard, hopefully.

A possibly dumb question. I know that ReactOS developers work by observing what the real Windows does, documenting that, and then reimplementing from those docs, instead of straight reverse engineering. This is supposed to avoid legal trouble. But wouldn't it be better to take a Windows installation and start replacing components, one by one, with open-source reimplementations, until there is none of the original proprietary Windows left?

Or, to rephrase it: what would happen if I took Windows XP and replaced the kernel (ntoskrnl.exe) with the one from ReactOS? Would that not be the ultimate binary and API compatibility test?

You could try. But several of the APIs just map to Linux equivalents. Such as if you ask for network details, it would interact with Linux to determine what is needed and return that value.

Things like dxvk or vkd3d have done support for what you are describing iirc though.

Your answer seems to be about WINE. The question was about ReactOS.

While I do not think that ReactOS is managed as described, I see no reason ReactOS could not meet its goals in this way. From a practical stand-point, I do not think it is possible today as few ReactOS components are complete enough to work in a real Windows environment. Certainly some of the user space stuff gets tested like that though.

Both GNU and BSD were created by starting with stuff that worked in real UNIX and filling in the blanks until a full system emerged. So, it seems a very practical approach.

The opposite happens sometimes as I have seen reports that say that something works on ReactOS when using one or two DLLs from real Windows.

When I mentioned GNU, I realized that in some ways ReactOS works the same.

ReactOS relies on WINE for user controls and libraries close to the user. In this way, it is a bit like GNU that started with the user interface and worked back to the kernel.

The ReactOS project itself seems to be focussed on the kernel and working back out from there.

Perhaps this is all too simple a view though as ReactOS certainly has other components ( like the app installer ). I think there is certainly some overlap between WINE and ReactOS devs as well.

> I think there is certainly some overlap between WINE and ReactOS devs as well. This is my understanding.

But you're likely correct that my response is mostly suited to speaking about dll's created from the wine project.

Although I think some code and implementation ideas are shared between projects, as you allude with your comment about sharing developers.

I'm really after letting ReactOS be useful for a boring office environment, has anyone been able to achieve this yet?

Why not Linux?

I'd worry about stability and security in business context.

I dont mean for a literal business, just for personal use, but being able to run stuff like MS Office and such would be nice. Maybe even do Windows development on it for web things. I like the idea of an OS not bloated by "telemetry" basically. I hate tweaking Windows beyond the norm, it breaks things typically.

I just run Windows in a VM if I need to do things with Office that I can't do with the Office for the web products, which isn't very often.

Think of ReactOS as a replacement for Windows XP. The selling point is more that it has compatibility with things like NT-based drivers, rather than being the future of compatibility with Windows. I have heard that you can set up Office 365 on Linux under Wine with a few tricks applied.

I've got office 365 on linux. Legally. It is buggy and slow.

You can run MS Office in Linux via Wine.

I would like that too.

Why more monoculture? The Linux driver situation is already bad enough, but it is even more terrible that it's practically the ONLY operating system which has some hardware support.

I support alternative open source OSs as much as I can, but monoculture or not, using ReactOS for business - especially connected to the internet - is asking for problems. Turns out that's not the intention anyways.

There is plenty of Linux-certified hardware as well as support plans.

What is the Linux driver situation and how is it bad in ways that other non-Windows FOSS OSes would be able to mitigate?

Linux does not have a stable ABI for drivers.

Presumably ReactOS uses Windows driver ABI, so you can just use Windows drivers?

That is the goal. In practice, that does not work yet.

ReactOS might become a real alternative to Windows for the older version of me, and I hope it will be ready by then! If they open up a "bughunting Friday" for games I might participate for the sake of old games conservation.

Now wait for pretty much every game to come with kernel-level drivers ("anti cheat").

What exactly does ReactOS provide that Wine or some emulation environment on Linux can't?

> What exactly does ReactOS provide that Wine or some emulation environment on Linux can't?

Support for NT kernel interfaces. This allows drivers written for Windows to work under ReactOS. Most of the userspace should work just fine on Wine and Linux.

Okay, that makes a huge difference lol. I always felt like the project seemed pointless and unsuccessful, but a free os that can run existing NT drivers is exciting.

https://en.wikipedia.org/wiki/NDISwrapper

Windows driver support

Problem is, Windows is, and seems to become more and more, with each version, something of a moving target - and so may be (are?) device drivers, which begs the question whether one can only use devices from ten years ago or such...

Hmmmm, wonder how well it works with recent VMware Workstation/Player?

From memory, that has fairly decent DirectX and OpenGL support in its drivers too, probably more optimised than the VirtualBox stuff.

What I want to see is a Windows kernel with GNU/Linux coreutils and X window manager. Then the circle will be complete.

WSL1 has you covered.

Ah good point, but it would be better if it were open-source.

I feel like showing off a game from 2002 comes off like “anti news”. Like look how slowly we’ve progressed.

Stop saying shit like "open source windows". Not only does it undersell the accomplishment here but it is a low brow way to bring the wrong kind of heat and attention.

Michael should know better than to publish that headline. Is this what we should expect from phoronix for 2022 onward?

Reply on news.ycombinator.com