SoylentNews is people
SoylentNews
https://reactos.org/blogs/30yrs-of-ros/
Today marks 30 years since the first commit to the ReactOS source tree.
[...]
ReactOS started from the ashes of the FreeWin95 project, which aimed to provide a free and open-source clone of Windows 95. FreeWin95 suffered from analysis paralysis, attempting to plan the whole system before writing any code. Tired of the lack of progress on the project, Jason Filby took the reins as project coordinator and led a new effort targeting Windows NT. The project was renamed to "ReactOS" as it was a reaction to Microsoft's monopolistic position in home computer operating systems.
[...]
While writing this article, I reached out to Eric Kohl. He developed the original storage driver stack for ReactOS [...]"I think I found ReactOS while searching for example code for my contributions to the WINE project. I subscribed to the mailing list and followed the discussions for a few days. The developers were discussing the future of shell.exe, a little command line interpreter that could only change drives and directories and execute programs. A few days [later] I had started to convert the FreeDOS command.com into a Win32 console application, because I wanted to extend it to make it 4DOS compatible. 4DOS was a very powerful command line interpreter. On December 4th, 1998 I introduced myself and suggested to use my converted FreeDOS command.com as the future ReactOS cmd.exe. I had a little conversation with Jason Filby and Rex Joliff, the CVS repository maintainer. I sent my cmd.exe code to Rex and he applied it to the repository. After applying a few more cmd-related patches over the next weeks, Rex asked me whether I would like to have write-access to the repository. I accepted the offer...
[...]
There was always an open and friendly atmosphere. It was and still is always nice to talk to other developers. No fights, no wars, like in some other projects."[...]
Public interest grew as ReactOS matured. In October 2005, Jason Filby stepped down as project coordinator, and Steven Edwards was voted to be the next project coordinator.
[...]
Steven Edwards strengthened the project's intellectual property policy and the project made the difficult decision to audit the existing source code and temporarily freeze contributions.
[...]
Following challenges with the audit, Steven Edwards stepped down as project coordinator and Aleksey Bragin assumed the role by August 2006.
Despite the challenges during this time, ReactOS 0.3.x continued to build upon ReactOS's legacy. ReactOS 0.3.0 was released on August 28th, 2006.
[...]
ReactOS 0.4.0 was released on February 16th, 2016. It introduced a new graphical shell that utilized more Windows features and was more similar architecturally to Windows Explorer. ReactOS 0.4.0 also introduced support for kernel debugging using WinDbg when compiled with MSVC. Being able to use standard Windows tools for kernel debugging has helped us progress considerably. ReactOS 0.4.0 continued to receive incremental updates every few months up until versions 0.4.14 and 0.4.15 which had years of development updates each. Today, the x86_64 port of ReactOS is similarly functional to its x86 counterpart, but with no WoW64 subsystem to run x86 apps its usability is limited.
[...]
Behind the scenes there are several out-of-tree projects in development. Some of these exciting projects include a new build environment for developers (RosBE), a new NTFS driver, a new ATA driver, multi-processor (SMP) support, support for class 3 UEFI systems, kernel and usermode address space layout randomization (ASLR), and support for modern GPU drivers built on WDDM.The future of ReactOS will be written by the people who believe in the mission and are willing to help carry it forward.
If you believe in running "your favorite Windows apps and drivers in an open-source environment you can trust", you can help make that a reality by making a financial contribution, opening a pull request on GitHub, or testing and filing bug reports. Even small contributions can help a lot!
Previously on SoylentNews:
ReactOS 0.4.15 Released - 20250326
Watch: Mac OS X 10.4 Running in Windows Alternative ReactOS via PearPC Emulator - 20180510
Alternatives to Win32...Win32 of course! ReactOS still making progress.... - 20160828
Release of ReactOS 0.4 Brings Open Source Windows Closer to Reality - 20160217
Ask Soylent: Can We Turn ReactOS into a Viable Alternative to Windows 10? - 20151021
NTFS Now Supported in ReactOS LiveCD - 20141106
(Score: 4, Touché) by looorg on Monday February 02, @09:23PM (8 children)
This is one of those OS that seemed like a great idea 30 years ago, when W95 was still a thing. It seemed like a great idea. Today? Not quite as sure. Is there anyone that actually runs this for anything but for to check it out? Or something you download and then run inside a WM and wonder if this just hadn't been awesome, about 30 years ago ...
How much of a operating system aficionado, or masochist, do you have to be to use it as a main OS today?
(Score: 4, Informative) by aafcac on Monday February 02, @09:38PM (7 children)
The main reason why this has any real value at all is that it has kernel compatibility for older hardware. So, if you've got hardware that doesn't have suitable drivers for anything other than older versions of Windows from 95 to somewhere around Vista, ReactOS might be a viable option. But, given where Wine is presently and all the options that don't involve Windows only binaries, I'm not sure that it's that useful for most people.
(Score: 2) by Bentonite on Tuesday February 03, @01:41AM (6 children)
Even it you have e-waste hardware that only has ancient proprietary drivers available, it would make far more sense to develop free drivers for GNU/Linux (depending on the hardware, it may just be a pain in the ass for a few hours), than to develop ReactOS to be able to run the proprietary drivers (although if ReactOS already has support, you can happen to "conveniently" get it quickly working in the short term, despite the long term consequences).
(Score: 2) by aafcac on Tuesday February 03, @03:10AM (2 children)
Except that that's on a per device basis. A compatible kernel allows for basically all of them to work without having to go through the process of analyzing and replicating the drivers.
(Score: 2) by Bentonite on Tuesday February 03, @06:00AM (1 child)
Many devices use protocols that don't meet any standard, but aren't particularly complicated, meaning once a generic driver for that type of device is developed, supporting more devices isn't too hard.
One example is generic drawing tablets - those don't follow the USB HID tablet standard, but generally implement a simple protocol - DIGImend provides a generic driver that requires a limited amount of work to add support for another tablet; https://digimend.github.io/support/howto/trbl/diagnostics/ [github.io]
Even with a compatible kernel, many drivers will fail to work, as many drivers are dependent on windows bugs and it seems debugging and working around such failures could be harder than adding another tablet to DIGImend.
(Score: 3, Touché) by aafcac on Tuesday February 03, @07:25AM
Many devices. That's the thing, many devices do. But if you go back to the '90s there was far less standardization than there is now and far fewer agreed upon APIs. The whole thing is pretty dumb as there's really no point in going to that work if there's already a kernel that's compatible. Chances are that if this is any sort of a consideration, you're dealing with obscure hardware that isn't easily replaced anyways. Why waste a bunch of money reverse engineering something that has an available driver that works with something like ReactOS? Nobody is producing more of that stuff anyways.
(Score: 2) by beckett on Tuesday February 03, @10:15PM (2 children)
I’ve been hoping someone would develop third party support for my Varian 5900 gas chromatograph, but they ended support with win 95.
It’s not e waste, still produces replicable results, but not enough interest for a Linux community to form around the hardware.
Here’s hoping my air gapped P4 workstation keeps chooching for a few more years.
(Score: 2) by Bentonite on Wednesday February 04, @12:23AM
It was specifically designed to be e-waste if it doesn't work without a proprietary driver - although with a free driver that problem can be fixed.
Linux community? Results from that kind of hardware would be handled in GNUserpace.
It doesn't seem the protocol would be that complicated unless the manufacturer obfuscated it - the main difficulty would be working out how to extract and understand the listing of what materials return mass spectrum values that is calibrated to the machine.
(Score: 2) by RS3 on Wednesday February 04, @03:11AM
I did a brief web search but didn't find the answer to: what interface / drivers / software does the Varian use?
Also from a search: