ReactOS Updates
reactos.org
reactos.org
I think that for the long term, Wine is a superior solution, as it can use all the nice modern features of Linux kernel, and can easily co-exist with modern aoftware. The only feature that ReactOS has and Wine does not is windows device drivers - and QusesOS does not need those.
I wouldn't mind being back in a Windows env/shop with ReactOS.
I'm still not sure that the move from actual buttons on a button bar to just a flat series of icons was right, and many such changes happened after that (culminating in the horror of the ribbon bar).
The big items Win2K/XP brought to the market was stability outside of the NT niche (I really enjoyed NT4). On the UI level, the downgrade continued, especially with that ugly blue standard theme and the bisque semi-rounded UI elements.
But boy, would I like to see some "distro"-fication of that. And I'm not talking about just using different themes or "shell" replacements, but about putting the core parts to good use. It could be amazing to what some dedicated minds could do with COM, OLE, VCL and VBS. A much more modular environment, similar to what OpenDoc promised and didn't keep. (And maybe add some Amiga stuff)
Not that my hopes are very high in that regard, as Linux and the BSDs didn't manage to do that either, despite having most of the technology and even doing some half-hearted attempts (CORBA was a part of early GNOME)…
A Windows shop these days isn't that much different from any other enterprisey shop. Cloud, VM language, web UIs with enough whitespace to hide Moby Dick. Not that many of the smaller shops around that did custom desktop apps for small businesses.
Oh, and as a final note: If you like the aestheticof 90s-ish Win, check out Serenity OS[1]. It's pretty awesome what they put together. A not slavishly POSIX-ish system with a Win95-like UI. Even the starts of a remarkably capable browser…
I'm sure this is still an unpopular opinion, but I've come around to the idea of the ribbon bar. Toolbars as they were pre-Office-2007 usually only contained duplicates of entries that were already in the menu. The menus are difficult to discover things in and limited to only showing text (at least in the "classic" sense like Office 03 used). Ribbon bars take the discoverability of a toolbar and make it use only as much space as a menu would. It's a solid compromise IMO.
To be fair, they've left the classic mode in. Right click the taskbar, then click 'taskbar settings', scroll to the bottom and there's a dropdown for 'combine taskbar buttons'. Change it to 'Never' for the classic mode. (This is also present in Windows 7/8)
I prefer the new mode, less mouse movement required and looks tidier personally but it's nice the option is still there.
Within a few Office and OS versions, that changed to first dropping the beveled edge, as we might realize that icons under the menu are buttons, and there would be less visual noise, then large buttons with icons + text, and finally getting into an incestous relationship with the menu and becoming ribbons.
(Although, I do the old-fashioned taskbar settings, too.)
D-BUS has taken up that role, but it doesn't get as much as COM/UWP, which many still don't realize that since XP the large majority of new Windows APIs are only available via COM, with a possible additional .NET wrapper on top.
There's more GUI scripting done on Macs and Windows. Whole cottage industry automating Excel, for example…
Linux/BSD have the tooling, yet it is ChromeOS and Android that reap the benefits of such component based APIs.
My first job after high school was QA for Lindows, and I used dcop to automate testing of their app store client (2002-2003).
Win98SE was the peak IMHO.
Nowadays I like KDE/Qt on Linux.
Win98SE's toolbar were those big mozilla-ish ones, right, with both text and icon and no button border? Other than that, I can't remember anything distinguishing about the 98 UI. Were gradient in the window bars introduced with 98 or SE?
The classic Windows 2000 theme has just the perfect balance of looking good, being totally usable, and not being overtly flashy.
That was actually a feature. I wanted to use my GPU for other things like gaming and rendering things I actually wanted to be pretty.
The OS interface doesn't need to be pretty. It needs to be usable. The pretty and usable are usually conflicting goals.
That's a pretty bold statement.
I use computers for 10-20 hours each day. I've come up with some pretty bold opinions based on actually wanting to improve efficiency of using computers. Someone else's ideas of aesthetics almost always conflicts with efficiently using the computer.
FWIW, as a general rule, I disagree: say you get to use two pieces of software with the same functionality, shortcuts et. al. for similar amounts of time, the first having 0 regard towards UI/UX, and the second having spent some time thinking about how it presents information and overall legibility. I'd be more than extremely surprised if most users couldn't possibly end up being more efficient using the second.
However, sure, making things pretty for the sake of it tends to impede on usability.
The Windows 95 through 2000 UI, I think, expresses the second idea perfectly. Rather than being clunky like older versions, they had thought put into how the layout and presentation looked. Granted, some of its qualities stemmed from needing to be renderable on a 386 in reasonable time, it still achieved something both visually appealing and productive.
In contrast, whatever fad comes around to make buttons look like Play-Doh or glass or flat elements with no distinguishing features... they take away from it quite a lot.
> Note: These results are totally wrong.
https://www.opendesktop.org/p/1253201
With the Redmond or Chicago95 theme for GTK, those apps also look in place in case you need them.
For truly a low resource usage desktop I look at LXQt. Same base lib as KDE, namely Qt, which is apparently a lot lighter on the resources than GTK. Not sure if it is ready yet these days.
I don't say it to be needlessly negative, it just amazes me how difficult this stuff can be. And I don't think I could actually use this, it would drive me insane for reasons I can't really justify.
For me, fonts are more important (and easier!) to get right than being pixel perfect, so I grabbed the real fonts from a Vista install DVD, and used those.
> ReactOS is a free and open-source operating system for amd64/i686 personal computers intended to be binary-compatible with computer programs and device drivers made for Windows Server 2003 and later versions of Windows. ReactOS has been noted as a potential open-source drop-in replacement for Windows and for its information on undocumented Windows APIs.
I've also read that a fair number of ReactOS developers have been recruited by Microsoft over the years. So even if the project itself never reaches feature parity, it's still a strong advert to put on ones CV.
It seems they will never have enough resources to become more popular than windows.
And they will never manage to become the desktop OS of choice over Linux or Mac either.
It seems to sit in an odd place with only a tiny userbase and no real goal, permanently playing catchup.
If Microsoft ever damages the reputation of Windows too much, ReactOS can act as a drop-in replacement for many things with relatively little investment compared to migrating to an OS on another kernel. Even if they're not currently a threat Windows, they have done enough of the groundwork that some extra funding and support could make them a serious competitor should the need ever arise.
Plus, it's just cool.
One of the more beautiful aspects of Windows is you actually rarely interact with the kernel at all. That portion of the OS could (and in practice often is) switched out and replaced without the user-facing portions being aware.
If you look at the list of NT system calls [0] you can see how frequently they've changed. The only programs that can safely talk to the kernel are core OS components, which in turn provide a user-facing stable ABI through the use of DLLs.
The fact Wine is running on a separate kernel is essentially 100% transparent to all but a handful of programs that intentionally poke the kernel, either for undocumented functionality or to e.g. detect tampering.
This is why IMO for running application software, Wine will always be superior. Linux is a really good kernel for almost everything, and with io_uring the last big deficit (async i/o) may be fixed.
ReactOS's remaining advantages are driver support for Win2k, and the whole explorer shell and start menu environment. If someone really wanted to, I bet you could run ReactOS's shell on top of Wine, fullscreened on Linux...
[0] https://j00ru.vexillium.org/syscalls/nt/32/
EDIT:
A thought I had after finishing this. Another benefit of ReactOS's architecture vs Wine is you could, in principle, directly copy at least some system-level DLLs/software from Windows (2000/XP) and get something akin to Windows 2003/XP running on a modern and up-to-date kernel, possibility with much newer hardware support.
I doubt the ReactOS devs themselves would want to get that close to even just binary blobs from Microsoft, but if it gets far enough along, I could see users scrapping together systems like this, maybe for retro games or something.
Not everything has to be #1 to be sustainable, interesting and/or worthwhile.
They only really need to get to a XP64/win7 level of win32 capability with the ability to run a recent graphics stack and they will win. They have been getting closer to the "just" works bit every year. At some point I suspect their market share will start to rise enough that application vendors start assuring their programs work properly.
At which point they could have a larger market impact than macos has had for the past 30 years.
I can think of some niche use-cases. For example, my mother owns a perfectly functional printer and spent quite a lot of money on ink cartridges, only to have the manufacturer refuse to provide drivers beyond Windows 7 (and never bothered supporting anything but Windows). React OS could allow her to continue using this otherwise functioning printer until she runs out of ink and cannot buy any more cartridges.
There are probably tons of other weird devices out there that are beyond their official EOL and require some previous version of Windows to continue to be used. There is also a lot of software that people depend on but which is either EOL or the original software vendor is defunct, and React OS can provide a compatible environment to run that software on regardless of what Microsoft chooses to do with more recent versions of Windows. It may seem crazy and there are probably a variety of security issues with running unsupported software, but for some people the risk will be worth it.
- Windows has gone very stagnant IMO. Sure they might have a bunch of new apis for 8/10, but... are there killer apps for them?
- Windows is no longer in growth phase. COVID computer demand surge is a temporary measure, and will probably be followed with a long shallow valley
- ARM is coming on the desktop, and it's going to destroy Windows backwards compatibility. That creates a tentpole point for ReactOS to target for compatibility, and likely something that, like Dosbox, microsoft would de facto embrace to alleviate itself of pressures of backwards compatibility
So I think ReactOS could settle into the "backwards compatibility VM" that windows could (should) actively support so they can move onto a new processor architecture.
There are a lot of workflows dependent on software and devices that never had a proper update to support past Windows XP 32-bit.
Even if you use license-downgrade rights, it's going to get harder and harder to find the actual bits you need to keep such systems alive.
ReactOS could potentially provide that steady-state-- a perpetually available Windows XP, which is also recent enough that you could see new drivers added and software ported so you could still boot it on a commodity PC.
Also: If Windows starts getting real ugly with forced telemetry, cloud service integration, and deprecation of Win32 apps, ReactOS can provide a way to continue using "Windows" in a productive manner without the negative side effects of ad-surveillance and forcing you to upgrade your PC every X interval like a phone.
Hopefully Microsoft doesn't make any other app become basically unremoveable like Internet Explorer and Cortana.
Windows 10 certainly isn't the "last version" of Windows in the sense you are thinking.
Even if there is no new version number, they could likely just drop that and call it "Windows" from now on. I haven't heard of any plans to discontinue desktop development.
It will just be constantly updated, as we are seeing it now.
Like the major UI revamp in the works codenamed 'Sun Valley', due later in 2021.
https://www.windowscentral.com/windows-10-sun-valley-ui-octo...
You'll have to do better than a new color scheme and fixing the dialogs they broke since Win7.
Now Windows terminal is something to talk about, but the number of devoted team members appears to be under 5.
I do know about WSL, which you could consider an anti-feature in a way.
If though, you're asking if they "can" in very generic terms, yes, certainly - as a matter of fact, this has been a large controversy of ReactOS.
There are no certainties, as everybody has their own side of the story. An MS developer, Axel Rietschin, publicly expressed his opinion that there are wholesale ripped off (low-level) functionalities¹; I personally find it convincing, although it's fuzzy, as he doesn't give details.
You can, but if your solution is at all like theirs the onus will be on you (what-ever legal team you can afford against their 800lb gorilla) to prove that you didn't copy it.
It is far safer not to look at all, and IIRC ReactOS's developer guidelines prohibit their devs from doing so for the avoidance of doubt.
> or write documentation about the behavior of the APIs and general behavior.
What Compaq did to implement the behaviour of IBM's BIOS (the only part of the original PC that wasn't off-the-shelf) was to double-clean-room. Two completely separate teams were on the job: in one "clean room" they analysed the chip's behaviour in detail and documented everything significant, and in the other a team implemented a design that mimicked said behaviour.
I doubt the ReactOS team have the resources to properly pull this off for something as large as the Windows source code though, and even if they did that still wouldn't get close to their target of Win2003 & later compatibility (there have been some significant changes to parts of the driver model since the XP days).
He imagines if Microsoft with their whole "We <3 Open Source" ideal either open sourced older versions of Windows (he mentions 3.1 for Work groups, or 98 back), or better, backs/contributes code to ReactOS themselves.
One of his arguments is that either method would take minimal effort from Microsoft, and would show their love of Open Source. The code could be made available as is, and allow the ReactOS project to continue burden of development/support.
His second major argument is that Microsoft would not take a financial hit from releasing these old versions. The OS's are no longer available for purchase in stores, and MS no longer provides support. Could also convince Embrace/Extend/Extinguish gray beards that Microsoft is "changing", making them more likely to trust MS.
Ultimately he theorizes Microsoft could only make finical gain from this. This comes from the positive community views (and wallets), and they could be positioned to repackage it as a "Windows Classic". This would allow them to "sell" and support old code again that would be perfect for legacy software, yet run on modern hardware.
Windows 98 could still be in used in some places for some obscure reason? Especially when you consider Windows ME and 2000 include many of the Windows 98 component. Open Sourcing those would create some security and legal problems.
Although I do wish they could start with open sourcing the Kernel.
That's something that's very usable piecemeal, and is probably more useful long term than a single version of a code dump like we'd probably get if they open sourced.
ReactOS is a cool project, but it's an alpha-stage complete operating system with bugs as basic in nature as you shouldn't even expect the file system to live long without being corrupted, or the OS crashing constantly. Not to mention they primarily focus on Windows XP compatibility, Vista and newer software is generally unlikely to work.
There was a day people accepted that sort of thing... but not anymore.
That sounds like ntfs worked already if you had an existing non-boot partition.
-----
Dirty rumour + speculation time: I understand that, to an extent, ReactOS is supported by the Russian government to ensure they have options for running their IT systems in the event of US or NATO-led sanctions which would prohibit service and support from Microsoft corporation. Ordinarily I wouldn't be concerned (geopolitics, yey) but given Putin's current direction... I hope ReactOS is getting suitably security audited...
The project did not receive any serious support from the state institutions of Russia
Security audit won't hurt, for sure.
To be clear, I don't know what Biden is up to but any country big enough sure have secret services making sure their country stays in the game. That's just part of history.
Now, as an individual, I'd be very happy to have a clean OS. But, considering the difficulty/practical impossibility to make my own audit, well, in the end, I have to trust someone...
Edit: This could very easily be from AdBlock Plus as well, but the tooltip was under the address bar (and it doesn't reappear when I visit reactos.org)
Edit2: I got this when navigating to https://goggle.com also (that's goGGle, not google). Turned off Lastpass and Adblock Plus to confirm it wasn't from them.
More than 3 times longer. ReactOS was started in the 90s (in fact I might have even used ReactOS before I first used Linux. There certainly isn't much between it). Whereas React.js was started in 2013 (ref: Wikipedia).
But for legitimate communities building honest software (or any honest product, really), it can be harmful to have potential users/contributors being scared off by a message like this. At the very least, it can make visitors question the legitimacy of the product. Since ReactOS has been around for decades at this point, it seems as if they're suffering a penalty for not being as popular as ReactJS, which is kind of bullshit, if there's no way for ReactOS (and other legitimate companies which may be affected) to let Google know "hey, we're doing our own thing, would you please mind not scaring potential users away". Whether or not I use Chrome, at least 60% of Internet users do. And I've never seen a warning when visiting reactjs.org asking if I didn't actually mean reactos.org, so the axe doesn't swing both ways here.
Well, you just reiterated that ReactJS is newer and newer is always better. /s
The best way to avoid having Google interfere with your browsing is to use a non-Google browser.
We never broke ties with IRC though. You can still join #reactos or #reactos-dev on Freenode, both are bridged to their corresponding Mattermost channels using Matterbridge.
Our Matrix server was set up right in time for FOSDEM 2021. It will soon be extended to bridge to the IRC and Mattermost worlds, as Matrix integrates even better with Freenode's IRC server than Matterbridge.
As an open-source project, never place your bets on a single third-party platform!
Edit: reference to the question
https://www.quora.com/What-do-you-think-about-ReactOS?share=...
There was an issue when there was a leak of windows source code to the internet, and ReactOS effectively had to shut down development for months while all code was audited to make sure no helpful folks had used any of it to 'help' the project.
That's the only MS IP controversy they've been involved in (and I've been watching the project for waaaay too many years now)
(That issue answer reads like someone angry, and with an agenda. It also reads somewhat like the SCO/Linux thing a few years ago - there's no way anyone could write an OS like linux from scratch! It has to be stolen! Also the aforementioned shutdown/cleanup period kinda points to them taking this issue very seriously)
> Many internal data structures and internal functions, not exported anywhere and not part of the public symbols, have the exact same names as they appear in the Research Kernel (which, by the way, is quite obsolete). There is an almost surely zero probability that this happened, at that scale, by accident.
Unfortunately I don’t think anyone who doesn’t have access to the research kernel is capable of answering.
The main existential threat to WINE would be the Oracle/Google case being decided (sometime before June). If that winds up creating adverse precedent to Google's case, the entire Free Software movement will be negatively impacted. Actually, it'll be like 100 SCOs, given how much of our Free foundations are functionally-compatible reimplementations. We'll lose pretty much everything except scripting language runtimes, Rust, and C compilers; and there would surely be no way to do something like WINE if SCOTUS decides to trample all over the merger doctrine and starts granting copyright on functionality.
You'd probably have a better argument for GPL violation for non-GPL reimplementations, but I'm not aware of that many people doing proprietary reimplementations of Linux APIs. Hell, even Microsoft stopped trying that when they moved to WSL2.
But ReactOS is clean room, and like Wine, AFAIK actively bars from contributing people who had contact with MS source code - IIRC it also cooperates heavily with Wine on implementing things.