4 ms·

i thought reactos contained portions of windows NT code?

by aliswe 5y ago

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
    Yes, I remember that discussion, it was very interesting, but it was quickly became obvious that the whole thing is very nuanced, and what may seem too much of a coincidence for an outsider (comparing the codebase of stolen or licensed source code of Windows with React OS), it could have a very rational explanation. They took the huge effort of complete rewrite and clean room implementation just for that! So not only it would make no sense for them to cheat, it would mean actually harming the project and causing its demise. Nobody in their right mind would do so.
  - josefx 5y ago
    > 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. Someone put namespaced functions into a folder named after that namespace? If it wasn't for that classic C style filename I would have suggested a call to the K&R police for the most heinous crime of all: the attempt to write maintainable C code. Wine also isn't providing driver API compatibility.

i thought reactos contained portions of windows NT code?

by aliswe 5y ago

i thought reactos contained portions of windows NT code?

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
  Yes, I remember that discussion, it was very interesting, but it was quickly became obvious that the whole thing is very nuanced, and what may seem too much of a coincidence for an outsider (comparing the codebase of stolen or licensed source code of Windows with React OS), it could have a very rational explanation. They took the huge effort of complete rewrite and clean room implementation just for that! So not only it would make no sense for them to cheat, it would mean actually harming the project and causing its demise. Nobody in their right mind would do so.
- josefx 5y ago
  > 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. Someone put namespaced functions into a folder named after that namespace? If it wasn't for that classic C style filename I would have suggested a call to the K&R police for the most heinous crime of all: the attempt to write maintainable C code. Wine also isn't providing driver API compatibility.