mirror of
https://github.com/reactos/web-content.git
synced 2025-04-17 07:09:51 +00:00
45d33cf1ba
That way they really work as on our old website, otherwise it was reactos.org/project-news/node/295 and not reactos.org/node/295
9 lines
5.4 KiB
HTML
9 lines
5.4 KiB
HTML
---
|
|
title: "Use cases for ReactOS"
|
|
author: "Z98"
|
|
date: 2013-05-26
|
|
aliases: [ "/node/661" ]
|
|
---
|
|
|
|
<p>Many people see ReactOS as a Windows XP successor, a way for them to avoid the changes Microsoft brought about in Windows 8. This is a somewhat idealized goal, as ReactOS would need to be much more complete before it could attempt to fill in that role. There are however other use cases for which ReactOS is much closer to being ready for. Many of these however are more business use cases than consumer use cases.</p><p>Remote Desktop Thin Client</p><p>ReactOS actually has a working remote desktop client, though it obviously needs fleshing out to support the newer security protocols in later versions of Windows. That said, having a remote desktop client allows one to run applications on the remote server, not on ReactOS itself. This significantly reduces the components that need to be robust, as all ReactOS needs to do is make sure its network stack is stable and win32 can handle all of the drawing commands sent it.</p><p>POS Client</p><p>Point of Sale clients are locked down computers intended to run only one application. They're used everywhere from sales registers to kiosks to ATMs. Their specificity means that while they generally are running an application, they do not need to support nearly as wide a range. The user is also locked out of a lot of functionality, so there is less risk of them monkeying around and breaking something by accident. This scenario can also be extended to say industrial systems that are intended to run only a specific set of applications and drivers. These systems are not meant to be used to browse the web and generally should never be connected to the wider internet, so again less variability.</p><p>Remote Application Host</p><p>This is something of a new one, made possible by the wider spread of broadband. The idea is to provide hosting of a single application or groups of applications that can be accessed remotely. Marketing types like to call this the "cloud." Developers and system administrators call it networking. The difficulty has however always been the cost of licenses. To run Windows applications, one needed an instance of the Windows OS. Microsoft's licensing does not permit sharing of such instances and companies trying to pull this application host off have had to basically pay for a separate license for each user. But for a strict subset of applications, ReactOS could conceivably act as a replacement, allowing companies to spin up as many or as few OS instances as they need. This scenario can also be applied to compute instances, where some kind of scientific software needs to run on Windows and a scientist wants to run computations in parallel on multiple machines. The traditional approach was to use Windows desktops owned by the organization while they're idling, but to spin up instances in something like Amazon EC2 would again require a valid Windows license for each separate instance. Feasible, but it adds cost compared to a dedicated ReactOS instance.</p><p>Research and Development</p><p>One issue that Microsoft suffers heavily from is the need to maintain backwards compatibility with a huge range of applications, many written during an era where programmers were a lot sloppier when it came to security and compartmentalization. As a consequence, Microsoft can be almost considered deathly afraid of breaking things by improving existing APIs and frameworks. A lot of other projects and companies don't even really try to maintain that level of compatibility. Case in point is Apple, who will deprecate and outright drop things the moment it has come up with something it believes is better. And yet ReactOS offers an interesting opportunity. While the project is heavily interested in backwards compatibility, we do not suffer nearly as much risk as Microsoft in making tweaks that could potentially break that compatibility. After all, it is not as if we have thousands of customers that would call for our blood if we accidentally broke something, or shareholders that would want heads to roll if a change does not appear to be well received. Then again, the open source community is hardly the paragon of civil feedback, but that's a tangential problem. But the ultimate point is that ReactOS can make tweaks that Microsoft cannot or will not make for fear of risking breaking compatibility. Furthermore, ReactOS can theoretically act as a sort of "strict" implementation of the NT and Win32 API, acting as a sanity baseline for application developers to see if they are accidentally attempting to use undocumented functionality or misusing documented functionality. This benefits many people, both developers and users. It actually would also theoretically, perhaps ironically, benefit Microsoft. As mentioned above, Microsoft cannot risk improvements breaking existing frameworks and consequentially is very conservative about even considering them. This however also means such improvements never really get the chance to be tested in the wild to see whether they actually break anything. If however ReactOS did make such tweaks and released them, we would get feedback about whether it broke something or not. That knowledge would be there, publicly available for anyone to use. For that matter, the WINE developers might also find the information useful. Regardless, ReactOS can act as a testing ground to improve the Windows desktop experience, which will ultimately benefit everyone.</p>
|