I do a lot of industrial automation and it is the one thing that keeps me boat-anchored to Windows. Every little programmable doodad like signal conditioners and temperature transmitters have their own USB programming cables and their own, mostly crappy windows config software. PLC software is another abomination, hopelessly Windows anchored, bloated GUI monsters, some built on top of Visual Studio (Beckhoff TwinCAT.)
I have donated to ReactOS in the past in the hopes of one day freeing myself from this hell.
You can forward USB devices into a VM. About 15 years ago I was using a Windows VM on Linux to program PIC18F??? devices with the custom (JTAG based?) programmer provided by Microchip. The upside is that you can preserve and share this windows environment for other coworkers, and have separate VMs for different projects (perhaps one you can update, and one you can't ...)
This is exactly what I do currently but it's flaky. Bekhoff installs a runtime on the development PC that works its way deep into the system that can and does crash the VM. Some USB devices work, some don't, some are buggy and may hang or fail in the middle of programming. I have to keep a dedicated Win PC just to make sure I have a working Winstall for my work. I keep VM's of 2k, XP, and 7 as I have to maintain a wide variety of hardware and software. I just want off the Windows upgrade treadmill.
Because that requires breaking the almost assured stipulation in a software license agreement that says "You will not try to RE this software", which is fine to ignore for home gamers, but not something you generally want to mess around with in a business setting where the risks are much higher.
The thing about this type of thinking is that it often requires risking millions of dollars and a major distraction from your primary goal in order to find out if it's true or not.
As would be running critical software certified for Windows on ReactOS as envisioned by GP. So, either we talk about an enterprise setting, in which GP already fucked up, or a more personal setting, in which both whaat GP and I said are reasonable
Also, the one thing that's important above all else in industrial automation is reliability. If your LLM doesn't know about one tiny little detail that ends up causing your product to fail, your customers start losing money and you can no longer point the finger at your PLC manufacturer. Make bad gambles like that and you won't be in business for long.
The reason industrial PLCs cost so much is because of their reliability. They need to be working flawlessly 50 years in the future. Trying to vibe code your way into a PLC compiler feels like it could blow up in your face after a little while.
That is also ignoring the safety PLCs with safety instructions that are certified for use with ISO 13849. Can you imagine getting inspected because your safety subsystem cause injury and you explain how you don't use the officially licensed software to program it.
You completely stripped what I said from its context. GP explicitely said they donate to ReactOS in the hopes of one day being able to run that industrial software on it instead of on Windows. In this context, running the software on ReactOS instead of official Windows would already fail your hypothetical inspections. This is why I suggested trying the LLM route.
If I had to explain a failure in production I would much rather say "due to availability of old hardware, we ran this on a different version of Windows/inside a VM/inside a Windows compatibility layer/Wine/ReactOS" than "we vibecoded the entire driver stack from scratch, go ask Claude why the plant blew up lol".
Running the same software in a different environment is unlikely to cause issues. But with vibe coding, you're throwing away the code the manufacturer certified as working, and the best possible outcome is it bricks your hardware in dev before things escalate to a post-mortem.
That is only recently become an option you could try, and we don't know long term how well it will work. Remember laws may change (and there are some legal issues around LLMs that are not clear at all)
Looks like a lot of improvements on long-standing hard-to-find issues. Kudos to the team and thank you for providing an alternative OS that keeps getting better
One of my favorite projects, maybe someday it can be a true daily driver, I wonder if that's the goal for 1.0 is to claim that they've gotten it stable enough to run as though it were Windows 7 or something to that effect.
It's not only that it was text based, but that it failed in all sorts of ways.
I had a particularly bad afternoon in early 2000s when I tried to install Linux on various machines (4 or 5, each one with different hardware) and failed with all of them. Of course, I wasn't as savvy as I am now, but it's been years since I've seen an issue with a Linux install; although I might have to download and compile a driver for one thing or another, the install itself doesn't fail.
Same with me - late 90s. Celeron 366Mz, 64 MB RAM, 4.3 GB HDD. Don't remember the video card and the sound card. Used to stay up all night to try and fix X11. And once you got it running - victory !!!
Yes, but native open-source drivers are needed for out-of-the-box support, legal compliance, and debugging missing kernel/NDIS APIs during development.
It's also the kind of project where LLM license-washing is going to be the most dangerous for the project itself. Projects like Wine and ReactOS have to be extremely careful about what kind of code to accept, because taking code from one of the countless Windows source leaks is just a recipe for legal disaster.
TIL that the GUI of ReactOS isn't based on React. All these years spent baffled that who would like to build an OS with JS, thanks to me only reading the headlines lol
I do a lot of industrial automation and it is the one thing that keeps me boat-anchored to Windows. Every little programmable doodad like signal conditioners and temperature transmitters have their own USB programming cables and their own, mostly crappy windows config software. PLC software is another abomination, hopelessly Windows anchored, bloated GUI monsters, some built on top of Visual Studio (Beckhoff TwinCAT.)
I have donated to ReactOS in the past in the hopes of one day freeing myself from this hell.
You can forward USB devices into a VM. About 15 years ago I was using a Windows VM on Linux to program PIC18F??? devices with the custom (JTAG based?) programmer provided by Microchip. The upside is that you can preserve and share this windows environment for other coworkers, and have separate VMs for different projects (perhaps one you can update, and one you can't ...)
This is exactly what I do currently but it's flaky. Bekhoff installs a runtime on the development PC that works its way deep into the system that can and does crash the VM. Some USB devices work, some don't, some are buggy and may hang or fail in the middle of programming. I have to keep a dedicated Win PC just to make sure I have a working Winstall for my work. I keep VM's of 2k, XP, and 7 as I have to maintain a wide variety of hardware and software. I just want off the Windows upgrade treadmill.
Why not spend some money on an uncensored LLM to reverse engineer or create an open clean room reimplementation?
Because that requires breaking the almost assured stipulation in a software license agreement that says "You will not try to RE this software", which is fine to ignore for home gamers, but not something you generally want to mess around with in a business setting where the risks are much higher.
Reverse engineering is protected under certain conditions, even if the EULA prohibits it
The thing about this type of thinking is that it often requires risking millions of dollars and a major distraction from your primary goal in order to find out if it's true or not.
As would be running critical software certified for Windows on ReactOS as envisioned by GP. So, either we talk about an enterprise setting, in which GP already fucked up, or a more personal setting, in which both whaat GP and I said are reasonable
That is how you get a hardware provider to stop selling you stuff
Also, the one thing that's important above all else in industrial automation is reliability. If your LLM doesn't know about one tiny little detail that ends up causing your product to fail, your customers start losing money and you can no longer point the finger at your PLC manufacturer. Make bad gambles like that and you won't be in business for long.
The reason industrial PLCs cost so much is because of their reliability. They need to be working flawlessly 50 years in the future. Trying to vibe code your way into a PLC compiler feels like it could blow up in your face after a little while.
That is also ignoring the safety PLCs with safety instructions that are certified for use with ISO 13849. Can you imagine getting inspected because your safety subsystem cause injury and you explain how you don't use the officially licensed software to program it.
For personal project, that could be fun however.
You completely stripped what I said from its context. GP explicitely said they donate to ReactOS in the hopes of one day being able to run that industrial software on it instead of on Windows. In this context, running the software on ReactOS instead of official Windows would already fail your hypothetical inspections. This is why I suggested trying the LLM route.
If I had to explain a failure in production I would much rather say "due to availability of old hardware, we ran this on a different version of Windows/inside a VM/inside a Windows compatibility layer/Wine/ReactOS" than "we vibecoded the entire driver stack from scratch, go ask Claude why the plant blew up lol".
Running the same software in a different environment is unlikely to cause issues. But with vibe coding, you're throwing away the code the manufacturer certified as working, and the best possible outcome is it bricks your hardware in dev before things escalate to a post-mortem.
That is only recently become an option you could try, and we don't know long term how well it will work. Remember laws may change (and there are some legal issues around LLMs that are not clear at all)
Looks like a lot of improvements on long-standing hard-to-find issues. Kudos to the team and thank you for providing an alternative OS that keeps getting better
One of my favorite projects, maybe someday it can be a true daily driver, I wonder if that's the goal for 1.0 is to claim that they've gotten it stable enough to run as though it were Windows 7 or something to that effect.
Love it! Haiku, ReactOS and sure Linux. But if necessary, the real art of computing can be kept up!
Now all we need is an alternative clean-room implementation of Mac OS.
You should take a look at ravynOS! https://ravynos.com/
See also: https://www.darlinghq.org/
> lets you run macOS software
> must be running a 64-bit x86
And an L4 version of Solaris or Plan 9 with servers for USB and Bluetooth.
Quite the dedication have these people!
This reminds me of the feeling of when Linux got graphical installers instead of long text based ones asking you many, many questions.
It's not only that it was text based, but that it failed in all sorts of ways.
I had a particularly bad afternoon in early 2000s when I tried to install Linux on various machines (4 or 5, each one with different hardware) and failed with all of them. Of course, I wasn't as savvy as I am now, but it's been years since I've seen an issue with a Linux install; although I might have to download and compile a driver for one thing or another, the install itself doesn't fail.
Mine was in the 90s and concerned X11 failing or crashing due to the video card typically. Redhat 5.2ish or Suse.
Same with me - late 90s. Celeron 366Mz, 64 MB RAM, 4.3 GB HDD. Don't remember the video card and the sound card. Used to stay up all night to try and fix X11. And once you got it running - victory !!!
Bar bad floppies I don't remember ever having an installer issue.
Unrecognized/unsupported hardware is another thing but I always could finish the install and at least reach the console login prompt.
I've never used bleeding edge equipment though, euther second hand or brand new but proven tech.
It always brings me joy to see ReactOS going places.
After the news about the Start Menu, the name briefly had me convinced someone actually rebuilt all of Windows in React Native.
> a new DC21X4 network adapter driver
Hasn't the point been for the OS to be compatible with the existing Windows drivers?
Yes, but native open-source drivers are needed for out-of-the-box support, legal compliance, and debugging missing kernel/NDIS APIs during development.
This is a donation reminder for me.
This seems like the sort of project that ai would excel at. /goal excel runs flawlessly.
It's also the kind of project where LLM license-washing is going to be the most dangerous for the project itself. Projects like Wine and ReactOS have to be extremely careful about what kind of code to accept, because taking code from one of the countless Windows source leaks is just a recipe for legal disaster.
Some of us are old enough when very similar smelling FUD was being spread by MS about Linux 30 years ago.
Well, Excel has AI now, so maybe it can help.
Excel writes Excel, which writes Excel...
Now we have an infinite loop
Just what the world needed, excel implemented In an excel script. Thanks sloppers
Why, this could be a fun excrement for sure
[dead]
TIL that the GUI of ReactOS isn't based on React. All these years spent baffled that who would like to build an OS with JS, thanks to me only reading the headlines lol
Well ReactOS did have a 15 year lead on the name over React...1998 vs 2013, going by first public release of each.
ReactOS is way older than React. In fact, the first times when I heard about React I thought ReactOS was becoming mainstream, but no...
If you an OS based in JS, maybe the closer we had was NodeOS [1]
[1] https://node-os.com
Or maybe https://bellard.org/jslinux/