Comment by repolfx
7 years ago
I took a quick look at the structure of the WRK and ReactOS, as the MS developer suggested.
I can see what he means.
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/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.
Just wanted to comment that Googling "KeBalanceSetManager" gives this article [1] among others (the article mentions the leaked source code but it doesn't contain the code itself, just the description). Many internal function names were leaked with debugging symbols, and some people were reverse engineering those functions (for example, people who deal with malware).
The similarity in code can be explained by reverse engineering. For example, constant names in switch are different (TimerExpiration vs STATUS_WAIT_0).
> Why does this code in ReactOS exist if it does nothing?
Maybe because there is software that relies on the existence of this thread?
Regarding assertions and local variable names and same declaration oder, I don't know where they come from. That looks suspicious.
[1] https://github.com/bowlofstew/rootkit.com/blob/master/90210/...
> But it seems kind of unlikely: the Wine sources do not show this pattern.
Wine is not an NT kernel. Wine deals with the Win32 api, not the kernel.
> 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.
When trying to build an OS that is binary compatible with another, including the low-level like kernel drivers, surely it's expected that the prototypes be the same?
> The loop does nothing, just sits blocking in a loop forever. Why does this code in ReactOS exist if it does nothing?
Perhaps because the ReactOS kernel is note feature-complete, it's Alpha, so that part hasn't been implemented?