Thanks for the link, o for a bunch of new followers on Quora today and was wondering why :)
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 v-alione@microsoft.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?
> Consider that the name of local variables is never part of the binaries, only public symbols are.
"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."
Also, the Windows code is under shared source license for nearly 20 years. Not really some sensitive secret thing or crown jewels that many want us to believe.
Back in NT3.x times, for quad-processors machines, and IIRC even NT 4.x with 8-processors machines (like AXEL crazy SMP monsters) Microsoft shipped windows NT as code, and you had to compile it on the machine it was to run on.
Microsoft does not release the kernel’s private symbols, trust me on that. But yes there was some leaks in the past, small portions of NT4 and W2K were leaked, I think I link to a Google query pointing to articles discussing the leaks in the Quora reply.
One small correction. On quora, you state that
there is no such thing as public documentation for the NT kernel internals.
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
I cannot edit my comment for some reason, sorry for the typos. About my colleague’s hack don’t get too excited, this is ancient history but it was at the center of a public debate at the time. Some 3rd parties had an ask, the company said it was difficult, this was very true but someone inside came up with a very clever hack that satisfied all parties, the issue was settled and everybody lived happily ever after. It’s just that the nature of the hack relied on very specific implementation details and it’s highly improbably that another implementation would need a hack to begin with, let alone the same hack. It’s one of the many coincidences that I believe will be hard to explain, shall someone really ask.
Most of the kernel code in Reactos is from far before Alex started working at Microsoft. Also the official Microsoft documentation is of course far from the only ‘Windows Internals’ documentation.
It's BSD code in both examples.
Given that the BSD license explicitly permits the sort of use in question, ripped off seems inaccurate.
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.
It seems like you're personally offended by the project. If some of the code that got presumably stolen is yours I can definitely understand.
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.
Thanks for the personal attack lol. I watched and did not learn much, except that he’s a quite decent orator. I think what he describes is the process he uses to write his books.
I hadn't heard of ReactOS but a quick glance at it's kernel source on GitHub and it's OBVIOUSLY straight from Windows.
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.
I find an opinion hard to credit when exact proof is sitting their on an open source repo everyone has access to and a closed source repo only you have access to.
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.
It appears you did not read what I wrote. The similarities are out there for anyone to see, there is plenty of leaked Windows code floating around including on GitHub, and I did not need anything else to form my opinion.
Do you think senior management at MS believes your comments are a good idea or at best benign? Or do you think all the details of your comments have just not yet fully reached VP level, legal, and PR?
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.
I’m not speaking in the name of the company: I expressed my personal opinion about ReactOS and wrote back in 2017 that I think it’s a ripoff, after looking at their code. I’m not out there to destroy ReactOS, but if you ask me today what I think about it, I’ll give you the same answer.
What is the point of comments like this besides aiming to seem smarter than the original poster? If you get your way then you would stifle open discussion and information.
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.
Is that really clean-room, though? (Note that "clean-room" is not a term in US copyright law, it's just a technique that certain people hope results in a work that is not a derivative of whatever they're reimplementing.)
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.)
>> 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.
> 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.
> If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it,
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?
Clean room re-implementations have stood up to many court challenges through the years, and are interoperability is explicitly permitted under things like the DMCA.
Reverse engineering is usually considered a violation of proprietary software IP right (not sure the exact legal term)? I know at every company I've ever worked at I've been told to never under any circumstances attempt to decompile or reverse engineer another company's proprietary software product. Maybe that's just legal CYA but decompiling+documenting then re-implementing sure sounds like stealing to me...
In the United States, clean room reverse engineering is legal for interoperability purposes. In general reverse engineering is legal unless there is a contract involved prohibiting it.
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.
You seem to have internalized ethics designed to maximize profit not happiness or utility.
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.
Reverse engineering is generally allowed. Trade secrets don't have a lot of protections. The reverse engineering + reimplementing route has precedent in the US, the Compaq vs IBM BIOS case.
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.
The author of post, Axel Rietschin at Microsoft, should remove this post and publicly apologize for his baseless defamation of ReactOS ("like a baby mosquito on the back of an giant elephant") if he cannot give authoritative evidence to back his claims. There may be copyright issues in some subroutines, but calling the entire project "a ripoff of the Windows Research Kernel" is an extraordinary, arrogant claim. If you have extraordinary evidence, fair enough, otherwise you should STFU.
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’s my personal opinion and it’s based on my lecture of ReactOS code at the time I downloaded it (circa when I wrote my reply on Quora). I think anyone who can read C code can reach similar conclusions just by eyeballing the code in ReactOS and the code from the leaked Research Kernel, that can be found for example on GitHub. As a matter fact, someone on this thread did just that and it did not take that person very long (just minutes) to find some of the similarities that I, for one, qualify as troubling. It should not be a problem for anyone to repeat the experiment, all code is available for download. So why not go ahead and see that code with your own eyes? I think it’s highly improbable that a reimplementation of that magnitude came so close from the original in so many respects. I’ve been conducting interviews for years and screened some of the best and most promising future engineers coming from the best universities and I always ask the same coding questions. I was given many decent and correct answers, but never the actual implementation was similar to the level I can observe between ReactOS and the leaked Microsoft code. In fact every candidate wrote very different answers to the very same question, some even had very different approaches to the resolution of the same problems. I cannot explain how a team of people on a hyper-complex open source project can write nearly the same code - the source code looks very similar down to peculiar formatting idiosyncrasies - as a separate team of developers of the original closed-source project, just from observing the external behavior and/or reading the documentation, if available at all. I think this is impossible.
Saying "like a baby mosquito on the back of an giant elephant" is not a defamation. It's a metaphor. He's saying that the project doesn't really threaten Microsoft so they'll probably just ignore it.
Don't we all think if the accusations were true, Microsoft would have aggressively persued legal action? Remember that guy they sued into oblivion and maybe prison over "rescue discs" for old PCs? Microsoft it notoriously sue happy. Why not here?
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.
I hate to say this: the guy who printed the "rescue disks" also decided to put the standard Windows Install Disk graphics on them. He got sued over the whole thing, but they look the same, and he didn't pay is what got him.
Because Nadella is trying hard to win the hearts of developers and attacking an open source project now like they did with Linux would backfire on them.
Interesting, but I’d really like it if they actually pointed out some examples. There may in fact be stolen source code or at least it is possible some stolen source code was referenced in ReactOS - there’s virtually no way to prove that it didn’t happen - but one human’s observation could be very flawed and represent a view extrapolated from a small subset of stolen code. How much of the code could they have possibly read?
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 was curious, and since the author of this answer provided links to what they called leaks [1], it's not difficult to download both the leak and ReactOS source [2] and look for similarities. So, out of curiosity, that's what I did.
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:
Now that said, I have no idea what I'm looking for, or if this is significant. But since we have the source for both, it seems we can do better than speculate w/r/t how much code is similar between them. I know that does not prove copying but I think the author's point can't be blindly dismissed.
I do not wish to view the leaked copies of Windows source code, unfortunately. It does have potential legal ramifications, in the United States. If someone who doesn't care can attempt to audit it, that would be absolutely great.
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.
I tried googling for KiInitializeContextThread and there are lot of search results for this name. For example, a presentation in Chinese dated 2005 year described process creating and mentions this function: [1]
The sequence of events that happens inside KeInitThread() can be obtained from reverse engineering. If you compare the code of this function in WRK [2] and in Reactos [3] 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 [4], 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.
I'm confused about those examples. Both symbols seem to be referenced in quite a few web resources that aren't dumps of that research kernel and either github search is a bit broken or I can't seem to find many of those in your [1] repository.
I have a book on my shelf somewhere about NT internal APIs; I forget the title or publisher as ive not looked at in nearly 20 years (thought it was interesting at the time, in practice I've hardly done more than glance at it). It's not officially sanctioned, and IIRC, there were notices that these were not considered public APIs and could change at any time without warning. It was from the Win2000 era, so who knows how relevant it is anymore.
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).
ReactOS only officially allows clean-room reverse engineering. Sadly I don't know the best canonical documentation for this, so here's a blog post from 2006.
Well said. I don't know if ReactOS has stolen code in it, but the Quora has some very shallow accusations. Besides, there are many ways of reverse engineering. Didn't Compaq famously have one team writing documentation for another team implementing? With the doc team scavenging info wherever they could.
Comments like these are eerily similar to what Microsoft had been saying for years about Linux - at best they had been infringing on patents but I seem to also recall accusations of the kernel containing proprietary Windows source code. This is just one individuals opinion but I would be really interested in seeing them provide more specifics - especially given the amount of MS source that has leaked/been open sourced over the years.
I don't recall accusations of Linux using Windows code, but these accusations (especially the "one has only to eyeball the code to see it was stolen") are reminiscent of the SCO troll-case, which was (indirectly but very likely intentionally) financially backed by Microsoft.
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.
Exactly. The author doesn't give any references, just says "Trust me, it is the same code". Maybe the author doesn't know that there are many resources with reverse-engineered descriptions of undocumented kernel structures and functions, for example [1] [2]
It looks like ms has some sort of inside sect training on that matter. It is so easy to hear blames from ms staff on minor legal troubles that it just feels to be true. For one, I once read the thread on local ms support site that yelled at and almost banned a user for a story of upgrading to w10 and then downgrading back to 7. The problem was that his LICENSE was converted into 10-th one and now he LOST RIGHT to use 7. While maybe formally legal, for me this behavior is completely out of sane bounds.
Fascinating thread. You don't often see this kind of thing discussed openly.
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.
When you've read and understood some piece of code, you're more prone to replicate it, even without realizing it. And ReactOS developers have obviously some extensive experience with Windows API, and it should be not suprise that any attempt to rewrite Windows will fall into the same trap.
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.
Someone should get Alex Ionescu's take. He both used to be _the_ kernel guy of ReactOS, and he some wrote chapters in Windows Internals, some of Microsoft's deepest official public documentation.
Yeah, it seems like the guy answering here has no idea what he's talking about. Alex has a blog where he basically says that he'd spend the days writing Windows Internals and the nights reverse engineering the kernel.
> Many internal data structures and internal functions, not exported anywhere and not part of the public symbols
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.
"Many internal structures" that Axel believes are private and available only for MS employees, are actually published in the Internet, for example [1] [2]
OP wrote "If any of the presumed authors wants to chime in and explain the similitudes, I’m happy to change my mind".
Since you're from the team, could you provide some example explanations? Technical arguments are surely significant, rather than a purely rhetoric answer.
This is an utterly insufficient answer to the allegation that you copied internal data structures entirely from the NT kernel, including (why?) their names.
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?
> This is an utterly insufficient answer to the allegation that you copied internal data structures entirely from the NT kernel
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
You didn't spell started correctly both on here and on quora aka thanks for the low effort canned response. Maybe try addressing their points directly. This is bad PR for you.
Not only is ReactOS getting a lot of coverage it otherwise would not have, but the core claim seems to be that ReactOS is actually such a good re-implementation of Windows that actual Windows engineers think it couldn't have been accomplished without using the Windows source code.
It's hard to know what specifically he means to have been copied. But it would not surprise me if a lot of "impossibly" identical structure member names have been published as ntoskrnl.pdb (kernel debug symbols).
I have also seen some pretty good reverse engineering of nt native APIs out there.
The MS guy says there was no public NT internals doc. However many people refer to VAX/VMS Internals and Data Structures as being very similar. Both were architected by DNC.
>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 ;-)
It would be interesting to see this engineer's statements tested in court. Microsoft are highly motivated to protect their source code so there would have to be a reason why they haven't. ReactOS is definitely NOT a mosquito to an elephant in violation terms if this engineers comments have validity. I'm thinking patents, copyrights etc.
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)
I find the attitude more interesting.. on one side we have Linux embedded in Windows, more Linux VMs on Azure than Windows Server, MS employees proudly brandishing shirts with 'I heart Linux' and 'I heart OSS' and on the other side we have Windows Kernal developers saying their ideas were stolen.
Maybe it's a sign of the relationship between Azure and Windows teams?
I interned at Microsoft in late 2000's. The sales engineers had an "anti oss" budget. Many of these guys still work at Microsoft today, now "hearts" open source and linux...
The comment is from one dude in late 2017 - it probably doesn't mean shit.
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.
Big companies are hardly ever coherent, let alone after a big pivot like Nadella’s.
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.
How are these two things related at all? I use Linux too but would be highly annoyed if someone stole my car. Are you implying that Linux users are in some way "stealing" from the Linux authors?
I always heard that ReactOS had an ultra-strict vetting process, where no one who had ever so much as been within spitting distance of Redmond at some point in their life was allowed to touch the code, to support their claim of a clean-room implementation in case Microsoft ever decided to make a fuss about it. Seems like a lot of pointless effort if they actually did use leaks or university kernel releases. So either this guy is mistaken, my info about ReactOS is bad, or the project is run by people very ignorant of the law.
Why not consider the alternative that the process is just inherently flawed? (As in, it has flaws, even if its intent is good)
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.
For MS's WSL, according to their devs, they only allowed themselves to read the documentation (external API). They didn't allow themselves to look at the code. Different case but also a form of reverse engineering.
It's the "internal data structures, macros" stuff that is problematic.
Honestly I always thought that that was an open secret of ReactOS. How else are you gonna achieve binary compatibility with a closed source OS. Of course there's symbols but those only get you so far.
In the past when porting netbsd to new architectures the approach was to first run a kernel with a binary compatibility layer to the existing operating system, be it something like OSF/1 or SunOS.
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.
The information about many internal "undocumented" structures is actually documented on third-party sites. And if there are structures that are really not documented anywhere then you don't have to reimplement them because no developer is using them and they are not necessary for compatibility.
What goes around, comes around. Stealing code is on Microsoft records, as a simple "Microsoft admits stealing code" search shows. One can only wonder how much code the company stole that did not come to public knowledge.
Also many of the .wav files in Windows 98SE were edited with a pirated version of Sony's Soundforge, the metadata in the media files contained the Soundforge cracker's name.
I have always been confused as to what level of reverse engineering is legally acceptable in this case. Is having a sneak peak at one of the win32 dlls with IDA or Radare allowed? Or, are you expected to re-invent the wheel based on documentation and observed behaviour? In the case of the former, how can it be conclusively legally proven that it was not reverse engineered (from machine code)?
In that case, considering that even the undocumented methods are exported from the respective DLLs, these can easily be identified and their workings can be figured out by perusing the machine code. Access to source code, stolen or otherwise, is not really required. Also, as compatibility is ReactOS' goal, even identical bugs can't be credible evidence.
Reversing is one thing, distributing copies of reverse engineered IP is another. I am pretty sure that is not a good idea unless the terms under which you obtained the product explicitly allow it.
I appreciate the insider perspective (though I am definitely not qualified to assess these claims.) Unfortunately, it might be hard to prove these claims either way since it sounds like they have plenty of plausible deniability to fall back on.
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.
Axel is a windows kernel developer, he has his pick of the job market. Microsoft alone is probably happy to cover him in dobloons just to stick around.
Why would any paying customer use ReactOS over windows? There is no support (security patches automatically supplied ETC). Windows 10 is evergreen and new feature appear quite often. Microsoft loses exactly zero dollars a year because of ReactOS. People who don't want to pay for windows just pirate it. Those who do pay, get it buldled with a computer or laptop that they purchase, or are corporations who need support. ReactOS will always be a tinkerers hobby... Did they steal code? Did they reverse engineer so good that it looks like they stole code? Who cares really... Not Microsoft. Why would they?
> Why would any paying customer use ReactOS over windows? [...] Windows 10 is evergreen and new feature appear quite often.
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.
While I haven't given it a test drive yet, I'm quite excited about ReactOS. I grew up on Windows, but have been in a state of disappointment for the last decade while I watched Microsoft slowly mutilate or let rot so many of the things I like about it.
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 hope by the time I have to give up Windows 7, ReactOS will have a viable alternative
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 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.
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.
> 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?
When I discovered ReactOS, I was passionate about it, I always downloaded the latest version available in order to test it in VirtualBox. But then, I noticed that the project was evolving so slowly, that it could never catch up his delay from Windows.
Microsoft has made great strides in opening up some of their code lately and the focus seems to be more and more on Online services. I hope one day, sooner or later, they go all in and open source Windows. That would be a great day.
I have been following the ReactOS debate long before Microsoft's Axel Rietschin wrote in Quora that ReactOS is "a ripoff of the Windows Research Kernel…"
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.
The evidence of the Microsoft employee boils down to "our secret code that only we can see totally shows react OS ripped us off. We cant show you it but believe us guys".
This thing is odd, because most companies I've worked for have pretty strong bans on making statements like this outside of official channels.
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).
I know this is only tangentially related, but could you verify the famous HN post by an anonymous Windows kernel developer explaining why Windows is so much slower than Linux
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 :)
Interesting read, but I think the author is somewhat jaded.
> We fill headcount with nine-to-five-with-kids types,
What is wrong with having a life outside of work? Or children and responsibilities? Does anyone believe these make for worse engineers? It's not even legal for companies to force parents out of their workforce.
> P.S. I have no problem with family people, and want to retract the offhand comment I made about them. I work with many awesome colleagues who happen to have children at home. What I really meant to say is that I don't like people who see what we do as more of a job than a passion, and it feels like we have a lot of these people these days. Maybe everyone does, though, or maybe I'm just completely wrong.
It's probably somewhat preferable to the company that the employee sees their job as their entire purpose in life, but realistically most people beyond their 20s do not stay in that state of mind and an experienced 40 year old "9-5 with kids" probably brings some benefits to the team that the "fully committed" 28 year old with no extracurricular interests does not.
At the risk of not adding anything substantive to the discussion, I would just say if I was an engineer working on Windows, I would dial down the arrogance a little bit.
> like a baby mosquito on the back of an giant elephant.
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.
The researcher is unable to name any data structure in the source file. If -- as he claims -- it's littered with them, this should be easy to prove.
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.
Just a tip - if you want to make statements and have people take you seriously, stick to facts and don't add stupid things like:
> Literally no one wants to read Microsoft code anyway; knowing them, it's probably horrendous.
This added NOTHING to your previous statement, and only served to make me think your acting as a troll and actually worked against everything else you had previously said.
Thanks for the link, o for a bunch of new followers on Quora today and was wondering why :)
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 v-alione@microsoft.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?
> Consider that the name of local variables is never part of the binaries, only public symbols are.
"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:
https://en.wikipedia.org/wiki/NSAKEY
"_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."
Also, the Windows code is under shared source license for nearly 20 years. Not really some sensitive secret thing or crown jewels that many want us to believe.
1 reply →
Back in NT3.x times, for quad-processors machines, and IIRC even NT 4.x with 8-processors machines (like AXEL crazy SMP monsters) Microsoft shipped windows NT as code, and you had to compile it on the machine it was to run on.
Microsoft does not release the kernel’s private symbols, trust me on that. But yes there was some leaks in the past, small portions of NT4 and W2K were leaked, I think I link to a Google query pointing to articles discussing the leaks in the Quora reply.
17 replies →
One small correction. On quora, you state that there is no such thing as public documentation for the NT kernel internals.
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
And one of the authors of said book is also quite a prominent member of the ReactOS team.
6 replies →
I cannot edit my comment for some reason, sorry for the typos. About my colleague’s hack don’t get too excited, this is ancient history but it was at the center of a public debate at the time. Some 3rd parties had an ask, the company said it was difficult, this was very true but someone inside came up with a very clever hack that satisfied all parties, the issue was settled and everybody lived happily ever after. It’s just that the nature of the hack relied on very specific implementation details and it’s highly improbably that another implementation would need a hack to begin with, let alone the same hack. It’s one of the many coincidences that I believe will be hard to explain, shall someone really ask.
Most of the kernel code in Reactos is from far before Alex started working at Microsoft. Also the official Microsoft documentation is of course far from the only ‘Windows Internals’ documentation.
Microsoft has leaked tons of private variable names publicly though. See the whole _NSAKEY thing for one example.
https://en.wikipedia.org/wiki/NSAKEY
Microsoft complaining about ripped off source code?
You are the blackest pot in the history of computer software.
https://www.geek.com/news/microsoft-uses-open-source-code-54...
https://lwn.net/Articles/245805/
It's BSD code in both examples. Given that the BSD license explicitly permits the sort of use in question, ripped off seems inaccurate.
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.
It seems like you're personally offended by the project. If some of the code that got presumably stolen is yours I can definitely understand.
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.
This is news?
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.
Anyone spending time giving detailed explanations regarding manual transmissions and engines in general deserves a follow :)
When MS finishes trashing Windows all of the legacy users will only have ReactOS and WINE to fall back on.
Frankly, they're doing a great service to the world, and maybe you should help instead of taking potshots.
The more you write in these threads the more you sound like a fool. https://youtu.be/2D9ExVc0G10 Start around the 9 minute mark.
Thanks for the personal attack lol. I watched and did not learn much, except that he’s a quite decent orator. I think what he describes is the process he uses to write his books.
1 reply →
Uh-oh. Someone didn't check with MS LCA before posting this. Bad move.
I expressed my personal opinion, here and on Quora. I think I’ll be fine.
Can you please explain what is MS LCA?
4 replies →
He needs to defend himself in internet court, employment be damned. /s
Why wouldn't you reply to ReactOS devs here pointing that what you are saying is clearly wrong?
What would he say other than what he has already said? The ReactOS devs are not addressing the substantive points. No point in him repeating himself.
2 replies →
I hadn't heard of ReactOS but a quick glance at it's kernel source on GitHub and it's OBVIOUSLY straight from Windows.
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.
I kind of doubt this is the case, because more than 10 years ago they had accusations of this sort and undertook an extensive audit and cleanroom rewrite: https://www.reactos.org/reset-reboot-restart-legal-issues-an...
I find an opinion hard to credit when exact proof is sitting their on an open source repo everyone has access to and a closed source repo only you have access to.
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.
It appears you did not read what I wrote. The similarities are out there for anyone to see, there is plenty of leaked Windows code floating around including on GitHub, and I did not need anything else to form my opinion.
1 reply →
Do you think senior management at MS believes your comments are a good idea or at best benign? Or do you think all the details of your comments have just not yet fully reached VP level, legal, and PR?
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.
Why are you policing other company's employees and presuming to know what their job is?
5 replies →
I’m not speaking in the name of the company: I expressed my personal opinion about ReactOS and wrote back in 2017 that I think it’s a ripoff, after looking at their code. I’m not out there to destroy ReactOS, but if you ask me today what I think about it, I’ll give you the same answer.
1 reply →
What is the point of comments like this besides aiming to seem smarter than the original poster? If you get your way then you would stifle open discussion and information.
I like this honesty and transparency, employers such as Microsoft encouraging it's employees to act in this way is a good thing.
Shutting down discussion behind lawyers and bland public statements should be discouraged.
2 replies →
There are other jobs, would you really want to work some where that makes you afraid to have an opinion?
In 2006 ReactOS halted all developments because of accusations like this. After a year long effort there was found to be no use of Microsoft source code in ReactOS. (https://www.reactos.org/reset-reboot-restart-legal-issues-an...)
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.
Is that really clean-room, though? (Note that "clean-room" is not a term in US copyright law, it's just a technique that certain people hope results in a work that is not a derivative of whatever they're reimplementing.)
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.)
>> 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.
> 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.
1 reply →
> If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it,
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?
2 replies →
Clean room re-implementations have stood up to many court challenges through the years, and are interoperability is explicitly permitted under things like the DMCA.
3 replies →
Reverse engineering is usually considered a violation of proprietary software IP right (not sure the exact legal term)? I know at every company I've ever worked at I've been told to never under any circumstances attempt to decompile or reverse engineer another company's proprietary software product. Maybe that's just legal CYA but decompiling+documenting then re-implementing sure sounds like stealing to me...
In the United States, clean room reverse engineering is legal for interoperability purposes. In general reverse engineering is legal unless there is a contract involved prohibiting it.
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.
7 replies →
You seem to have internalized ethics designed to maximize profit not happiness or utility.
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.
Reverse engineering is generally allowed. Trade secrets don't have a lot of protections. The reverse engineering + reimplementing route has precedent in the US, the Compaq vs IBM BIOS case.
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.
ReactOS underwent a big audit years ago because people kept saying things like this, and AFAIK it's over and nothing exciting turned up.
[1] - https://reactos.org/wiki/Audit
The author of post, Axel Rietschin at Microsoft, should remove this post and publicly apologize for his baseless defamation of ReactOS ("like a baby mosquito on the back of an giant elephant") if he cannot give authoritative evidence to back his claims. There may be copyright issues in some subroutines, but calling the entire project "a ripoff of the Windows Research Kernel" is an extraordinary, arrogant claim. If you have extraordinary evidence, fair enough, otherwise you should STFU.
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’s my personal opinion and it’s based on my lecture of ReactOS code at the time I downloaded it (circa when I wrote my reply on Quora). I think anyone who can read C code can reach similar conclusions just by eyeballing the code in ReactOS and the code from the leaked Research Kernel, that can be found for example on GitHub. As a matter fact, someone on this thread did just that and it did not take that person very long (just minutes) to find some of the similarities that I, for one, qualify as troubling. It should not be a problem for anyone to repeat the experiment, all code is available for download. So why not go ahead and see that code with your own eyes? I think it’s highly improbable that a reimplementation of that magnitude came so close from the original in so many respects. I’ve been conducting interviews for years and screened some of the best and most promising future engineers coming from the best universities and I always ask the same coding questions. I was given many decent and correct answers, but never the actual implementation was similar to the level I can observe between ReactOS and the leaked Microsoft code. In fact every candidate wrote very different answers to the very same question, some even had very different approaches to the resolution of the same problems. I cannot explain how a team of people on a hyper-complex open source project can write nearly the same code - the source code looks very similar down to peculiar formatting idiosyncrasies - as a separate team of developers of the original closed-source project, just from observing the external behavior and/or reading the documentation, if available at all. I think this is impossible.
14 replies →
Saying "like a baby mosquito on the back of an giant elephant" is not a defamation. It's a metaphor. He's saying that the project doesn't really threaten Microsoft so they'll probably just ignore it.
>baseless defamation of ReactOS ("like a baby mosquito on the back of an giant elephant")
If only he had called it a cancer. That seems to work well generally.
5 replies →
Don't we all think if the accusations were true, Microsoft would have aggressively persued legal action? Remember that guy they sued into oblivion and maybe prison over "rescue discs" for old PCs? Microsoft it notoriously sue happy. Why not here?
Because reactos is irrelevant to Microsoft?
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.
1 reply →
I hate to say this: the guy who printed the "rescue disks" also decided to put the standard Windows Install Disk graphics on them. He got sued over the whole thing, but they look the same, and he didn't pay is what got him.
Because Nadella is trying hard to win the hearts of developers and attacking an open source project now like they did with Linux would backfire on them.
Because what Microsoft did instead was offer Alex Ionescu a job.
Interesting, but I’d really like it if they actually pointed out some examples. There may in fact be stolen source code or at least it is possible some stolen source code was referenced in ReactOS - there’s virtually no way to prove that it didn’t happen - but one human’s observation could be very flawed and represent a view extrapolated from a small subset of stolen code. How much of the code could they have possibly read?
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 was curious, and since the author of this answer provided links to what they called leaks [1], it's not difficult to download both the leak and ReactOS source [2] and look for similarities. So, out of curiosity, that's what I did.
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:
Now that said, I have no idea what I'm looking for, or if this is significant. But since we have the source for both, it seems we can do better than speculate w/r/t how much code is similar between them. I know that does not prove copying but I think the author's point can't be blindly dismissed.
[1] https://github.com/Zer0Mem0ry/ntoskrnl
[2] https://sourceforge.net/projects/reactos/files/ReactOS/
I do not wish to view the leaked copies of Windows source code, unfortunately. It does have potential legal ramifications, in the United States. If someone who doesn't care can attempt to audit it, that would be absolutely great.
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.
https://web.archive.org/web/20151214014944/http://www.micros...
9 replies →
I tried googling for KiInitializeContextThread and there are lot of search results for this name. For example, a presentation in Chinese dated 2005 year described process creating and mentions this function: [1]
The sequence of events that happens inside KeInitThread() can be obtained from reverse engineering. If you compare the code of this function in WRK [2] and in Reactos [3] 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 [4], 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.
[1] https://slideplayer.com/slide/6561298/
[2] https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/thredo...
[3] https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/t...
[4] https://github.com/Zer0Mem0ry/ntoskrnl/blob/a1eded2d8efb0716...
[5] https://github.com/reactos/reactos/blob/893a3c9d030fd8b078cb...
I'm confused about those examples. Both symbols seem to be referenced in quite a few web resources that aren't dumps of that research kernel and either github search is a bit broken or I can't seem to find many of those in your [1] repository.
I have a book on my shelf somewhere about NT internal APIs; I forget the title or publisher as ive not looked at in nearly 20 years (thought it was interesting at the time, in practice I've hardly done more than glance at it). It's not officially sanctioned, and IIRC, there were notices that these were not considered public APIs and could change at any time without warning. It was from the Win2000 era, so who knows how relevant it is anymore.
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).
Was it "Windows NT/2000 Native API Reference" by Gary Nebbett? (https://amzn.to/2XHhSFF)
That's considered a bit of a bible for NT internals in security circles.
ReactOS only officially allows clean-room reverse engineering. Sadly I don't know the best canonical documentation for this, so here's a blog post from 2006.
https://www.reactos.org/reset-reboot-restart-legal-issues-an...
2 replies →
Well said. I don't know if ReactOS has stolen code in it, but the Quora has some very shallow accusations. Besides, there are many ways of reverse engineering. Didn't Compaq famously have one team writing documentation for another team implementing? With the doc team scavenging info wherever they could.
Is Stardock still a thing?
Comments like these are eerily similar to what Microsoft had been saying for years about Linux - at best they had been infringing on patents but I seem to also recall accusations of the kernel containing proprietary Windows source code. This is just one individuals opinion but I would be really interested in seeing them provide more specifics - especially given the amount of MS source that has leaked/been open sourced over the years.
I don't recall accusations of Linux using Windows code, but these accusations (especially the "one has only to eyeball the code to see it was stolen") are reminiscent of the SCO troll-case, which was (indirectly but very likely intentionally) financially backed by Microsoft.
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.
Upvoted. The history of Microsoft is well-documented, including the accusation of "stealing" code. Not sure why your comment has been downvoted.
Exactly. The author doesn't give any references, just says "Trust me, it is the same code". Maybe the author doesn't know that there are many resources with reverse-engineered descriptions of undocumented kernel structures and functions, for example [1] [2]
[1] https://www.nirsoft.net/kernel_struct/vista/index.html
[2] http://msdn.mirt.net/
It looks like ms has some sort of inside sect training on that matter. It is so easy to hear blames from ms staff on minor legal troubles that it just feels to be true. For one, I once read the thread on local ms support site that yelled at and almost banned a user for a story of upgrading to w10 and then downgrading back to 7. The problem was that his LICENSE was converted into 10-th one and now he LOST RIGHT to use 7. While maybe formally legal, for me this behavior is completely out of sane bounds.
Fascinating thread. You don't often see this kind of thing discussed openly.
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.
When you've read and understood some piece of code, you're more prone to replicate it, even without realizing it. And ReactOS developers have obviously some extensive experience with Windows API, and it should be not suprise that any attempt to rewrite Windows will fall into the same trap.
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.
The basics are available in the windows driver development kit.
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.
Someone should get Alex Ionescu's take. He both used to be _the_ kernel guy of ReactOS, and he some wrote chapters in Windows Internals, some of Microsoft's deepest official public documentation.
Yeah, it seems like the guy answering here has no idea what he's talking about. Alex has a blog where he basically says that he'd spend the days writing Windows Internals and the nights reverse engineering the kernel.
So... doesn't that confirm what he's saying? How could you possibly "clean room reverse engineer" while you certainly are not in a clean room?
8 replies →
> Many internal data structures and internal functions, not exported anywhere and not part of the public symbols
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.
"Many internal structures" that Axel believes are private and available only for MS employees, are actually published in the Internet, for example [1] [2]
[1] https://www.nirsoft.net/kernel_struct/vista/index.html
[2] http://msdn.mirt.net/
> On the internet, the burden of proof is on the accused.
True, unfortunately.
Maybe, you are looking for this:
https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41...
Hello from ReactOS team!
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
OP wrote "If any of the presumed authors wants to chime in and explain the similitudes, I’m happy to change my mind".
Since you're from the team, could you provide some example explanations? Technical arguments are surely significant, rather than a purely rhetoric answer.
I don't think they need to. The OP blames ReactOS, the burden of proof is on him, if he thinks it's an issue. Otherwise it's called trolling.
Axel didn't provide any examples of allegedly copied code, so what can they explain?
This is an utterly insufficient answer to the allegation that you copied internal data structures entirely from the NT kernel, including (why?) their names.
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?
> This is an utterly insufficient answer to the allegation that you copied internal data structures entirely from the NT kernel
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.)
1 reply →
Well, now please re-read your statement
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
2 replies →
Many "undocumented" Windows kernel structures are actually documented on third-party sites, for example [1] and [2]
[1] https://www.nirsoft.net/kernel_struct/vista/index.html
[2] http://msdn.mirt.net/
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.
Heh, thats a very guilty looking answer.
True about the free campaign but that might backfire.
You didn't spell started correctly both on here and on quora aka thanks for the low effort canned response. Maybe try addressing their points directly. This is bad PR for you.
You mean the accusations for which the accuser refuses to provide any proof?
What "points"? Axel didn't provide a single example of what could be allegedly copied code.
Why would you call it a PR campaign if it wasn't favoring you? Just curious.
Not only is ReactOS getting a lot of coverage it otherwise would not have, but the core claim seems to be that ReactOS is actually such a good re-implementation of Windows that actual Windows engineers think it couldn't have been accomplished without using the Windows source code.
Probably because it makes far more people aware that ReactOS even exists.
because a lot of people probably just learned about ReactOS as a result of this controversy. "There's no such thing as bad press." -someone
1 reply →
You never heard of "all publicity is good publicity"?
Even very dirty river water would still spin your mill, as long as the mill itself is good.
This guy literally confirms that one little open source OS could be as good as Windows $)
It's hard to know what specifically he means to have been copied. But it would not surprise me if a lot of "impossibly" identical structure member names have been published as ntoskrnl.pdb (kernel debug symbols).
I have also seen some pretty good reverse engineering of nt native APIs out there.
Alex Ionescu - Reversing Without Reversing https://www.youtube.com/watch?v=2D9ExVc0G10
The MS guy says there was no public NT internals doc. However many people refer to VAX/VMS Internals and Data Structures as being very similar. Both were architected by DNC.
Its bullshit too, there is not much public by MS but there is plenty of third party work done on documenting it.
>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 ;-)
Can you taste the power-trip?
It would be interesting to see this engineer's statements tested in court. Microsoft are highly motivated to protect their source code so there would have to be a reason why they haven't. ReactOS is definitely NOT a mosquito to an elephant in violation terms if this engineers comments have validity. I'm thinking patents, copyrights etc.
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)
I find the attitude more interesting.. on one side we have Linux embedded in Windows, more Linux VMs on Azure than Windows Server, MS employees proudly brandishing shirts with 'I heart Linux' and 'I heart OSS' and on the other side we have Windows Kernal developers saying their ideas were stolen.
Maybe it's a sign of the relationship between Azure and Windows teams?
I interned at Microsoft in late 2000's. The sales engineers had an "anti oss" budget. Many of these guys still work at Microsoft today, now "hearts" open source and linux...
3 replies →
> Windows Kernal developers
Windows Kernel. To me best knowledge, Windows was never ported to Commodore 64 ;-)
* https://en.wikipedia.org/wiki/KERNAL
The comment is from one dude in late 2017 - it probably doesn't mean shit.
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.
5 replies →
Big companies are hardly ever coherent, let alone after a big pivot like Nadella’s.
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.
How are these two things related at all? I use Linux too but would be highly annoyed if someone stole my car. Are you implying that Linux users are in some way "stealing" from the Linux authors?
I always heard that ReactOS had an ultra-strict vetting process, where no one who had ever so much as been within spitting distance of Redmond at some point in their life was allowed to touch the code, to support their claim of a clean-room implementation in case Microsoft ever decided to make a fuss about it. Seems like a lot of pointless effort if they actually did use leaks or university kernel releases. So either this guy is mistaken, my info about ReactOS is bad, or the project is run by people very ignorant of the law.
Why not consider the alternative that the process is just inherently flawed? (As in, it has flaws, even if its intent is good)
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.
I heard WINE has a rule like that but ReactOS does not.
But I also heard they borrow some code from WINE.
ReactOS had the same process.
1 reply →
For MS's WSL, according to their devs, they only allowed themselves to read the documentation (external API). They didn't allow themselves to look at the code. Different case but also a form of reverse engineering.
It's the "internal data structures, macros" stuff that is problematic.
They looked at syscall surface primarily.
Honestly I always thought that that was an open secret of ReactOS. How else are you gonna achieve binary compatibility with a closed source OS. Of course there's symbols but those only get you so far.
In the past when porting netbsd to new architectures the approach was to first run a kernel with a binary compatibility layer to the existing operating system, be it something like OSF/1 or SunOS.
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.
The information about many internal "undocumented" structures is actually documented on third-party sites. And if there are structures that are really not documented anywhere then you don't have to reimplement them because no developer is using them and they are not necessary for compatibility.
So you're using their "leaked" or reverse engineered information? That's just IP theft with extra steps.
1 reply →
What goes around, comes around. Stealing code is on Microsoft records, as a simple "Microsoft admits stealing code" search shows. One can only wonder how much code the company stole that did not come to public knowledge.
https://www.computerworld.com/article/2522017/microsoft-admi...
Also many of the .wav files in Windows 98SE were edited with a pirated version of Sony's Soundforge, the metadata in the media files contained the Soundforge cracker's name.
As far as I could research, I only found articles about Windows XP. Close enough. https://www.tomshardware.co.uk/pirated-software-used-to-crea...
These .wav files might be made by person who works under Microsoft contract, not necessarily directly employed by Microsoft.
7 replies →
I have always been confused as to what level of reverse engineering is legally acceptable in this case. Is having a sneak peak at one of the win32 dlls with IDA or Radare allowed? Or, are you expected to re-invent the wheel based on documentation and observed behaviour? In the case of the former, how can it be conclusively legally proven that it was not reverse engineered (from machine code)?
In the U.S. it is perfectly legal to reverse anything that you obtained legally.
Not if you agree to an EULA that explicitly prohibits it. See https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand...
And https://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologie....
Note that pretty much any EULA I've seen in the past 10 years has had an anti reverse engineering clause.
In that case, considering that even the undocumented methods are exported from the respective DLLs, these can easily be identified and their workings can be figured out by perusing the machine code. Access to source code, stolen or otherwise, is not really required. Also, as compatibility is ReactOS' goal, even identical bugs can't be credible evidence.
Reversing is one thing, distributing copies of reverse engineered IP is another. I am pretty sure that is not a good idea unless the terms under which you obtained the product explicitly allow it.
I appreciate the insider perspective (though I am definitely not qualified to assess these claims.) Unfortunately, it might be hard to prove these claims either way since it sounds like they have plenty of plausible deniability to fall back on.
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.
Axel is a windows kernel developer, he has his pick of the job market. Microsoft alone is probably happy to cover him in dobloons just to stick around.
A rant that reads very much in the style of Open Letter to Hobbyists[1]. Typical MS.
[1]. https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists
Why would any paying customer use ReactOS over windows? There is no support (security patches automatically supplied ETC). Windows 10 is evergreen and new feature appear quite often. Microsoft loses exactly zero dollars a year because of ReactOS. People who don't want to pay for windows just pirate it. Those who do pay, get it buldled with a computer or laptop that they purchase, or are corporations who need support. ReactOS will always be a tinkerers hobby... Did they steal code? Did they reverse engineer so good that it looks like they stole code? Who cares really... Not Microsoft. Why would they?
> Why would any paying customer use ReactOS over windows? [...] Windows 10 is evergreen and new feature appear quite often.
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.
> People who don't want to pay for windows just pirate it
Or they pay small fraction of the price on gray market: ebay.com, scdkey.com, allkeyshop.com, etc.
While I haven't given it a test drive yet, I'm quite excited about ReactOS. I grew up on Windows, but have been in a state of disappointment for the last decade while I watched Microsoft slowly mutilate or let rot so many of the things I like about it.
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 hope by the time I have to give up Windows 7, ReactOS will have a viable alternative
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.
Why reverse engineer? The Windows code has been available via shared source license since nearly 20 years....
That license does not allow to repackage the system, rebrand it, or resell it, afaik.
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?
When I discovered ReactOS, I was passionate about it, I always downloaded the latest version available in order to test it in VirtualBox. But then, I noticed that the project was evolving so slowly, that it could never catch up his delay from Windows.
Microsoft has made great strides in opening up some of their code lately and the focus seems to be more and more on Online services. I hope one day, sooner or later, they go all in and open source Windows. That would be a great day.
Alex Ionescu on this subject: https://www.youtube.com/watch?v=ceQ6kT1ZMrk
Aren't there tools that are used to catch code plagiarism? I am curious what results you would get if you used them on both ReactOS and the NT kernel.
I have been following the ReactOS debate long before Microsoft's Axel Rietschin wrote in Quora that ReactOS is "a ripoff of the Windows Research Kernel…"
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.)
> baby mosquito on giant elephant...
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.
The evidence of the Microsoft employee boils down to "our secret code that only we can see totally shows react OS ripped us off. We cant show you it but believe us guys".
I wasn't born yesterday
To be fair he did say you could compare with the leaked versions.
Took me a few reads to parse that title. How about something like “A Kernel Engineer from Microsoft Answers: “What Do You Think About ReactOS?””
You are right, sorry I am not good in English.
This thing is odd, because most companies I've worked for have pretty strong bans on making statements like this outside of official channels.
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).
I know this is only tangentially related, but could you verify the famous HN post by an anonymous Windows kernel developer explaining why Windows is so much slower than Linux
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 :)
We detached this subthread from https://news.ycombinator.com/item?id=20341933.
Interesting read, but I think the author is somewhat jaded.
> We fill headcount with nine-to-five-with-kids types,
What is wrong with having a life outside of work? Or children and responsibilities? Does anyone believe these make for worse engineers? It's not even legal for companies to force parents out of their workforce.
He later clarified:
> P.S. I have no problem with family people, and want to retract the offhand comment I made about them. I work with many awesome colleagues who happen to have children at home. What I really meant to say is that I don't like people who see what we do as more of a job than a passion, and it feels like we have a lot of these people these days. Maybe everyone does, though, or maybe I'm just completely wrong.
It's probably somewhat preferable to the company that the employee sees their job as their entire purpose in life, but realistically most people beyond their 20s do not stay in that state of mind and an experienced 40 year old "9-5 with kids" probably brings some benefits to the team that the "fully committed" 28 year old with no extracurricular interests does not.
At the risk of not adding anything substantive to the discussion, I would just say if I was an engineer working on Windows, I would dial down the arrogance a little bit.
pathetic comment.
What a fscking bootlicker.
How extraordinarily fair and thoughtful of you...
Nasty article
Could you please stop posting unsubstantive comments to Hacker News?
I tried ReactOS recently. Got a BSOD trying to eject a CD. Lost interest.
Well at least they implemented Microsoft's best known feature (The BSOD).
It's still in alpha version. Could also be an compatibility issue with your hardware.
> like a baby mosquito on the back of an giant elephant.
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.
The researcher is unable to name any data structure in the source file. If -- as he claims -- it's littered with them, this should be easy to prove.
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.
Just a tip - if you want to make statements and have people take you seriously, stick to facts and don't add stupid things like:
> Literally no one wants to read Microsoft code anyway; knowing them, it's probably horrendous.
This added NOTHING to your previous statement, and only served to make me think your acting as a troll and actually worked against everything else you had previously said.
I wish everyone would read their Facebook stream with your eyes...
[dead]
> don't add stupid things like
Don't use the word "stupid" when another, less self-righteous word suffices.
1 reply →