News ReactOS now supports 3dfx's Voodoo5 GPUs — open-source Windows alternative offers near-native performance for retro gamers

[Admin]

The open-source Windows alternative ReactOS now has support for 3dfx's Voodoo5 GPU family, with Unreal (1998) successfully tested.

ReactOS now supports 3dfx's Voodoo5 GPUs — open-source Windows alternative offers near-native performance for retro gamers : Read more

 

[das_stig]

ReactOS need to stop and rethink their path, they should be targeting Windows 10 compatibility. At current progress, it will just be a plaything and pipedream rather than an alternative.

 

[Mark Knight]

The voodoo 5 cards were NOT iconic, they were a failure and put 3dfx out of business.

 

[USAFRet]

'near native' performance.

So, almost but not quite being able to match performance of 25 year old hardware.

 

[_deXter_]

ReactOS need to stop and rethink their path, they should be targeting Windows 10 compatibility. At current progress, it will just be a plaything and pipedream rather than an alternative.

Maybe you need to stop and rethink what ReactOS is all about (hint: it was never about being an alternative for recent Windows versions). Besides, you need to be able to walk before you can run—and that's what they're focusing on right now, so targeting XP/2003 era APIs is a very practical goal. Also, most of the underlying APIs from that era are unchanged and still in use today in Win10/11, so it's not like they're wasting time here.

Also, ReactOS is not a "plaything", it has actual real-world use cases such as in embedded and industrial applications, where you're running expensive/specialised hardware and you don't have the option to upgrade to a recent supported OS. At my previous workplace for instance, we had a bunch of very, very expensive scientific instruments that ran Windows XP Embedded, each of which had a custom PCI card (not PCIe, mind you) to interface with the core instruments. We had a requirement to securely sync that data to the production network, but naturally you can't connect such an old OS to a modern network. Security issues aside, the protocols used in that era (like SMBv1) were super flaky (we used an intermediary server to sync the data, but the system was pretty unreliable overall). So as an experiment, we installed ReactOS on one of the machines (which was my idea btw), and surprisingly, it all just worked - even the instrument control drivers and software ran without a hitch. This allowed us to switch to the NFS protocol, which made the sync process so much more reliable that all our previous issues was now a thing of the past. I moved on from that role shortly afterwards so I'm not sure if they ever upgraded the rest of the machines in prod, but the point is that it showed that ReactOS was a legit alternative for people running ancient hardware.

 

[das_stig]

Maybe you need to stop and rethink what ReactOS is all about (hint: it was never about being an alternative for recent Windows versions). Besides, you need to be able to walk before you can run—and that's what they're focusing on right now, so targeting XP/2003 era APIs is a very practical goal. Also, most of the underlying APIs from that era are unchanged and still in use today in Win10/11, so it's not like they're wasting time here.

Also, ReactOS is not a "plaything", it has actual real-world use cases such as in embedded and industrial applications, where you're running expensive/specialised hardware and you don't have the option to upgrade to a recent supported OS. At my previous workplace for instance, we had a bunch of very, very expensive scientific instruments that ran Windows XP Embedded, each of which had a custom PCI card (not PCIe, mind you) to interface with the core instruments. We had a requirement to securely sync that data to the production network, but naturally you can't connect such an old OS to a modern network. Security issues aside, the protocols used in that era (like SMBv1) were super flaky (we used an intermediary server to sync the data, but the system was pretty unreliable overall). So as an experiment, we installed ReactOS on one of the machines (which was my idea btw), and surprisingly, it all just worked - even the instrument control drivers and software ran without a hitch. This allowed us to switch to the NFS protocol, which made the sync process so much more reliable that all our previous issues was now a thing of the past. I moved on from that role shortly afterwards so I'm not sure if they ever upgraded the rest of the machines in prod, but the point is that it showed that ReactOS was a legit alternative for people running ancient hardware.

It's great and a sign they are heading in the right direction, that the OOBE all worked for you and yes I know all about it goals and why XP era etc and have read the blurb, still stand by my comment that Win10 should be its target and a true alternative. Yet if they want to be taken seriously, they must fix their website, so many broken bits or content inaccessible and of course the $1m question, when will it be v1.0 production ready, another 20 years when it will be irrelevant?

 

[mitch074]

It's great and a sign they are heading in the right direction, that the OOBE all worked for you and yes I know all about it goals and why XP era etc and have read the blurb, still stand by my comment that Win10 should be its target and a true alternative. Yet if they want to be taken seriously, they must fix their website, so many broken bits or content inaccessible and of course the $1m question, when will it be v1.0 production ready, another 20 years when it will be irrelevant?

Actually, since ReactOS uses Wine for API support the only reason they'd switch to Win10 as a target would be to isolate the graphics drivers from kernel space - as that's the main difference between the Windows Server 2003 kernel they're clean-room reverse engineering and the Vista/7/8/10 kernel. Maybe the scheduler...? But then they can swap a scheduler out and implement their own based on Linux ones as well.
I'm not so sure anybody would really be interested in all the entry points for spyware that Microsoft added later on, so...

 

[snemarch]

Actually, since ReactOS uses Wine for API support the only reason they'd switch to Win10 as a target would be to isolate the graphics drivers from kernel space - as that's the main difference between the Windows Server 2003 kernel they're clean-room reverse engineering and the Vista/7/8/10 kernel.

Getting the graphics drivers out of kernel space is worth it – I know Vista got a lot of flak, but BSODs dropped basically to zero with the new display drier model.

Maybe the scheduler...? But then they can swap a scheduler out and implement their own based on Linux ones as well.
I'm not so sure anybody would really be interested in all the entry points for spyware that Microsoft added later on, so...

Having it **look like** the patchguard etc stuff is implemented might be interesting for some usecases 😉

 

[drivinfast247]

The voodoo 5 cards were NOT iconic, they were a failure and put 3dfx out of business.

Do you know what "iconic" means?

 

[mitch074]

Getting the graphics drivers out of kernel space is worth it – I know Vista got a lot of flak, but BSODs dropped basically to zero with the new display drier model.


Having it **look like** the patchguard etc stuff is implemented might be interesting for some usecases 😉

Driver out of kernel space : agreed. I'm not sure it's technically too difficult though, as the graphics driver were an exception more than the rule in NT5.x and older. Implementing WDDM on top of their kernel may not need that much re-architecturing.
Make it look like patchguard is working : in that case, Linux+Wine (or Proton) is a better approach. ReactOS is really looking at binary compatibility with drivers, so this may be an overreach.

 

[Mark Knight]

Do you know what "iconic" means?

Yep, the voodoo 2 was iconic.

 

[Pemalite]

Voodoo, Voodoo 2 and Voodoo 3 was iconic.

I still have a Voodoo 2 actually.

Been keeping an eye on ReactOS, if it's not as flakey as Win9X, I might make the move one day for my Retro PC.