I really hope the integration with QubesOS[1] will be completed in the near future. It will allow to run suspicious legacy Windows software without any hassle.
But would ReactOS be a best approach in this case?
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.
Good idea— I’ve been loading windows but perhaps there’s no need. I liked the appVM and templates but Win10 must be hvm.... GitHub has a great scripted airgapped updated trimmed install:
https://github.com/elliotkillick/qvm-create-windows-qube
As with many things, I think from a pure UI perspective every Windows/Office release made things worse. Win95 was pretty solid, even improved on a few things that they took from the state of art at that time (Nextstep, Classic Mac, OS/2). The Taskbar being a good example.
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.
> 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).
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.
I meant the regular toolbars underneath the menus (in MFC it was CToolbar, I think), that in Win95 were a set of regular icon buttons, including a beveled edge.
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.)
> 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)…
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.
DBUS would probably be closer to DCOM or even the Amiga's ARexx ports. Granted, with that plus XEmbed, you could get a lot of the benefits without an explicit object model/component system, but I haven't seen that done a lot in action. Linux users mostly go for 70s shell/pipes to cobble together parts. Better than nothing, but man, such wasted opportunities (and even something that doesn't require Lisp/Smalltalk/Oberon systems where everything is the PL anyway).
There's more GUI scripting done on Macs and Windows. Whole cottage industry automating Excel, for example…
I feel you, back when I look to some setups I hardly see any difference to my former self organising xterms in groups of four on a X Windows IBM terminal connected to a DG/UX server, in 1994.
Linux/BSD have the tooling, yet it is ChromeOS and Android that reap the benefits of such component based APIs.
Note that I was only talking about the uniformity of the UI here. Stability-wise, every DOS Windows was pretty bad.
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?
It's a real shame that Microsoft has seen fit to try to hide the ability to use the classic theme in Windows 8/10. There are ways to enable it again, but they tend to break on every update...
The classic Windows 2000 theme has just the perfect balance of looking good, being totally usable, and not being overtly flashy.
Maybe I'm a minority here, but I already used an alternative color scheme with beige backgrounds and dark red title bars (I think it was called "Brick") on Windows 95 because the various shades of grey looked too dreary for my taste. So I was happy to see that Windows XP kept the beige background and never looked back. Plus, under Windows XP an application that popped up with the "classic" styling was a red flag indicating that the developers didn't know how (or didn't care) to include a manifest file/resource to activate the "XP-style" controls...
The classic theme doesn't use DWM sadly (at least it didn't in Windows 7, I assume it still true in 10). So it doesn't just change appearance but also how it performs: DWM offloads compositing from the CPU to the GPU.
The issue is, at least when I tried it in Windows 7, without DWM you don't get Vsync. That means any video or game you play will have horrible screen tearing. I used to have a script to switch to Aero temporarily when I got fed up with it enough.
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.
You presented it as a fact, not an opinion, thus my original answer.
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.
> 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.
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.
The classic theme is simple enough that it doesn't need GPU assistance (besides the usual 2D acceleration); and you get a noticeable decrease in latency from it:
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.
Just looking at it I'm struck by how difficult it is to get the small details right. I don't even know exactly what's wrong but the spacing at the top and bottom of the title bar text is visibly wrong, and the menu bar is too high?
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 trying to reverse engineer a look, what has been done with this theme is amazing! I use it in a VM and on a laptop. Between higher resolution/PPI screens than CRTs that displayed this old Windows look, and familiarity with XFCE, the spacing doesn't look weird to me.
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.
Part of it appears to be that the font descender may have been used for alignment/padding, rather than the baseline. Agree though, when something is so burned into your psyche, tiny differences create a really aggravating uncanny valley effect.
Ditto with the 2.4x/2.6x kernels on Linux/ FreeBSD 4.x and KDE3 on top, with the first release of X.org. I am more like a Fluxbox + ROX guy, but if I had
to choose a DE, KDE3 was rock solid and featureful, and
you could disable Artsd just fine, dmix and OSS4 on earch respective systems worked well otherwise.
> 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.
Indeed but it does provide direct value to the open source community even when it fails in the more ambitious end goal. For example the ReactOS and WINE devs do collaborate a fair amount.
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.
If ReactOS is stable enough, it can also be an alternative for all the places where a very specific software runs on a very specific Windows edition, without having to redevelop the application (think ATMs or specialized displays)
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.
> relatively little investment compared to migrating to an OS on another kernel
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...
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.
Preservation. Think a library or museum archiving a piece of human culture. Not just the OS itself but the programs that run on the OS. If ReactOS succeeds you'd be able to run those Win95/98/XP era programs literally forever (think 100 years from now) as long as ReactOS is kept up to date and compiled on new processor architectures. Sure you can target running the real original OS as well but this requires a virtual machine and doesn't always work right, since drivers have to be written for the legacy OS to support the VM virtual hardware in some cases.
When Linux the kernel will eventually be completely absorbed into systemd, and the Mac will turn into one giant Touch Bar, there will remain only two contenders for the reasoned user: Windows and ReactOS. (Unless Apple buys Microsoft by then, that is.)
How much of the windows churn over the past decade has been widely accepted as good by the users?
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 have been as skeptical as the parent post. You make a good point though. Getting to Windows 7 at any point this decade will give them a real shot at increasing user base. I assume most people would be happy on Windows 7 as on Windows 10 outside of becoming comfortable on Windows 10 over the past 5 yrs
What makes you think being more popular, as popular, or even a fraction as popular as Windows (which is used on billions of devices) is a goal?
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.
I've noticed a couple things over the last half decade:
- 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.
I think there's a huge argument for a "controlled" Windows-compatible OS.
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.
I think with Windows 10 being the last version of Windows, ReactOS will eventually catch up.
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.
> I think with Windows 10 being the last version of Windows, ReactOS will eventually catch up.
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.
If they cared they'd try something like what OpenSolaris did (file-based GPL alternative so they could have copyleft on code but still ship binaries). I'm not advocating for another viral license but there are definitely ways around that problem.
MS itself already did it in part once (WRK) so they clearly have looked into it at least once before.
If you're asking if they are formally allowed to do it, the answer is definitely no.
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.
I forget the details, but generally, no. They want a clean room implementation, so if you've seen the code, you might even unconsciously copy it. They've taken license matters very seriously, so ReactOS devs would probably actively avoid looking at the code for the legal safety of the project.
Quite the opposite, any developer that so much as glances at the leaked source code is banned from the project. The legality of ReactOS rests upon its developers reverse engineering Windows without having access to the source code.
As far as I'm aware you can however look at the leaked source code and use those insights to fix or write documentation about the behavior of the APIs and general behavior. You just can't write any ReactOS code yourself because you are tained once you've seen the leak. But I think the overlap between people who can extract insights from the leaked code and people who enjoy writing documentation in their free time (more than reverse engineering and programming) is pretty small.
> As far as I'm aware you can however look at the leaked source code and use those insights to fix
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).
Bryan Lunduke on Youtube and LBRY, has as a wishful hope for the future of ReactOS.
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.
Making Windows open source has been brought up before, and I’m just quoting what has been said and it could be wrong, but lots of people made the claim that Windows is such an old codebase with 25+ years of different people (and, sometimes, companies) involved that it’s a huge legal task to be able to open source it. So even if it was in the interest of Microsoft they’d have to remove a lot of legacy code or track down individual contractors and get permission to do so (not to mention hardware support that may have been given to them under a proprietary license.) Again this could be bs, I’m not sure, but it makes sense if this is the case.
Will not happen while OS department is profitable, or even afterwards. They would just build on top of open source project (no source code of old IE versions).
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.
More than their prod code, I'd love them to open their win32 test suite.
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.
It would also make an interesting companion product if the rumors of a switch to the Linux kernel turn out to be true, though more likely they'd just "Linux 10" alongside Windows for a while.
Is ReactOS capable of running all the Windows software OK already? I'm curious if I can actually use it instead of Windows whenever I need a Windows VM.
Wine tends to have far higher compatibility, and the operating system it runs on top of is mature too.
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.
I gather ReactOS builds upon the work for WINE and other open-source Windows-compatibility libraries - nothing wrong with that, but it isn't as impressive as it sounds - not that ReactOS as-a-whole isn't impressive as it is.
-----
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...
If that's Russia's backup plan then it's severely underfunded. I'm sure Russia could hire a couple of capable software engineers/reverse engineering experts to contribute to the project (just as the US Naval Research Laboratory employed people working on TOR). But if Russia is doing that, then clearly not enough to bring ReactOS to a production-ready level within the next decade.
Given current US direction, I hope ReactOS is getting suitably security audited...
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...
Out of curiosity - what do people use ReactOS for? Does anybody daily it, or is it mainly used as a testing environment for certain Windows applications? I'd love for somebody who uses it to comment.
When I followed this link via Chrome, a tool tip popped out of my address bar ("Did you mean reactjs.org?" with some warning about attackers using deceptive URLs). I wonder if there's a way to whitelist URLs with Google to prevent users from seeing this message. Especially since I believe ReactOS has been around long before ReactJS
Chrome user here - I didn't get any notifications or popups like that. Do you have a third-party Chrome extension installed? I know a lot of AV vendors love to auto-install their own cyber-security browser extensions that report stuff like that, so it could be that?
No*, but I visit reactjs.org regularly, so this could also be due to Google tracking me. In full disclosure, I clicked the article thinking it was about ReactJS. I've never used ReactOS, though I've been aware of the project (and visited their webpage) before ReactJS was even a thing.
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.
it's definitely a feature that's been around chrome (I'm remembering from both mobile and desktop) for a while. I think the way they show this message has changed over time and probably don't show it if you think you're an advance enough user, that'd be my guess. or maybe you have an extension that stops u from seeing this
> Especially since I believe ReactOS has been around long before ReactJS
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).
I wasn't referring to me whitelisting sites, the tooltip wasn't an issue for me.
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.
A bit off topic, but I'm glade to see a project like this running there own instance of matrix instead of the usual centralized/proprietary/censurable solutions.
On the contrary, I'm sad to see them moving towards "slack clone" solutions rather than sticking with simple chat, a la IRC. I don't think adding stickers and emoticons to a conversation makes it any better.
We didn't do it just for the eye candy, but also for threads, offline messages, and user identification.
I wrote down our reasons for moving from IRC to a self-hosted Mattermost here: https://reactos.org/project-news/new-discussion-platform/
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!
Emoticons absolutely make it better, just by saving chat traffic for simple acknowledgements. Emoticons are also used as a simple way to poll, which is very useful.
But they're annoying to type. I never end up using them because I'd have to go look up the icon for something, then copy and paste. I think phones have keyboard features or something, but I actively avoid typing messages from a phone because it's so slow. This represents another move towards "mobile-first" stuff, which I generally dislike.
You are entitled to your preferences, but let's not dismiss actual practical advantages of emoticon support in Slack-likes compared to IRC. I agree it has costs as well as benefits, but dismissing the real benefit is a bad manner.
In slack, at least, typing a colon begins autocomplete by name, which is mostly how I type them: e.g. `+:+1:‘ to react to the post above me with a thumbs-up.
There was some Quora answer according to which ReactOS is derived from an proprietary MS research code. Doesn't it mean it would have legal issues if ever they decide to use it in anything close to real scenario?
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.
Even if someone had access to compare it, I wouldn't put the probability at 0. Windows has a pretty specific way of naming types, fields and functions. Some of those leak through error messages and other methods of introspection. They're have to match on a few very esoteric private fields to support that argument.
The guy seems to point to the reasons for his opinion, that's why I'm asking. I'm not so invested to check symbol names in the reactos repo vs the leaked code.
It was by one "I am very smart. Nobody can be as smart as me" Microsoft programmer. Who completely dismissed this explanation https://youtu.be/2D9ExVc0G10
ReactOS denies those accusations. If it's true and proved, probably users should stop using it, but until it's proved, I don't think that it's an issue. Like you've got some software, you checked its license, it's open source reimplementation of Windows, sounds good. For example Valve uses wine to run games on Linux, it's pretty legit.
WINE and ReactOS are separate projects and the allegations in the Quora post are specific to ReactOS. WINE doesn't handle NT kernel internals; it reimplements public Windows APIs and proxies kernel functionality to the host userland (usually GNU+Linux+X11 but occasionally Darwin+AppKit).
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.
BSD networking was distributed under a very permissive license, so that would extend to any new APIs included in BSD. You'd have to argue that the BSD license doesn't cover API rights, which would basically be like trying to argue that it's not really permissively licensed at all.
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.
Sounds like FUD - There are things like NT4.5 which is NT built from university source copy of (as the name suggests) NT as it was somewhere between 4.x and 5.0.
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.
[1] https://github.com/QubesOS/qubes-issues/issues/2809