There are lots of good answers in this thread. In particular, someone took the time to look at the code, and that person wrote it only took them minutes to find similarities that make my opinion difficult to dismiss.
About the lack of documentation, consider that only a tiny fraction of the kernel’s internals surface in the DDK. All our internal headers have a .w extension and are littered with directives like begin_ntddk, end_ntddk (and many others), so a large number of structures and many fields inside existing structures are hidden or replaced by a generic reserved field.
Macros names, parameters, etc. never appears in the compiled code. It is highly improbable (I studied math, “impossible” is not a word lol), almost surely impossible that a clean-room reimplementation ends up using macros for the same things, let alone macros with the same or similar names.
Also, consider that optimizing compilers emit code that is extremely hard to follow even for us. Heck, the debugger, together with the PRIVATE symbols that has the name of all private symbols, and the actual source code, has a hard time to sync with the disassembly with the code when stepping through. While it is possible to write code that behaves similarly seen from outside, it is again implausible that the expression of this behavior results in code that looks nearly identical to the original. Consider that the name of local variables is never part of the binaries, only public symbols are. Also, consider that the compiler aggressively optimizes out variables to reduce memory accesses and holds values in CPU registers as much as possible, so those variables, while conceptually present, don’t really exist as such in the disassembled code. How to explain that a reimplementation comes up with the same variables, declared in the same order, when those variables are optimized out by the compiler?
What about in-line functions, both explicit and auto-unlined by the compiler? How do you even know there was a function in the first place, and how do you invent a name that is identical to the name of said function in the original code?
Funnily, I had a conversation with a very seasoned kernel engineer (I report directly to him) about ReactOS and my Quora reply. He told me the team looked into ReactOS some time ago and reached the exact same conclusions: impossible.
In particular, this person distinctly remembers a hack he implemented (I’m not going to reveal any details, but suffice to say it was in response to some assertion by some 3rd parties that something Microsoft declared in a court of law as very difficult). He explained the hack to me in full details and, boy, hacky that was, and they found the same hack in ReactOS’s code, except that the présumer authors of that “clean room” implementation probably have no idea regarding why the hack was there.
Finally, “clean room” takes another sense when one knows that Alex (yes) worked for Microsoft until spring 2019 at least, as a contractor for a company called Cloudbase Solutions SRL. His Microsoft email address was email@example.com. I don’t know if he had access to the ntos code, or NTFS or anything else, but very close from home he was, for sure.
So to those who want to take my opinion to court, I say it’s a “careful what you wish for” type of thing, but again I’m not a lawyer, and in other regards ReactOS aligns with a very old version of the NT kernel. It is possible (my opinion only) that Microsoft does does not care?
"Never" and "only public" are wrong in the statement above, because non public symbols were indeed released by Microsoft.
I guess you are young enough not to know that Microsoft accidentally did release some NT builds with the names of the internal variables, and such builds were intentionally made with less compiler optimizations, allowing for easier reversing. Such events of releasing the internal names resulted in some very interesting stories and statements:
"_NSAKEY was a variable name discovered in Windows NT 4 Service Pack 5 (which had been released unstripped of its symbolic debugging data) in August 1999 by Andrew D. Fernandes of Cryptonym Corporation."
Private symbols are not the only way of gleaning more information, other examples I can think of are:
* Checked builds (prior to Win10). These builds shipped de-optimized kernels (e.g. no inlines) typically with copious debug strings which gave away important details. For example I gleaned a lot of knowledge of ALPC MSRPC from the checked build of rpcrt4.dll from Windows 8.
* SDK/DDK headers, especially in the brave new world of insider previews with preview SDK/DDKs there is sometimes information present which should not have been released including "private" information. Again bit of a grey area.
* The private symbols MS do ship. For example a significant proportion of the COM runtime has private symbols, intentionally. You can extract from those a surprising amount of system call structure information.
I'd recommend watching Alex Ionescu's talk at OffensiveCon about how he does reverse engineering on Windows to see many of these things in action. https://www.youtube.com/watch?v=2D9ExVc0G10
I'm not saying any of this would make it a clean-room re-implementation but to say ReactOS cannot possibly have been reverse engineered without just up and copying source isn't true.
It is very possible that some private symbols were part of some leak, but stolen data does not qualify as “shipping” :)
Again, I stand behind my opinion. I eyeballed some of the code side-by-side and there was portions where I could literally see a line-by-line correlation, which I can hardly explain.
Then if reversing the kernel is so doable using legitimate means, why ReactOS is still largely stuck in the early 2000’s, coincidentally where the major leaks happened?
However you seem to want to claim the only place those symbols can come from is being stolen. Of course in this case you use leak as a synonym for stolen, bit leak can just as much mean they were released accidentally by the owner, MS can't steal their own private symbols and release them on the web. I'm sure there's some symbol files traded in private scenarios which are actually taken through non public means but there have been actual incidences of public release of private symbols.
I'm not trying to claim that ReactOS is clean, I have no skin in the game from a project or user perspective. For all I know it might have lifted significant portions of its code from stolen source code or the WRK (which isn't stolen in so much as used without permission, which I'd regard as a totally different thing). I do however take exception to the typical software engineer's view there are somethings which cannot be reverse engineered into a almost similar form.
As to why ReactOS is stuck in the early 2000s, it could be because of all the source code which was stolen and put wholesale into the project. Although if that was the case I'd have expect MS would have sued the living shit of the project by now. It could also be because Windows was and is a very complex OS with many layers which if you're trying to re-implement with a team of 10s to 100s versus 1000s it's going to take a lot of time. It's seems unlikely that the project would spend the millions of man hours to create the abomination that is UWP.
Perhaps the best way to determine if ReactOS is unclean is for MS to open source the Windows Kernel, hell why would you even need ReactOS then :-)
“Windows NT 4 Service Pack 5 (which had been released unstripped of its symbolic debugging data)”
I’ve seen private symbols for sql server with the guid to switch editions published on the public symbol server for at least 6 months before they were pulled.
Full releases and service packs typically are stripped very well but if you are saying that no private symbols have been published to the public symbol servers then you are incorrect.
The only product that has been effective at stripping symbols traditionally has been office, they were always stripped if you could even get hold of them which was unlikely.
Don’t forget also you could download the checked windows builds which were very open.
Because they don't care or need about the newer MS stuff and also don't have the resources either.
Also they can exploit Microsoft good record of backward compatibility, once you have a good enough lower API compatibility, you can just install a lot of newer MS tech directly on top of it.
Even if that is the case, it's an incredibly poor idea to use them, so that the code ends up with spurious similarities in spite of being (otherwise) cleanly developed.
Because the former is fairly well documented and the latter doesn't seem right in the context of this discussion. If MS themselves messed up and published the symbols through an official channel that's fair game IMO. Although obviously IANAL etc... I'm talking from an ethical perspective, not a legal one.
I don't know much about ReactOS or the NT kernel but we have this type of controversy regularly in the emulation scene and while sometimes it's true that people reuse docs they shouldn't have, a lot of the time people underestimate the skill and cunning of reverse-engineers to figure out how things work without having access to any restricted information.
I don't really subscribe to a belief of absolute morality, but in the context of the discussion, I think that no matter how you got access to that code, if you say that you are reverse engineering it, then copying an implementation is not doing what you are saying you are doing (as well as being copyright infringement).
I think he's saying that even having access to leaked or accidentally released originals is not implicit permission to use it freely. Otherwise any piece of software that was ever legitimately released would be fair game, just throw it at a decompiler and profit.
If you're making a clean room design having so many similarities to the original is unlikely to happen accidentally.
Anybody implementing a clean room design should theoretically have no prior knowledge of the original's inner workings. The specs are written by one person, checked to not include any of the original material by a second one, before being passed to a third to be implemented.
From far enough a piece of wire and an isolation transformer do the same thing. The secret sauce is in that isolation, you can't just shunt it and pretend it's the same.
There IS public documentation for the NT kernel internals. It is called Windows Internals Book (https://amzn.to/2xCQla5) and has survived its’ 7th Edition
But still in 2006 ReactOS already had its 0.3.0 version and 8 years of existence ^) And book Microsoft Windows Internals, Fourth Edition has already been released in 2004
Of course it’s not a proper clean-room copy. This is immediately clear to anyone who’s worked on NTOS or who has source code license.
It been obvious for years. The only possible conclusion is that MSFT doesn’t care.
Not that I work for MS but I used to work on NT graphics drivers and had a copy of the leaked NT kernel source for a while (strictly for personal interest!). This so very like what I remember.
IMHO such blatant theft shouldn't really go unpunished.
You are the blackest pot in the history of computer software.
Not that microsoft has never crossed any lines - even the naming of the Windows operating system seems morally dubious - but in this case I don't see any issue with what they've done.
Looking at how slowly that project is moving though I think your conclusion is right: They don't care. In some other comment you mentioned how the project seems to be stuck in the 2000/XP area. How relevant does that make this project today? But whether it's based on stolen code or not, it seems like the right choice to focus on getting that completed before moving on to everything that came after. And after all, Windows isn't just the kernel. They have to implement a lot of user space too, because software out there might assume it's available and behaving in very certain ways. Just an explorer clone sounds like a mammoth task on its own.
I still find the project very interesting and overly ambitious, even if code was stolen. I think at their current pace, reactos won't become usable before operating systems became largely irrelevant and everything runs in the cloud. Everyone still working on it today is probably just doing it for the challenge.
You make a theoretically compelling argument like the "hack" you describe above and then leave out the only part that really matters where you prove it. It is entirely likely that you are simultaneously entirely correct and entirely unable to prove it due to company policy but this leads us to the next logical question.
If you knew you couldn't prove it why did you open your mouth? It seems the only result will be negative PR.
I have no intention of reading through millions of lines of code from a legally questionable source to make your point for you.
How about you do so and post an in depth analysis?
I'm thinking they'd disapprove. That's just a guess, maybe they think it's fine and great. However, it may be worth at least considering another possibility.
Does your company want random technical employees, making non-technical statements, about how people are "ripping off" MS?
It's your job to raise the flag internally and help people understand up and down the chain, and across functional lines the context and perceived severity of the issue.
It's your job to write a blog post about how great your containers are architected. Not be a lone wolf, self appointed spokesperson using inflammatory language on issues with potential legal implications.
Please don't take this comment in the vein of you're just an engineer shut up and code, in fact you have a critical role as someone with domain expertise.
The point is when you stumble onto a high visibility cross-functional issue, I've found on sensitive topics many organizations seem to appreciate when someone reacts by coordinating, discussing, and facilitating a cross functional, unified response with one designated voice, that acts in the best interests the company.
Secondly you object to me presuming I know what his responsibilities are. I don't claim to know what he codes. However I'm able to make a pretty good guess about what the scope of a MSFT senior developers job is and this kind of thing is not even close, unless it's a special case worked out in advance with others. It wasn't worked out in advance in this case because he says that he made the comments before getting feedback from more senior people on his team.
Finally I assume some of the down votes have mistakenly conflated my comments with trying to hide information behind corporate walls.
I advocate hiding nothing - and fully support the new generation of companies who believe in transparency and ethics.
Being transparent and ethical has nothing to do whatsoever with letting developers try and make legal decisions when it's not their area of expertise. It also doesn't mean that a company shouldn't work together across departments to try to decide the right thing to do.
Good management and coordination between roles don't preclude transparency or doing the right thing in anyway shape or form .
> First off I'm not policing anything, because, how would I have the authority to do that?
Maybe policing isn't the right word, but your earlier post was fairly condescending to axelriet. "I think they'd disapprove... It's your job to do this... It's your job to do that..."
Moreover, I don't believe in such a philosophy between any two people, so to the extent it is I regret the tone of the comment.
If it makes any difference, the true source of the tone was based on thinking similar to, holy crap that person is backing up into a stove someone speak loudly and quickly... There is no evidence for you to believe that, but I hope you will, somehow, decide the intent was nothing more.
Appeal to authority may be a classical logical fallacy, but it's a highly effective one and is used by many people to infer the merit of an opinion rightly or wrongly so. Yeah, I know it's weird, that people would associate a comment one person posts with the voice of a trillion dollar company. Just happens sometimes.
Moreover I have nothing to gain by trying to "make this into" anything.
Believe it or not, I actually hoped it could be of some help to you as another data point - as far as all the things you take into consideration when choosing how to exercise your bill of rights free speech, which has nothing to do with your corporate free-speech. The latter of which unfortunately has cost many people dearly.
With respect to Microsoft, I'm certainly not making any comment about them as a company one way or another. That wasn't the point because, this concept applies to most large similar tech companies.
Things do change rapidly at such companies. Fwiw, I have done your job, your bosses job, been the janitor, and a few other things there. Things may be different now, but i'm not making the most possible uninformed guesses just to mess with you.
I sincerely hope the truth is known and that there are no negative repercussions for you personally.
Look at my HN profile and contact me, so I can send you an email and ask you something. Or, put a way to contact you in your HN profile.
Shutting down discussion behind lawyers and bland public statements should be discouraged.
Its simply impossible to say, "no but this openness is good for the company" in an informed way. But we can certainly hope the company comes to this conclusion and encourages openness.
If you have good people in those positions in your organization, they will come together and make good decisions.
If you don't have the right people in those positions, then that's not going to be a good thing irrespective of my advice.
Transparency doesn't require anarchy and anarchy doesn't buy transparency.
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.
If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it, then two things are true: first, of course it will result in identical melodies and chord progressions, and second, of course (it seems to me) this is a derivative work and there's no way you can say its copyright is independent. On the other hand, if I learn a pop song, and then teach the fundamentals of songwriting to someone, and they write a song with a I-V-vi-IV progression with angsty lyrics about an estranged lover, no matter how much it resembles existing pop songs in intent, there's a much stronger argument for independent invention.
A "clean-room" approach to determine a specification where none exists is sound - e.g., if you're developing a driver for a piece of hardware which only has a proprietary driver, you can run the driver under instrumentation and see what it does, and then write your own driver that twiddles hardware in the same way but takes its own approach to implementation. A "clean-room" approach to determine internals feels less sound to me: if you're disassembling the code to determine structure layout and naming, aren't you really just transforming the code into an overly-detailed natural language representation, then back into code?
(To be clear, I don't know if this is what ReactOS does/did, I just think that this "clean-room" defense doesn't hold super strongly, or in other words, that if this is what ReactOS does/did, it can be true both that ReactOS believes they did a clean-room reimplementation and that it's an infringement of NT's copyrights, despite a lot of hard work by the ReactOS devs.)
> Is that really clean-room, though?
That is precisely the technique that Compaq used to reverse engineer the IBM PC BIOS. I'm sure it can be done in a legally risky way, but the fundamental technique has been quite well tested, legally speaking.
I hate bad analogies. A bad analogy just confuses the issue.
There's one and exactly one song called "Billie Jean", which was written, composed, and performed by Michael Jackson.
There are however a thousand different works relating the history of Michael Jackson's work with Quincy Jones in producing the song "Billie Jean" for the album Thriller.
So is there one and exactly one implementation of a Windows NT kernel, or is there a possibility there could be many different types of Windows NT kernel implementations?
What does "a Windows NT kernel" mean? Exposes the same interface? (Does Linux + WINE count?) Operates internally in the same way?
Maybe a better example is UNIX. Linux offers the same conceptual interface, but is neither binary-compatible with UNIX nor is implemented the same way. It is not UNIX, and does not infringe. NT, FreeBSD, and Solaris all have / had compatibility interfaces for Linux that are binary-compatible but wildly different internally. They also do not infringe. And no "clean-room" work was necessary to reach this state.
Please stop talking about music, because it just further confuses your thinking about software copyright.
> What does "a Windows NT kernel" mean?
I mean the plain understanding of "Windows NT Kernel". See wikipedia:
And yes, interoperability is permitted - that's why I'm saying it seems fine to clean-room reimplement a driver to communicate with a specific device. You do not need to have the same internal structures and the same function names to achieve interoperability, and I think making that argument that the DMCA allows you to have the same internal code layout will be hard.
That might be the case for interoperability with a hardware device, but you probably do to make an operating system that's compatible with Windows software and drivers, considering how historically brazen developers are at abusing internal details of Windows. Consider virus scanners that happily patch internal data structures like the SSDT, or other programs that detour a bunch of API functions, then expect those functions to be called in a specific order when a different API function is called, or programs that just reach into stack frames they don't control and pluck out values. (There are some other good ones in that link.) Windows takes pains to be compatible with insane programs like this, so you could argue that copying weird implementation details like this is necessary for interoperability.
Unless you’re reusing the original source code, there’s no copyright violation per se, simply functionality reimplemented in a compatible manner. The lengths that ReactOS goes to might actually be overkill, but no one can credibly claim the project has actually stolen anyone’s code.
Moreover, interoperability is not the same as distribution no? Honestly ReactOS's lengths do not seem like overkill to me, quite the contrary. Even re-implementing an API is legally suspect these days (see: Oracle vs. Google re: Android). Copying the internals of a piece of software by having one person explain verbally exactly how it works to another person who translates that to code feels a lot more like stealing than that.
That said, look at the steps involved.
Person A had the original software in binary form, runs it through a decompiler. The decompiler is not going to reproduce the code precisely, but it will be enough for documentation purposes. They document the functionality in a separate document describing what is happening when the software is run.
Person B receives this document and writes their own code according to what it says. They need not have ever even used the original software or signed a EULA, and then Person A or C or whoever can go on to test compatibility. It is a lot of effort, but the end result is code where no one involved violates any laws. It’s interoperable, and because the code is original, Person B or the Project he works for can claim copyright and license it out on their own terms, in the case of ReactOS, it is an open source license.
Re: Oracle vs Google, this case does make the whole project potentially suspect these days, but if APIs are not copyrightable, then ReactOS should be firmly on the right side of the law. If APIs are copyrightable, then we can expect the Wine project to be taken down alongside ReactOS. More reason to hope Google prevails entirely, regardless of our own personal opinions of them.
Tricking the user with a shrink-wrap license ("by opening this package you have agreed...") would not hold in court.
Asking users to click "I Agree" in installers also has dubious value due to the widespread practice of clicking these buttons to proceed without really reading the contract; their true intention was proceeding to the next question rather than entering any agreement.
In other words: if most reasonable persons wouldn't expect to be actually bound to the conditions listed in the contract, then Microsoft cannot effectively enforce them in a court.
Your claims are legally dubious at best. https://en.m.wikipedia.org/wiki/Shrink_wrap_contract
“One line of cases follows ProCD v. Zeidenberg which held such contracts enforceable (see, e.g., Bowers v. Baystate Technologies) and the other follows Klocek v. Gateway, Inc., which found the contracts at hand unenforceable (e.g., Specht v. Netscape Communications Corp.), but did not comment on shrink wrap contracts as a whole.”
If I receive a box in the mail or an exe in an email along with a request to document it to what degree am I party to any contract with the developer? I received after all nothing from them.
Dunno about that one, chief. Copying non-literal elements of code can still be infringing.
Deliberate incompatibility is a lever that allows a degree of control that allows one to extract money both from end users and from companies that serve end users.
Having the ability to reverse engineer a compatible solution is a check on the maximum amount of rent seeking one is able to do before a competitor provides a more open or at least cheaper alternative that doesn't force one to entirely rip out existing components.
This is only like stealing if you believe a company has an inherent right to make a maximum profit without interference from competitors which is an interesting moral stance to take.
Companies mostly have these rules to guard against copyright and patent lawsuits because there is no presumption of innocence beyond reasonable doubt in these in the US.
 - https://reactos.org/wiki/Audit
Update: my original comment was refering to the author's original answer, which didn't give a single symbol name. But apparently, the author registered an HN comment and start giving more details than what has been said in the original answer, I need to stick to the facts so I'd say the credibility of the accusation is no longer 100% "baseless". Let's see what is going to be the evidence.
It would be interesting to see if this statement comes back to bite you in court if the opposite accusation is ever made. That Windows kernel developers have been stealing from GPL code :)
In all seriousness is this normal? I write and work on kernel drivers for the company I work for and have always gone out of my way to not view or interact with any code that remotely relates to the work I do (out side of what I coded). Our competitor even released their version of a block device snapshot driver and while I would be tempted to see how they did things I have avoided it every step of the way.
I know the case of OpenBSD 'stealing' GPL code from broadcom linux driver, but it was done by a naive kernel developer who copy-pasted the code and the maintainer who didn't bother to check the authenticity of the code. But AFAIK no GPL driver writer has a problem with the driver being rewritten into BSD licence.
Of course one could clean room reverse engineer the GPL driver and then give the spec to someone else to implement and create a BSD driver, that would probably be ok.
If you had interviewee A write some piece of code, and then said to interviewee B "I want you to solve this problem as close as possible as the person before you did it, here is their executable", you'd be quite surprised what they could do. Especially if interviewee B is Alex Ionescu.
Others in the thread have pointed out several verifiably false fact claims in it, so it's both derogatory and at least in part factually false, not a mere matter of subjective opinion.
If only he had called it a cancer. That seems to work well generally.
Saying ReactOS infringes 200+ Microsoft patents and threatening for lawsuits to developers and all users is a more effective FUD approach to me, and may even be factually true. The entire project of Linux kernel was running under this threat for 10+ years until ~2005 (?) when an agreement was established.
If it's a commercial product or an academic research project under national grant, it may be the case.
But for free and open source project, banning U.S. developers from participating is (still) suicidal.
The project has been around for 20 years, it's not likely to cause MSFT to lose any revenue any time soon, and there is no large corporation to extract money from in a lawsuit.
It's basically the same reason they don't go after people who have a pirated version of Windows and just show them a "this is fake" warning.
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.
I started poking at some source files at random in ntoskernel, and it only took a minute to get some "hits" from the ReactOS source:
$ rg InitializeContextThread
./ntoskrnl/ke/powerpc/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
./ntoskrnl/ke/i386/thrdini.c:92:KiInitializeContextThread(IN PKTHREAD Thread,
./ntoskrnl/ke/amd64/thrdini.c:36:KiInitializeContextThread(IN PKTHREAD Thread,
./ntoskrnl/ke/arm/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
$ rg NpxFrame
./ntoskrnl/ke/i386/v86vdm.c:473: PFX_SAVE_AREA NpxFrame;
./ntoskrnl/ke/i386/v86vdm.c:480: NpxFrame = &StackFrame->NpxArea;
./ntoskrnl/ke/i386/v86vdm.c:481: ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
./ntoskrnl/ke/i386/v86vdm.c:485: RtlCopyMemory(KiGetThreadNpxArea(Thread), NpxFrame, sizeof(FX_SAVE_AREA));
./ntoskrnl/ke/i386/v86vdm.c:510: PFX_SAVE_AREA NpxFrame = &StackFrame->NpxArea;
./ntoskrnl/ke/i386/v86vdm.c:512: ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
./ntoskrnl/ke/i386/v86vdm.c:551: RtlCopyMemory(NpxFrame, V86Frame->ThreadStack, sizeof(FX_SAVE_AREA));
That said, KiInitializeContextThread isn't 'secret' enough to not appear, it is a well-known bit of internals. Here you can find some docs about it on Microsoft's own website, albeit I have no idea if this is present anywhere on there anymore.
GitHub belongs to Microsoft. They could pull that down at any time just because they feel like it. But they haven’t. That’s a pretty solid sign that there’s not any legal consequence to viewing it.
(You're also not allowed to contribute to the Wine CRT if you've ever seen the CRT source that's legally distributed with the Windows SDK.)
Still, even if Microsoft doesn't care, Wine Project and ReactOS care. My employer might care. There are unfortunately legal implications that exist, and if people want to play by the books they have to at least do the basic due diligence.
If you genuinely just don't care, you can lie to them and claim you never saw the original code, and attempt to cloak any code theft to make it indistinguishable from clean-room reverse engineering. Nothing stops you from doing that. Hell, the trouble is that it really can't be proven for sure. Even holding the positions I do on forums wouldn't prove my own innocence in such a situation, though maybe it helps build a case.
This seems like a grey area that slows the pace of R&D in countries that believe code is copyrightable & patentable (the US and select Western countries) compared to say New Zealand & China, where these aren't an issue.
And it's not about belief, but definition. Copyright and patents are human inventions defined by countries' laws (which is why different countries have different rules: different definitions). In NZ, as in many countries, "Computer software follows the rules for literary work" ( again).
The sequence of events that happens inside KeInitThread() can be obtained from reverse engineering. If you compare the code of this function in WRK  and in Reactos  code, you'll see that while they do similar things, the code is not the same.
Regarding NpxFrame, I don't know why this name is used in KiExitV86Mode, but if you compare functions KiInitializeContextThread in WRK and in Reactos, you'll see that in WRK the variable is named NpxFrame , and in Reactos a similar variable is named FxSaveArea (which matches structure FX_SAVE_AREA). The variable named NpxFrame in Reactos is used in other function, KiExitV86Mode.
Regarding the reverse engineering, ReactOS may be in a legal grey area. If they're disassembling, there might be some legal issues, bit I dont know, I'm not a lawyer and dont follow Reactor development closely (just checking progress from time to time when mentioned here or other places).
That's considered a bit of a bible for NT internals in security circles.
There is also a difference between stated policy and what actually ends up happening (not that I'm making any accusations, because I'm not). But what happens publicly isn't necessarily representative of what happens privately.
I mean, I can't contribute to it, because I have seen some source or disassembled components of Windows over the years. But excepting my public declaration of that here and now, who is to know?
Without specific proof demonstrating that there is no way one could have come to write that code from publicly available information they are just FUD.
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.
I'm not saying that their code is "clean" or is a "rip-off". Obviously, I don't have a clue about it. Maybe they were just lazy and they did not care.
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
Since you're from the team, could you provide some example explanations? Technical arguments are surely significant, rather than a purely rhetoric answer.
Brushing this off as a free "PR campaign" only works if those NT programmers simply made everything up. That's possible, because we as the general public have no way of knowing. But it's hard to ignore that there are just two possible scenarios here, nothing in between.
Could you please clarify: If MS people say they do recognize verbatim code from NT in your source, are they lying? If they're not lying, what happened?
It's quite sufficient when you consider that, unless the allegation is made in a court of law, it's in ReactOS’s interest for it to be perceived as plausible. Being perceived as either an actual (if unauthorized) fork of Windows or as something that a Microsoft insider could reasonably mistake for one is not bad for ReactOS.
And if Microsoft is going to bring the allegation in court, no matter the merits, the lawyers defending ReactOS aren't going to want lots of detailed public statements to have been made first.
> Brushing this off as a free "PR campaign" only works if those NT programmers simply made everything up
It works and, I'd argue, is the only sane strategy so long as Microsoft isn't suing them. Because, among other reasons, without such a suit it is nothing more than a free PR campaign especially if it is true.
Admittedly, it doesn't maximize imaginary internet debate points, but while that maybe be OPs interest, it doesn't seem to be ReactOS’s. (Also, probably not Microsoft’s, who I imagine so long as they aren't suing ReactOS would prefer not drawing attention to it, either.)
Do you understand that
internal data structures entirely from the NT kernel, including (why?) their names != verbatim code from NT in your source
The program code is logic first of all.
For the similarities of names and structures itself - the answer is in this already mentioned video https://www.youtube.com/watch?v=2D9ExVc0G10&t=9m53s from the 9:53 moment of time. TL:DW there are a lot of legal ways of obtaining names of variables, exported functions and structures
It's a serious allegation that deserves more than a casual brush-off and some condescending statements about publicly available debug symbols. If MS is really full of shit, as I hope they are, they should be held accountable with more than a shrug and a smile. If ReactOS does contain copied code (and yes, that does include data structures as well as instructions), well then that should have consequences as well.
They were found, for example, in debugging symbols released by MS. And sadly Axel didn't provide a single example of code that allegedly was copied.
True about the free campaign but that might backfire.
This guy literally confirms that one little open source OS could be as good as Windows $)
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)
Maybe it's a sign of the relationship between Azure and Windows teams?
Multiple people I know stopped attending LFNW that year, and will not return. Hopefully other conferences like SeaGL don't fall for the Microsoft embrace scam, as it injured LFNW pretty badly.
Windows Kernel. To me best knowledge, Windows was never ported to Commodore 64 ;-)
Like dude is talking about "there is absolutely no way on earth this was written from a clean sheet only from the available public documentation.", but that's not the bar for reverse engineering systems. It is legal (if you do it right anyways) to examine, use, and disassemble software in the process of reverse engineering.
c. Restrictions. The device manufacturer or installer and Microsoft reserve all rights (such as rights under intellectual property laws) not expressly granted in this agreement. For example, this license does not give you any right to, and you may not:
(skipping a few)
(vi) reverse engineer, decompile, or disassemble the software, or attempt to do so, except and only to the extent that the foregoing restriction is (a) permitted by applicable law; (b) permitted by licensing terms governing the use of open-source components that may be included with the software; or (c) required to debug changes to any libraries licensed under the GNU Lesser General Public License which are included with and linked to by the software; and
The EULA says you can reverse engineer to the extent that is legal in your jurisdiction.
The two things are also not exclusive: it might well be that MS “loves OSS” and that the ReactOS kernel was lifted wholesale from a Windows leak.
Besides, there are many who think projects like ReactOS or Mono are actually a net negative for the FOSS ecosystem, since they reduce the pressure on developers to switch away from Windows-based stacks.
If I look at some leaked source code, then contribute to your project, you can't know the code is stolen unless you also look at it, which you can't do.
You can reasonably guess if a large chunk looks "unusual" but it can't ever be perfect.
But I also heard they borrow some code from WINE.
I myself am ex msft so that's why I was curious. I have not contributed to any of these though.
Edit: found it.
Section on tainted developers says: "Tainted Developers". There is a legal theory that is occasionally cited in the context of producing a work-alike implementation of a published copyrighted work. ... It is the position of the Project that this theory is invalid for a number of reasons. As a general rule, there is no reason that a developer who has seen non-free code cannot write logically similar code for ReactOS. Then talks about disclosure of NDAs.
I read that as: if you worked at MS, disclose your NDA, but it doesn't automatically forbid your contribution.
It's the "internal data structures, macros" stuff that is problematic.
Not only was it doable, but people did it as a shortcut to getting a functional userland first.
It is easier on unix because they are similar to each other, but with enough persistence I believe Windows is possible too.
The steps are to get some kernel booting to a "native" userland, then add code to execute the simplest standalone Windows binary. Then when it makes a call to the kernel it will fail.
Generally tracing on Windows should give you a strong idea of what calls it makes to the kernel (I don't know, I have never developed on Windows, but probably it has something like ktrace/strace/etc.)
Once you can run a basic standalone programs, you try to add enough of a Windows userland to run bigger programs.
Once that's done, you can start to re-implement parts of the Windows userland. The symbols they export are public, you must implement all of them, and programs usually crash if you fail.
As for drivers, the Windows driver API is public, and other people have re-implemented it in the past. You can even pick up some of their work.
Do you check if your butcher has illegally bought his knife? Should you be liable, if so?
Note that pretty much any EULA I've seen in the past 10 years has had an anti reverse engineering clause.
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.
Yes, exactly. Windows likes to update. Some of us want a simple system to run Windows programs/drivers that just works and doesn't demand you upgrade constantly to the latest version with all-new features that you don't have any use for. Granted, *nix+WINE is usually better for this, but there may be times when ReactOS is the better option.
Or they pay small fraction of the price on gray market: ebay.com, scdkey.com, allkeyshop.com, etc.
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.
Speaking as someone who has followed ReactOS from the very beginning - don't hold your breath. Their pace of development is absolutely glacial and very basic things still aren't working.
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.
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.
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.
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?