5 ms·

I wonder if ReactOS will hit 1.0 by the time that Windows 10 goes out of support in 2024. It would be interesting to see older systems retasked to a free clone

by chasil 5y ago

I wonder if ReactOS will hit 1.0 by the time that Windows 10 goes out of support in 2024. It would be interesting to see older systems retasked to a free clone OS, potentially running most/all of the same software. https://reactos.org/project-news/reactos-in-2020/ https://reactos.org/project-news/reactos-in-2020/

hdjjhhvvhga 5y ago
They won't let it happen. For now they decided to just ignore the project and not give it any publicity, but the moment it gains popularity, they will definitely react. Until now they attacked it indirectly through their kernel developer saying ReactOS stole his code - in spite of the fact they took all necessary measures not to and underwent an audit. This is the same old strategy Microsoft supported during the SCO trial.
- aliswe 5y ago
  i thought reactos contained portions of windows NT code?
  - hdjjhhvvhga 5y ago
    No. Imagine you are a ReactOS (or Wine etc.) developer. The main thing you can't do is to use any code you are trying to reimplement. It literally contradicts the very aim of your project: to create a legal viable alternative to a proprietary system. Moreover, you know it is the biggest danger and the main avenue Microsoft will attack you in the future, so you are extremely careful never to do anything even remotely illegal. When someone sends you links to fragments of Windows source code, you politely but firmly answer you are not allowed to look at this code. Because you know that if you look at it even once, an evidence of that could be used against you in court - and you are competing against the most important product of one of the richest corporations in the world, so you can't let yourself to be sloppy.
    - aliswe 5y ago
      This is part of what I read on HN: The first thing we observe is that the directory structure is basically identical. Yes, NT kernel subsystems are identified with short codes like "Ke" or "Ex". It's plausible that someone with a lot of NT knowledge would end up creating top level directories with these exact names, as is true of the WRK. But it seems kind of unlikely: the Wine sources do not show this pattern. If we look at the Kernel Executive (Ke) subtree, we can see that there is a thing called a "Balance Set Manager". Both source trees define it in a file called balmgr.c - not only the location of the file but also the file name is identical. https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr... https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b... It appears from the module description that the "balance set manager" is an optimisation of some sort related to reducing memory usage. Is this really something that needs a reimplementation with identical function prototypes? Looking at the code of the identically named KeBalanceSetManager function, we can see that not only is the function prototype identical, but the order in which it does things is also identical. First it changes a thread priority, then it schedules a periodic timer callback. Some of the local variables in these functions have identical names: PeriodTimer, DueTime, WaitObjects. Yes, these are obvious names. It's not a smoking gun. But it's not looking good. Finally we discover that the ReactOS Balance Manager does .... nothing. It enters a loop which starts out by doing a wait for an event (fine, it's inherent to the task), and then switches on the result. But the code in the arms of the switch are commented out (the commented out code does a subset of the stuff in the NT code). The loop does nothing, just sits blocking in a loop forever. Why does this code in ReactOS exist if it does nothing? It's the same story for the other big function in this file, KiScanReadyQueues. The code is virtually identical, line for line, with minor formatting and occasional trivial naming differences. Even the assertions are identical. I'm not alleging anything specific or illegal, just comparing a small part of both codebases. However given what I've just seen, I wouldn't touch ReactOS with a barge pole. The Microsoft guy's complaint is entirely understandable. https://news.ycombinator.com/item?id=20345645 https://news.ycombinator.com/item?id=20345645
      - hdjjhhvvhga 5y ago
amyjess 5y ago
I'd settle for being able to delete explorer.exe from my system and put the ReactOS shell in its place. I want to play modern games but with the Windows 98 desktop experience.
pantalaimon 5y ago
Doesn't ReactOS use the libraries from wine? So you could just run Linux.
- ACS_Solver 5y ago
  The point of ReactOS is driver-level compatibility with Windows. The project implements their own equivalent of things like the Windows HAL or Windows Driver Model, which ideally should mean ReactOS can be a drop-in replacement for old Windows machines used to run some piece of hardware that only has a Windows driver. There are still industrial machines being driven over parallel port by WinXP. The Win32 API program used for controlling the machine most likely works just fine with Wine, but the necessary driver definitely doesn't. The ultimate goal of ReactOS is that you could just install the driver on it and thus control the industrial machine exactly like WinXP did it. It's an admirable project, though of course it's nowhere near ready for use. Currently ReactOS doesn't run on a lot of real hardware, and is still well behind WinXP in terms of hardware support (USB memory sticks don't work, USB keyboards have problems, Wifi has minimal support and only for open networks, etc), but the goals of ReactOS are very different from Wine.

by chasil 5y ago

hdjjhhvvhga 5y ago

They won't let it happen. For now they decided to just ignore the project and not give it any publicity, but the moment it gains popularity, they will definitely react. Until now they attacked it indirectly through their kernel developer saying ReactOS stole his code - in spite of the fact they took all necessary measures not to and underwent an audit. This is the same old strategy Microsoft supported during the SCO trial.

aliswe 5y ago
i thought reactos contained portions of windows NT code?
- hdjjhhvvhga 5y ago
  No. Imagine you are a ReactOS (or Wine etc.) developer. The main thing you can't do is to use any code you are trying to reimplement. It literally contradicts the very aim of your project: to create a legal viable alternative to a proprietary system. Moreover, you know it is the biggest danger and the main avenue Microsoft will attack you in the future, so you are extremely careful never to do anything even remotely illegal. When someone sends you links to fragments of Windows source code, you politely but firmly answer you are not allowed to look at this code. Because you know that if you look at it even once, an evidence of that could be used against you in court - and you are competing against the most important product of one of the richest corporations in the world, so you can't let yourself to be sloppy.
  - aliswe 5y ago
    This is part of what I read on HN: The first thing we observe is that the directory structure is basically identical. Yes, NT kernel subsystems are identified with short codes like "Ke" or "Ex". It's plausible that someone with a lot of NT knowledge would end up creating top level directories with these exact names, as is true of the WRK. But it seems kind of unlikely: the Wine sources do not show this pattern. If we look at the Kernel Executive (Ke) subtree, we can see that there is a thing called a "Balance Set Manager". Both source trees define it in a file called balmgr.c - not only the location of the file but also the file name is identical. https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr... https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b... It appears from the module description that the "balance set manager" is an optimisation of some sort related to reducing memory usage. Is this really something that needs a reimplementation with identical function prototypes? Looking at the code of the identically named KeBalanceSetManager function, we can see that not only is the function prototype identical, but the order in which it does things is also identical. First it changes a thread priority, then it schedules a periodic timer callback. Some of the local variables in these functions have identical names: PeriodTimer, DueTime, WaitObjects. Yes, these are obvious names. It's not a smoking gun. But it's not looking good. Finally we discover that the ReactOS Balance Manager does .... nothing. It enters a loop which starts out by doing a wait for an event (fine, it's inherent to the task), and then switches on the result. But the code in the arms of the switch are commented out (the commented out code does a subset of the stuff in the NT code). The loop does nothing, just sits blocking in a loop forever. Why does this code in ReactOS exist if it does nothing? It's the same story for the other big function in this file, KiScanReadyQueues. The code is virtually identical, line for line, with minor formatting and occasional trivial naming differences. Even the assertions are identical. I'm not alleging anything specific or illegal, just comparing a small part of both codebases. However given what I've just seen, I wouldn't touch ReactOS with a barge pole. The Microsoft guy's complaint is entirely understandable. https://news.ycombinator.com/item?id=20345645 https://news.ycombinator.com/item?id=20345645
    - hdjjhhvvhga 5y ago

amyjess 5y ago

I'd settle for being able to delete explorer.exe from my system and put the ReactOS shell in its place. I want to play modern games but with the Windows 98 desktop experience.

pantalaimon 5y ago

Doesn't ReactOS use the libraries from wine? So you could just run Linux.

ACS_Solver 5y ago
The point of ReactOS is driver-level compatibility with Windows. The project implements their own equivalent of things like the Windows HAL or Windows Driver Model, which ideally should mean ReactOS can be a drop-in replacement for old Windows machines used to run some piece of hardware that only has a Windows driver. There are still industrial machines being driven over parallel port by WinXP. The Win32 API program used for controlling the machine most likely works just fine with Wine, but the necessary driver definitely doesn't. The ultimate goal of ReactOS is that you could just install the driver on it and thus control the industrial machine exactly like WinXP did it. It's an admirable project, though of course it's nowhere near ready for use. Currently ReactOS doesn't run on a lot of real hardware, and is still well behind WinXP in terms of hardware support (USB memory sticks don't work, USB keyboards have problems, Wifi has minimal support and only for open networks, etc), but the goals of ReactOS are very different from Wine.