A Kernel Engineer at Microsoft's Answer to “What Do You Think about ReactOS?”

From what I understand a lot of the kernel work was done by clean-room reverse engineering. One person decompiles and documents the system and another re-implements given the documentation. I can easily see how this would result in identical structures and naming.

[1] - https://reactos.org/wiki/Audit

It’s also worth noting that large portions of ReactOS come from Wine and I’m sure those portions have plenty of internal NT structures too.

The bits about NT not being documented are bordering silly, though. The lack of documentation has certainly never stopped anyone. Stardock for example does some very interesting and very undocumented things, as do many (most?) DRM and obfuscation engines.

Personally, I think that if ReactOS has really stolen substantial amounts of code, then it genuinely didn’t pay off and probably was not that useful.

One personal experience: years ago I worked on a project where I had the task (I will not go into why..) of re-implementing some tricky, non-documented functionality for which I had the source code for another implementation available to study, but also the goal to make it hard to prove from inspection of the code I wrote that it had been inspired by said original code. So in essence, I had the task we postulate the ReactOS developers had, if they indeed were using leaked ntoskrnl source as a reference. Ok, so when I had that task I did things like re-order the declaration of variables; change variable names; think of ways to refactor such that logic was split over a different number of functions; and on and on. Basically: I did a bunch of things designed to NOT permit the kind of "ah ha! : these things are the same" analysis that we see here. You might call this "derivation obfuscation".

So I'm a bit confused: either the ah ha analysis is flawed; or the RactOS devs just didn't care about being found out, right? Because if they had wanted to, it wouldn't have been hard to obscure, at least to some degree, that they were deriving their code from MS's original source.

Many internal symbol and function names are available with debug symbols that have been released by Microsoft over the years.

Lots of undocumented internals you can learn about from this book: https://amzn.to/2XHhSFF

If the book doesn't match what you see (which isn't that often), then you just single-step and see what's happening.

I remember reading that even inside Microsoft, internal structures had to remain backwards-compatible because external, "very important" programs relied on them (violating the public API of course). I can't remember the source, unfortunately.

Now it would be interesting which aspects can affect compatibility and thus be part of a normal reverse engineering on the ReactOS side. For example, C usually does not remember structure names after compilation -- but "usually" is not always and depends on compilers, macros, and whatever somebody invented. The most interesting findings would of course be names that have absolutely no effect post-compilation AND were never published.

> If any of the presumed authors wants to chime in and explain the similitudes, I’m happy to change my mind, but be ready to answer some though questions about the origins your coding and naming styles, and all the design choices that you made and why you ended up architecting and writing things the way you say you did ;-)

On the internet, the burden of proof is on the accused.

We don't use the leaked code from MS,

We don't use Windows Research Kernel,

We thank you for the PR campaign you have stared 'pro bono' for our project! ;D

I have also seen some pretty good reverse engineering of nt native APIs out there.

Can you taste the power-trip?

The fact that Microsoft haven't acted for all this time is by itself evidence that could be interesting to present.

Contrast this with another chunk of law in trademarks where ignoring use and not challenging it strengthens someone elses laches defense.

(Usual disclaimer: I'm not a lawyer so these words are likely just words assembled by 400000 chimps for bananas)

It's the "internal data structures, macros" stuff that is problematic.

https://www.computerworld.com/article/2522017/microsoft-admi...

What I will say is: I hope Axel's post doesn't negatively effect his career. We've all seen how controversial opinions and politically incorrect behavior have ended peoples employment in the past, and I honestly think its a ridiculous over-reaction.

I can't help but wonder if some of the answers here are driven by emotional, anti-MS sentiment. Some people seem way too invested, lmao. Just get some pop corn and see if anything interesting turns up. It might turn out to be a good history lesson.

[1]. https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists

I hope by the time I have to give up Windows 7, ReactOS will have a viable alternative - or that it and the rest of the market will have forced MS to get its act together. Maybe give me the Windows 11 I really want.

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.

My experience goes back to the days when I was using Lifeboat Associates' distribution of Tim Paterson's 86-DOS and before that Gary Kildall's CP/M on S-100 machines and that was before Bill Gates purchased 86-DOS from Paterson for a pittance which he then used as the basis of MS-DOS. It was the unfairness of that deal that has made me extremely wary or Microsoft ever since—it was wariness past decades since then have taught me was the right stance to take.

I would also point out I have no direct allegiance to ReactOS per se except that I've tested it on multiple occasions and found it quite unsatisfactory (unfortunately), in fact over the years I've dubbed it "The Going Nowhere OS".

I have no comment about whether ReactOS is a 'ripoff' of Windows or not as I'm not acquainted with the facts. I would suggest however that Axel Rietschin use the word "ripoff" with great care given that he's working for Microsoft—he should take heed of the old quip about "glasshouses" and "stones". I would however excuse his exuberance if he's young enough to be a victim of air-brushed history which large corporations are so good at creating.

The key issue that everyone has essentially missed is why this seemingly foolhardy attempt to recreate Windows was attempted in the first place and I'd suggest that it has its roots in the failure of government to uphold existing US Antitrust Law which has a long history back to the Sherman Antitrust Act of 1890. Especially from the Reagan era onward, administrations have failed spectacularly to stop the growth of digital-era monopolies let alone extend Antitrust Law with much-needed extensions that befit the digital era. (It's been clear for years that not only should Antitrust Law be modernized for the digital era but also the changes must be of a degree of sophistication that will make them effective rather than just being a paper tiger).

I don't have the time here to develop all the arguments and go into all the ins and outs about why Microsoft and its Windows monopoly happened and why ultimately the monopoly is a disaster for both users and computing generally so I'll attempt to use a crude analogy to illustrate my point.

Let's pretend that in the 1800s a potential railroad owner had managed to patent the standard rail gauge but either because of ineffective patent law or that government failed to police existing law the patent owner was not obliged to license the technology to his competitors for reasonable fees (or that he refused to issue licenses altogether).

He now has an effective monopoly and investors say whoopee and they invest sufficient capital to build a dozen railroads that span the US from east to west which are sufficiently separated north to south to cover 90% of the country.

In the meantime, his competitors complain to Congress and Congress realizes the error its ways and changes the law to force the patent owner to license the technology for reasonable rates. Meantime, the monopoly has been effective so his competitors are unable to raise the funds as investors believe that the ROI on the remaining 10% will be too small and thus the venture is too risky an investment—especially given the huge initial cost to get the project started (an amount that was fine for the patent owner who had the whole country at his disposal but far too risky for latecomers). The outcome: the monopoly remains in place and the final 10% of the country remains unserved.

Now consider the case when Congress doesn't amend the patent law and 10% of the country still wants its railroad coverage. Anarchy breaks out and each little town defies the law and builds local railways in defiance. In the grand schema of railroad coverage of the US, this hardly matters but many are mighty pissed off that their government has let them down. One of the consequences is that once law-abiding citizens lose respect for laws and law-makers and ultimately the rule of law generally.

When the law breaks down either through existing law being not enforced or through inadequate law—especially when the reason for government taking no action is because of the effective lobbying of monopolists—then you cannot blame the citizenry for taking the law into its own hands (after all, government governs only by content of the citizenry as Thoreau aptly explains in his famous 1848 essay "On the Duty of Civil Disobedience").

You only have to look around you at the world today to know "ethics" and "government" are incongruous words and have been on a collision course for decades. In these circumstances I can only encourage the ReactOS team to continue what they are doing and damn the consequences. (As it seems to me things will only get worse before we come to our senses, so let's get it over with.)

As far as most *nix and open source users are concerned, Microsoft has been a dead, rotting elephant with flies all over it for a long time and someone urgently needs to clean that up. Looks like someone wants a little attention.

I wasn't born yesterday

That said, frankly its probably not a big deal because reactos, has been pretty clear about making a best case effort to avoid this kind of problem and solving it when it happens. Hiring 3rd party IP review companies to compare their code with the illegitimate windows drops is probably fairly inexpensive (given how much I seen paid during acquisitions I've been involved in) and something I imagine they have done. Its the kind of thing I might even expect that having a dialog with the right people at MS might go a long way to helping reactos avoid infringement. Heck it wouldn't surprise me if MS would fund something like this.

OTOH, it might take a more premium review service to assure compliance. I spent some time reverse engineering win2k, reading the native api book, and various other books full of windows reverse engineering documentation at the turn of the century for a driver project I was working on that hooked into some unusual parts of the OS.

NT has some wonderful documentation available which paints all the broad strokes, combined with Microsoft's own docs/samples/symbols/checked builds/etc and the fact that large parts of the OS seem to be written fairly well (and seemingly avoid a lot of spaghetti) doesn't lot of black box areas. NT also does a fine job with very verbose and descriptive variable and function names (unlike large parts of linux written to conform to 80 columns where frequently the solution to overrunning the column has been to name things very tersely).

So its not surprising that there are directory structure similarities. The natural thing to do is put subsystems in their own directories and nest them logically with the over arching architecture. Big swaths of the code are likely fairly similar as they fill out particular structures mostly with public field names, or even in the cases of non public fields the verbose NT naming convention would lend a reasonably high probability of name collisions in the undocumented parts.

Finally, if anything the two black binders full of internal secrets actually seem a bit weak. Looking at the long untouched part of my bookshelf with NT documentation, I have probably two feet of books not published by MS that are either entirely dedicated to reverse engineering, or are targeted towards driver writers looking to expand upon the official microsoft documentation. Including a black binder about half the size of the pictured one with various magazine articles, internet articles, etc I printed and bound during that two and a half years of my life.

Lastly, given I've spun up reactos a few times in a VM, I don't think MS has anything to worry about. I would love an opensource win2k clone, but its frankly no where near done. Some thing work really well, but many things simply don't work at all, or the thing crashes. Last time I ran it, the image ate itself. I'm also guessing more than 1/2 the work is being done by the wine project as they re-implement the userspace side of things, the core NT kernel simply wasn't that big in the win2k timeframe. If reactos had 1% of the developer effort that the linux kernel+core subsystems (systemd, dbus, etc) gets it would be a near perfect clone by now. After all MS wrote the thing in 5 years? (Cutler joined MS in '88, and NT 3.1 was released in '93).

http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w...

It's one of the most insightful posts I've seen on this site, and if true, would certainly help to explain why Windows is so much worse than other operating systems :)

As far as most *nix users are concerned Microsoft has been more like a dead rotting elephant covered with flies for a long time and someone needs to cleanup that mess. The engineers there should really take a look outside their bubble about how other competent developers think of their software.

His shock that this could be a clean room implementation would be meaningful, except that the WINE project has successfully clean-room reverse engineered much of the Win32 API (including private stuff) by observing how programs use them. Literally no one wants to read Microsoft code anyway; knowing them, it's probably horrendous.