ReactOS 0.4.4 Released
reactos.org
reactos.org
Many of the comments here are saying they're surprised it's still alive, or that it's sad someone would work on it, or that it should have more features. You're all missing the point.
If we skip practical part, ReactOS is great as any big community-driven project, because driving a big project is hard.
I know of many vitally important systems that are still running on DOS, Windows 3.1 and a variety of even more obsolete platforms. I expect that Windows XP will continue to be a significant platform for several decades. If ReactOS ever gets out of beta, it'll be a boon for huge numbers of users.
Having an open source clone of Windows makes perfect sense. Imagine if, after all those years, this project received more support from the open source community. Today we would have a free and open source OS that would be able to run Windows drivers and the Win32 apps people want to use. Adobe's stuff, AutoCAD, AbletonLive, games, MS Office, etc.
In the end, the average person doesn't care about operating systems. What they care about is their apps.
6 years ago we thought netbook thin clients paired with powerful backends would dominate. But here we are in 2017 - server side rendering of UI is waning while rich and robust client side interface applications are thriving.
I think that late 2000's/ early 2010's vision of local computing withering in the shade of cloud resources is over. It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
But a huge amount of them use web technologies which are pretty much OS independent. I'm using Linux for 10 years now and I used to have trouble to work with others because they where all using Windows-only software (proprietary chat client, MS office, etc.) but it's less the case anymore because for many use-cases everybody uses web applications instead of native software.
> It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
That's why JavaScript is the dominant language out there. And with WASM comming, even what's currently out of reach of JavaScript will be doable on a web plateform (except high-end gaming maybe).
Fixed that for you.
I am a developer, with UI experience going back to Amiga/Windows 3.x days, and will only touch Electron if forced by customers/employer to do so.
I've found the development experience using TypeScript and React to be fairly pleasant, though. I know some people gripe about JSX/TSX, but it seems to me it's a lot like XAML - declarative XML that you can use to lay out your interface and hook up event handlers.
I've been enjoying the UWP, WPF, and macOS ports of React Native. They make it fairly easy to get up and running with something that'll let you share 80% of your code cross platform while still making it easy to write extensions with the native OS toolkit when needed. From what I've observed, RN desktop apps are much more CPU and memory efficient than Electron apps. In my mind, this is a much better way to create desktop applications using (mostly) web technology.
It's the business which is pushing for JavaScript: for most product nowadays you need to support both Windows and MacOS. Now you need to consider the following trade-off: do you want native apps at the expense of two code bases ? Or do you prefer a portable one at the expense of quality ?
In many cases the answer is a cleary the second option. Now you just have to chose which portable runtime you want: Java like it's 2000 or the web which is the current norm.
An hybrid approach is Qt since it wants to be a tool to build portable native apps, but in fact they are neither really native (the UI doesn't feel right) nor really portable (it often doesn't work out of the box).
Case in point: OSM editors. iD has very low barriers to entry: it's all in-browser, integrated with the website, nice rounded corners, and no dependencies - but it's slow and unable to keep up with edits > 500 nodes (because it's a memory hog built on a memory-hog JS framework running in a JS+DOM memory-hog virtual machine inside a memory-hog application). JOSM, on the other hand, is not quite native (Java being a memory hog of its own), but is capable to use persistent caching and relatively efficient memory structures. (I'm explicitly not comparing the feature set, which stems from different usecases or ease-of-use, which is somewhat subjective: this is in comparison of rudimentary editing operations)
>>but it's slow and unable to keep up with edits > 500 nodes
It is perfectly possible to build a fast JS app. The one in your example is not well optimized.
With web apps there are issues such as vendor lock-in of your data (like doing accounting in a webapp) try getting your data out.
Vendor updating to a new non functional version of their web app while you liked the old one.
Security issues because your data is now on the internet instead of on a local PC.
You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
You can use self-hosted web apps or a vendor that allows export of data. You can use a vendor that allows loading/saving data locally.
>>Security issues because your data is now on the internet instead of on a local PC.
The same is true for most local apps. How do you know they are not leaking your data?
>>Vendor updating to a new non functional version of their web app while you liked the old one.
True for local apps as well
>>You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
There are always limitations, but web apps have less, which is why they are winning.
While self hosting webapps certainly is possible, this is not an option for the average user.
With a local app you can make it certain that it isn't leaking by not connecting it to the internet?
I guess we will have to agree to disagree on this as you are clearly looking at this from a different angle as I do.
(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --
As a user, when given the option, I always use native.
And I know many that do the same, specially in mobile apps.
At work, when given the option, I rather produce native applications than web ones.
Idk, maybe I a sheltered in Silicon Valley, and I know that most of the buisiness world has a lot of legacy windows apps you need to run your buisiness, and if it ain't broke no one is changing it. But, for new apps, I don't see why you wouldn't do SAS. It will be a slow process for sure but I can't see what will reverse it, except for maybe widespread privacy concerns about the cloud.
I hope you don't use web apps, ChromeOS or Android then.
You're critical of Windows for collecting data, but use other software that collects similar data, saying "that's fine I have 3rd-party privacy tools". These same tools have existed for Win10 since week 1.
He has entirely FOSS stacks for his devices? Quite literally no proprietary code wherever possible?
They're not "3rd-party privacy tools" he's making a point of, outside of a browser which isn't what the complaint is about on Windows, since that is outside the bounds of OS-specific complaints, but he mentioned it nonetheless since you asked about it.
On a fundamental technical level, windows 10 is a pretty finely tuned os.
On any other benchmark you might choose (privacy, invasiveness and advertising, user control, user experience, active user deception) windows has been going downhill for years.
Almost nobody could claim that it's a bad OS from a technical standpoint, though there are certainly significant improvements to be made. The real issue is lack of any semblance of privacy, user unfriendliness, and frankly the closed-down nature of it is never going to do it any favours.
In my view, apart from gaming, it has nothing going for it.
What Windows has going for it is that it supports a lot of different desktop/laptop hardware very well.
macOS doesn't support a lot of hardware. Linux supports a lot of hardware but much of it not very well.
If I list my desired specs for a laptop or desktop and then go ahead and buy the one that best meets my criteria, chances are pretty high that Windows will run best on it.
I have been a Mac user for many years. I'm using a Mac mini right now. But if I had to replace it today I wouldn't know what to replace it with.
I don't think that's the case. It's not that Windows itself supports more hardware, but the fact that drivers for said hardware are built only for Windows. It could even be seen as a vicious cicle: 1) HW manufacturers create drivers for Windows because It's more popular; 2) Users use Windows because "It Just Works (TM)" and so userbase grows; 3) goto 1
> Linux supports a lot of hardware but much of it not very well.
Hence I think Linux supports more HW but driver support isn't as good.
I get what you're saying though.
Damn it, Foxconn managed to ship a desktop motherboard that would produce junk ACPI data unless the OS identified itself as Windows on boot.
For Linux to compete with Windows realistically for average computer users it needs to have a distro that is like macOS in that it's idiot proof. I should be able to sit someone down in front of a computer running it with no instructions and the OS should do the teaching without telling them to open a terminal and look at man pages.
If you speak about this in /r/linux, the people there will tell you that "if people are not willing to learn how to use the terminal to install apps, then they're just lazy/too stupid". This is the kind of mentality we're dealing with and that's why there's 288 ditros without any chance of mass adoption.
Yeah, I understand that Windows wasn't like this, so people can get upset about the recent changes Microsoft is pushing onto. On the other hand Android has been like that from the beginning, so there might not be much expectation. But still I don't care Windows-as-a-service because nowadays pretty much every software I use is provided like that. It's just that the OS becamse not an exception.
On Windows the entire system and most well known applications are closed source, therefore not trustworthy, but on Android things are not that different: Android makes heavy use of closed source device drivers and so far any attempt to get a completely open system while keeping all the underlying iron useable has failed because most device manufacturers keep their hardware undocumented, save for Google and a few big players under NDA.
The point is that security is an OR: a chain whose strength depend on the weakest link; if one closed blob can contain a keylogger, having just one in an otherwise 100% open phone still makes the phone 100% potentially not secure.
Security is a process not a if/else choice, and Android is more secure than Windows because it is open source and you can replace Google parts. Good luck doing that on Windows.
And yes, Linux (and BSD) is also potentially insecure (or less secure if you prefer), which is the reason why the same effort who brought us a lot of quality Open Source verifiable software now should be directed towards obtaining also Open Hardware. We need to build a culture as we did with Open Source software so that people will understand the importance and associated risks.
Windows 10, never again.
It could be the indexing service for files. There is the NTFS MFT which is used by tools such as Everything by "void tools", but Windows also has its own Windows Search (WSearch) service which indexes files and contents. I believe this is similar to the Indexing Service found on Windows XP that would give you hopeless results (duplicates between its database and the actual file system). This is meant to make Cortana be able to give you helpful results when you search for things like files locally.
I have found it to be slow to type something into the Start menu (just type), particularly compared to the results from Everything (mentioned above) or Apple's Spotlight. It is very odd because Microsoft has its own SQL Server division (and SQLite is free if they want to use that!) as well as embedded SQL Server for file-based database systems yet their start menu search is horribly slow so as to be useless (for me at least).
I recommend buying Windows Internals 6 volumes 1 & 2 to understand what is going on, at least under Windows 7. There are not versions released for Windows 10 yet (and will there ever be? It's a constantly moving target).
Moving Chrome profile to a RAM disk helped somewhat, as did turning off some icon update stupidity or something like that in hidden Chrome settings.
But as you mentioned, if even the Start menu is lagging, I have no patience and no desire to investigate further, this is it. So instead of buying some utilities to make windows less crappy, I've finally had enough and installed Ubuntu on that last PC. Just to think about it, I was an MCSE+I and MCDBA some time ago, now I only boot windows for games.
Though worst from MS on spinning drives has to be using Visual Studio on a web project (or node dev for that matter)... it's painful.
A couple of years back, I set up my parents' notebook to dual boot either Windows 7 or Ubuntu 12.04. Despite the fact that both their printer and their (ancient) scanner worked out of the box (which did not work on Windows 7 at all), they have never used it.
5 of 6 years ago, my mother's old computer died. All the new ones where running Windows 7 while she was used to XP.
I seized the opportunity to install Linux on here computer instead of Windows 7, and she was OK with that because she was going to be in a new environment anyway. She is now a proud Linux user for 5 or 6 years :)
I installed Elementary OS on my niece's computer because she lost her Windows licence. 2-3 weeks after that, she told me her computer was "broken". The reason was that she tried to run some apps (win32) but of course it didn't worked.
Have a look at LibreOffice. StarOffice was open sourced in 2000 by Sun as OpenOffice.org and started somewhat slowly. By 2004 OpenOffice.org was making steady progress, and had captured quite a bit of market share.
Then the OpenOffice developers and Sun started stymying contributions, and eventually Michael Meeks setup Go-OO with a bunch of patches that made the program easier to use. Then Oracle bought Sun and really pissed off key external contributors so they forked the product and in 2011 The Document Foundation was formed to oversee LibreOffice development.
Since then OpenOffice.org has stagnated and withered on the vine, whereas LibreOffice has had entire swathes of old and cruddy code rewritten and each point release has not only got huge numbers of bugs fixed, but often new features - and often entire subsystems have been rewritten without the end user ever knowing.
So give it time - it's been just over 16 years since it the StarOffice source was opened to anyone. ReactOS has been around at least this long, and due to the nature of the project isn't quite as fast, but each time I read a new release it occurs to me that development is accelerating rather rapidly!
This has made it easier for open source competitors to catch up with Microsoft.
However compare that to operating system development - or to be more specific: reverse engineering undocumented APIs that receive updates every few years - and you have yourself a whole order of magnitude more difficult job to even just reach a usable parity let alone being a competitive alternative.
As quickly as ReactOS developers can reverse engineers Windows, Microsoft will progress their flagship OS. ReactOS is chasing a moving target in a way that LibreOffice is not.
Disclaimer: I'm not dismissing the developers efforts. I just don't agree with your statement that ReactOS will snowball in the same way that many other open source developments do.
ReactOS aims for WinNT series compatibility including hardware drivers. And those driver APIs haven't changed for a decade or more.
There have also been massive changes to the way Windows handles networking and authentication protocols (Active directory, SMB, etc), changes to the the driver model, changes to the way POSIX support is handled, etc.
As much as you might dismiss some subsequent Microsoft technologies to be "not very successful", the fact remains that Microsoft are still always pushing new technologies and a not so insignificant number of developers do sometimes use these technologies which means, at some point, the ReactOS developers will either need to reverse engineer those technologies as well (assuming those libraries can't run natively on ReactOS already _and_ there's no legal restrictions preventing them from running on non-Microsoft endorsed platforms) or accept a lack of parity with Windows.
And how much of it is actually needed? Considering only the actually useful parts of an OS, my impression is that Windows got saturated a long ago and the parts in later versions were just forced along in new versions due to reasons that have nothing to do with technological advance. My point is, ReactOS has only to become stable and reasonably good on real hardware to be successful. There is a lot of parts in the later Windows versions that only serve niches, thus being cruft for the bulk of users. Microsoft had to evolve this way due to its commercial nature, whereas ReactOS doesn't have to.
I don't get why people are pushing back on this point. It isn't a criticism of ReactOS. It's just a pragmatic result of writing a clone of another project that itself is constantly undergoing development.
This is why people more often talk about ReactOS being exciting in terms of supporting older software rather than new. Obviously if it ever got to the stage that it had parity with the latest releases of Windows then that would be amazing but the chances of that happening are miniscule.
I think this is where you're making wrong assumptions. ReactOS is free and open-source, and from this comes choice. Even if the main project chooses to work on reimplementing marginal or even unwanted things, a fork is always an option. (A fork from an immature project like it still is doesn't make sense for now.) After all, it's known that people don't appreciate bloat. ReactOS wants parity with Windows 2003 and that is a manageable target. Bits from later Windows versions may be added for important applications but it hasn't have to be nor is necessarily wanted all that Microsoft pushed from Vista hitherto. ReactOS doesn't have to cover all that much, really.
Also, an important nitpeek: ReactOS doesn't reverse-engineer. It employs clean-room engineering.
Yeah you're right it's not reverse engineering in the technical sense. It's a lazy term to use because it sounds like the approximation of the process even though it's technically inaccurate. I should get out of that habit. :)
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/me...
* the HAL - there have been changes here, but nothing so fundamental that can't be built upon
* kernel mode drivers - these have changed and new models keep getting released by Microsoft, but these rely on well defined interfaces and a lot of it is in the kernel mode driver framework (KMDF). A detailed history can be found here:
https://msdn.microsoft.com/windows/hardware/drivers/wdf/kmdf...
The user mode driver framework is similar.
I'm not going to go through the rest of the subsystems, you might want to review this document:
https://web.archive.org/web/20160113113554/http://research.m...
So... sure, things have changed over the years but they most certainly aren't radical enough to stall development of ReactOS.
ReactOS has a target of Windows Server 2003. If they decide to upgrade to a later operating system, I'm not quite sure I see that as a huge issue.
https://github.com/maharmstone/btrfs
Of course, Microsoft's driver signing changes make it a very expensive proposition to run on Windows 10, unfortunately.
[0] https://www.certum.eu/certum/cert,offer_en_open_source_cs.xm...
[1] http://stackoverflow.com/questions/1177552/code-signing-cert...
[0] https://blogs.msdn.microsoft.com/windows_hardware_certificat...
Of course malware authors don't care much about all this since they just find some old version of a driver with a known vulnerability, so the only it accomplishes is keeping a high barrier to entry.
Windows Embedded versions (7 through 10) are impossible to get a licence for without jumping through a shit-tonne of hoops, paperwork and scrutiny (been there recently and its almost like Microsoft don't want your custom even when its genuine) so there is a market but more of us embedded people are moving to Linux so you need to be quick.
Anyway Watching with interest and keep up the progress
Microsoft doesn't publicly show any signs of attention.
For a project like this it goes a long way towards staying relevant.
Just a few years ago it still looked like something I made for a school project with quick and dirty hacks in PHP in early 2000s.
Glad to see they took care of it.
Sorry, I know this type of comments are shunned but I couldn't help myself at this point.
Since intelligent design presupposes that a design was in place before implementation, you'd need a watertight specification to know what you'll need to design. This is pretty much the definition of the waterfall model.
Once you've started with the implementation, you'd not be able to deviate from the spec. If you're God you'd never make an incomplete or incorrect spec, right? By definition that'd be impossible.
With evolution change is introduced iteratively. Each generation contains tweaks and updates, is exposed to a barrage of tests and if it's less adapted to the requirements it's disposed of unceremoniously in favor of a version more suitable. Due to its iterative nature evolution is also able to adapt quickly to changing requirements and good/beneficial features are taken over into the next iteration.
As an aside, the most recent example of that I've come across, and much more relevant to current events (to US Americans, at least), was during the most recent Hardcore History podcast. It was pointed out that JFK won after he got a bunch of free press because of how photogenic his family was (which whether it was the reason he won or not probably helped quite a bit). Parallels weren't drawn to current events, but it's not like you need a political science degree to see them, which I found really interesting.
The first feeling that washes over you is a kind of despair that this question was asked at all, as even a cursory view of the information available in the OP, let alone a Google search, would immediately show the project is not related to ReactJS. You find it difficult to imagine the kind of mind that chooses to seek trivial answers from others rather than attempt to answer them on its own. This mind thinks nothing of wasting the time of others to satisfy its own meager curiosities. Surely, in this case, the time taken to ask the question takes almost as long as the research required to answer it.
However, you can't help but notice a deeper level of sadness swelling from below...
It's not merely that the question was trivial. For example, the question "What is this project for?" doesn't seem nearly as sad. Moreover, we notice that if ReactJS was an obscure or unpopular project then this user's question seems rather innocuous.
We see that your deeper sadness stems from the realization that this user is consumed and infatuated with the present trend in software development, whatever that may be. If he knew, he would not care that ReactOS predates ReactJS by nearly two decades. To this user, what exists now is better than what has ever existed before. After all, he imagines, every good idea and enlightened thinking in the history of computing has been brought to the present; these qualities are easily recognized by everyone and they naturally persist and become popular. Therefore, the popular projects are the best humanity has to offer both technically and philosophically. Likewise, obscure, small, or old projects have the opposite quality.
Learning of ReactOS for the first time, he is skeptical of how much of a "good idea" it could really be (surely he would have heard of it by now if it was worth knowing about). So, he attempts to establish the project's merit using the only method available to him: an appeal to popularity. Does this project relate to the current pinnacle of computing achievement, ReactJS? Being a React aficionado, he doesn't suspect it is related but decides to ask anyway just in case he missed something. He wants to know the answer, but ReactOS appears sufficiently unpopular (ie. irrelevant) as to not be worth any appreciable time or effort to discover it for himself. Besides, it is far more agreeable to his psyche that the crowd provide the answer.
There is a subtlety to the user's phrasing that enhances your sadness further. He does not wonder "is it related?" but rather "does this have anything to do with?". One gets the feeling that if only there were just the tiniest bit of relation to ReactJS then this user would be satisfied that ReactOS is indeed a worthy project.
There is a sense that this brand of thinking is 'shallow' or 'myopic'. That it is a brand of thinking that is destined to bring the industry to a state of perpetual mediocrity caused by the incessant following of trends instead of truth. That it is a brand of thinking that causes those under its influence to ignore the search for truth altogether as they are assured that truth is always provided for them, right here, in the present. And when real truth does arrive in those rare moments, it is a brand of thinking that renders it unrecognizable. This is troubling but it's not the sole cause of your depression now.
You are saddened because you know he is one of many.
The analysis was entertaining, but over-speculative.
Being an operating system automatically puts a project automatically on a different level or do you have a thing against JavaScript?
Why would anyone do this? For 13 years? Why?
Just about every popular general purpose operating system is some variation on UNIX. That is sad, just like it would be sad if JavaScript, TypeScript and Coffescript were the only popular programming languages. The only difference in scenarios is that the OS is much more significant and critical than the programming language.
Windows is fundamentally different from Linux and UNIX. ReactOS is a clean room reimplementation of that, bringing NT's many excellent ideas to the open source community. That is a good thing, even if you never get to use it. Don't forget that, just like in every other part of life, different != bad.
https://blogs.msdn.microsoft.com/oldnewthing/20070710-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20120913-00/?p=...
I am all for variety. Hurd, L4 -- these are fundamentally different from Unix and very interesting. ReactOS? well if you enjoy debugging windows kernel drivers without source code...
And yes, lots of people enjoy reverse engineering things like drivers.
Including Windows 9x which is based on DOS which is based on Xenix which is based on Unix. I didn't learn this until a few years ago, and it always seems to shock people in tech conversations.
Imagine a few decades from now, Windows has either transformed so much that it can no longer run certain things or it entirely disappears as a platform.
Something like ReactOS could become very useful to running legacy stuff or perhaps the code can be recycled for emulation/vm and legally offered for free. It can also be used on older hardware to bring back Windows applications/gaming, while also keeping it up to date.
I've already run into many issues trying to run older software from Windows 98/XP days. For example certain older tools for Quake1 modding don't work properly on anything past Windows XP.
Even something like Photoshop CS2 has certain bugs running under Windows 7.
The only advantage of ReactOS over WINE is that ReactOS has Windows 2003 compatible kernel. This means native Windows drivers, and faster emulation of some features.
However, a few decades from now, there will be no devices left which have Windows 2003 drivers. And hopefully CPUs will become faster, so Wine overhead will be negligible. And I doubt all the new devices will have ReactOS drivers.
Rather than keep going on ReactOS, I would much more prefer people making wine better.
What am I saying is that having an open source OS for Windows, is a huge deal if you are interested in hardware preservation for the future.
Therefore in reply to the original post about the current endeavor being "sad" I would say that it is quite the opposite.
Wine is very important as well, but it is a completely different piece of software in my opinion.
HaikuOS aims at BEOS compatibility and also works nicely.
ReactOS I've donated to them so they could reach their 4.x milestone.
If I was some rich billionare or a CEO I'd donate a million dollars to each alternative project.
Thanks for correcting me, looks like a pretty cool project will have to look more into it.
Link for anyone else wondering: https://en.wikipedia.org/wiki/AROS_Research_Operating_System
These days it's so much about only Windows, macOS, and Linux. And two of those are closed systems. Mobile devices are eating up more use cases by the day too, so I guess the golden era of desktop operating sytems are long passed. However, this sure makes me more sad than ReactOS being a thing!
I am curious what the story is, is this backed by some company? Was this almost abandoned along the way but picked up?
That is to say, I doubt they'd be running Aero Glass or UWP applications this month even if they hadn't lost time to the audit.
Fact is the moment ReactOS becomes a threat to Microsoft's business interests they will sue it out of existence.
Even if you ignore the patents issue, any re-implementation of Windows will inevitably be full of code looking similar to the Microsoft one, even if the authors never looked at the Microsoft code. And as the recent Oculus court case has shown, such a similarity is all Microsoft needs to successfully sue them.
I like the idea of project but I would never contribute to it because of the reality above.
And even within the US, ReactOS in its current state is perfectly safe: Microsoft has nothing to gain by suing them, but they would risk an extremely harmful precedent should they go to trial with their precious IP. Microsoft's patents and copyright FUD are effective tools against corporations, but not loosely organized collections of free software users.
They are doing what is basically a clean-room implementation of the Linux ABI to avoid the GPL.
What stops ReactOS doing the reverse? Microsoft have had 13 years to review the source code for ReactOS and haven't had a problem with it so far.
The only major issue arose internally:
> A claim was made on 17 January 2006, by now former developer Hartmut Birr on the ReactOS developers mailing list (ros-dev) that ReactOS contained code derived from disassembling Microsoft Windows. The code that Birr disputed involved the function BadStack in syscall.S. as well as other unspecified items. Comparing this function to disassembled binaries from Windows XP, Birr argued that the BadStack function was simply copy-pasted from Windows XP, given that they were identical. Alex Ionescu, the author of the code, asserted that while the Windows XP binary in question was indeed disassembled and studied, the code was not merely copy-pasted, but reimplemented; the reason why the functions were identical, Ionescu claimed, was because there was only one possible way to implement the function.[1]
It is a pity they did not get traction 10 years ago, when they could have competed with Vista.
Good to see that they are still around, though.