
A Kernel Engineer at Microsoft's Answer to “What Do You Think about ReactOS?” - whereistimbo
https://www.quora.com/What-do-you-think-about-ReactOS/answer/Axel-Rietschin?share=1
======
axelriet
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?

~~~
WhitneyLand
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.

~~~
forcemajeure
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.

~~~
Waterluvian
We like it. But it can be actively harmful to the interests of the company.
And its impossible for us to have the facts required to know if this is
harmful. That's up to the company. So if they decide to fire employees who are
spending their free time harming the company, we can't really get upset about
that.

Its simply impossible to say, "no but this openness is good for the company"
in an informed way. But we can certainly hope the company comes to this
conclusion and encourages openness.

------
sitharus
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...](https://www.reactos.org/reset-reboot-restart-legal-issues-and-long-
road-03))

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.

~~~
geofft
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.)

~~~
throwaway2048
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.

~~~
geofft
Yes, many clean-room reimplementations have stood up to court challenges. But
many _non_ -clean-room reimplementations have stood up, too. My argument is
that it's neither necessary nor sufficient, just loosely correlated, and
clean-room is not inherently a defense. And in particular, my argument is that
it matters whether the communication between the dirty and clean rooms is a
specification of an interface, or a description of a reverse-engineered
implementation.

And yes, interoperability is permitted - that's why I'm saying it seems fine
to clean-room reimplement a driver to communicate with a specific device. You
do not need to have the same internal structures and the same function names
to achieve interoperability, and I think making that argument that the DMCA
allows you to have the same internal code layout will be hard.

~~~
rossy
> _You do not need to have the same internal structures and the same function
> names to achieve interoperability_

That might be the case for interoperability with a hardware device, but you
probably do to make an operating system that's compatible with Windows
software and drivers, considering how historically brazen developers are at
abusing internal details of Windows. Consider virus scanners that happily
patch internal data structures like the SSDT, or other programs that detour a
bunch of API functions, then expect those functions to be called in a specific
order when a different API function is called, or programs that just _reach
into stack frames they don 't control_ and pluck out values[1]. (There are
some other good ones in that link.) Windows takes pains to be compatible with
insane programs like this, so you could argue that copying weird
implementation details like this is necessary for interoperability.

[1]:
[https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...](https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41373)

------
rincebrain
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](https://reactos.org/wiki/Audit)

~~~
segfaultbuserr
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. _

~~~
axelriet
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.

~~~
swebs
>and it’s based on my lecture of ReactOS code at the time I downloaded it

It would be interesting to see if this statement comes back to bite you in
court if the opposite accusation is ever made. That Windows kernel developers
have been stealing from GPL code :)

~~~
mbrumlow
Man, I thought the exact same thing. I must have stolen it from you. Sorry!

In all seriousness is this normal? I write and work on kernel drivers for the
company I work for and have always gone out of my way to not view or interact
with any code that remotely relates to the work I do (out side of what I
coded). Our competitor even released their version of a block device snapshot
driver and while I would be tempted to see how they did things I have avoided
it every step of the way.

~~~
iokanuon
So, if a Microsoft kernel developer doesn't follow the practice of not reading
kernel code with an incompatible license, does that mean we can assume they
don't follow it generally? Can we assume they take code from the Linux kernel,
violating the GPL?

~~~
anticensor
Possible.

~~~
whereistimbo
Doesn't GPL actually offer a person a freedom to study the code? Isn't it a
common phenomena of rewriting GPL Linux Driver into BSD Licensed driver which
will be put into mainline *BSD?

I know the case of OpenBSD 'stealing' GPL code from broadcom linux driver, but
it was done by a naive kernel developer who copy-pasted the code and the
maintainer who didn't bother to check the authenticity of the code. But AFAIK
no GPL driver writer has a problem with the driver being rewritten into BSD
licence.

~~~
jki275
GPL is absolutely incompatible with BSD licensing. The license does not allow
for one to "rewrite" the same code into a BSD licensed driver.

Of course one could clean room reverse engineer the GPL driver and then give
the spec to someone else to implement and create a BSD driver, that would
probably be ok.

~~~
Crestwave
Not exactly incompatible, as you can license something under both of them at
once. But yes, you cannot relicense it without permission from the
contributors; this is true for pretty much any license.

~~~
jki275
Right, of course the rights holder can license under anything they want. But
no one else can take GPL code and relicense it under BSD. The same is not true
the other way -- anyone can use BSD code.

------
jchw
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.

~~~
thom_nic
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:

    
    
        $ rg InitializeContextThread
        ./ntoskrnl/ke/thrdobj.c:872:        KiInitializeContextThread(Thread,
        ./ntoskrnl/ke/powerpc/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
        ./ntoskrnl/ke/i386/thrdini.c:92:KiInitializeContextThread(IN PKTHREAD Thread,
        ./ntoskrnl/ke/amd64/thrdini.c:36:KiInitializeContextThread(IN PKTHREAD Thread,
        ./ntoskrnl/ke/arm/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
        ./ntoskrnl/include/internal/ke.h:464:KiInitializeContextThread(
    
        $ rg NpxFrame
        ./ntoskrnl/ke/i386/v86vdm.c:473:    PFX_SAVE_AREA NpxFrame;
        ./ntoskrnl/ke/i386/v86vdm.c:480:    NpxFrame = &StackFrame->NpxArea;
        ./ntoskrnl/ke/i386/v86vdm.c:481:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
        ./ntoskrnl/ke/i386/v86vdm.c:485:    RtlCopyMemory(KiGetThreadNpxArea(Thread), NpxFrame, sizeof(FX_SAVE_AREA));
        ./ntoskrnl/ke/i386/v86vdm.c:510:    PFX_SAVE_AREA NpxFrame = &StackFrame->NpxArea;
        ./ntoskrnl/ke/i386/v86vdm.c:512:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
        ./ntoskrnl/ke/i386/v86vdm.c:551:    RtlCopyMemory(NpxFrame, V86Frame->ThreadStack, sizeof(FX_SAVE_AREA));
    

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](https://github.com/Zer0Mem0ry/ntoskrnl)

[2]
[https://sourceforge.net/projects/reactos/files/ReactOS/](https://sourceforge.net/projects/reactos/files/ReactOS/)

~~~
jchw
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...](https://web.archive.org/web/20151214014944/http://www.microsoft.com/mspress/books/sampchap/4354a.aspx)

~~~
fiblye
If Microsoft cared, they wouldn’t be hosting that on their very own servers.

GitHub belongs to Microsoft. They could pull that down at any time just
because they feel like it. But they haven’t. That’s a pretty solid sign that
there’s not any legal consequence to viewing it.

~~~
squarefoot
Well, my paranoid 99% says that they could keep it online on purpose so that
all people viewing it fall in a legal disadvantage position. Removing that
code would achieve nothing in secrecy today compared to the legal leverage
they can get tomorrow by keeping it online.

------
tjpnz
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.

~~~
jle17
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.

------
daurnimator
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](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.

------
dboreham
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.

~~~
Jallal
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.

------
monocasa
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.

~~~
vxNsr
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.

~~~
emteycz
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?

~~~
monocasa
The guy in the article is talking about variable names from the source. You
wouldn't get that from Alex's style of reversing.

~~~
TomMarius
I assume that writing about Windows internals requires knowledge of said
internals? Or do you think he never had access to the source code and has
never seen anything, not even ideas of algorithms?

~~~
ubercow13
You can get knowledge of the internals and ideas of the algorithms from
reverse engineering the released Windows binaries

~~~
TomMarius
Do you believe _that_ is what Microsoft employees do while writing Windows
Internals? I have serious trouble believing it. I'm not saying that it's not
possible, just that it might not be the case there and these facts seem to
confirm it.

~~~
asvitkine
Alex Ionescu wasn't a Microsoft employee, though.

~~~
TomMarius
I'm not so sure, maybe he was a contractor if that's what you mean (I don't
see any real difference). He had a @microsoft.com e-mail address, which is a
pretty clear indicator of being on the inside.

------
moring
> 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.

~~~
codedokode
"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](https://www.nirsoft.net/kernel_struct/vista/index.html)

[2] [http://msdn.mirt.net/](http://msdn.mirt.net/)

------
jeditobe
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

~~~
amrrs
Why would you call it a PR campaign if it wasn't favoring you? Just curious.

~~~
johnmarcus
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

~~~
lacampbell
The controversy is just unverifiable claims from a Microsoft employee. ReactOS
comes out looking pretty good.

------
asveikau
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.

------
zzzzzzzzzzz
Alex Ionescu - Reversing Without Reversing
[https://www.youtube.com/watch?v=2D9ExVc0G10](https://www.youtube.com/watch?v=2D9ExVc0G10)

------
CalChris
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.

~~~
throwaway2048
Its bullshit too, there is not much public by MS but there is plenty of third
party work done on documenting it.

------
hitekker
>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?

------
rs23296008n1
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)

~~~
discordance
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?

~~~
zyang
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...

~~~
dvfjsdhgfv
They have no choice, Linux already won big time on the server, so the only way
was to embrace it in a way that would bring them money. And they succeeded big
time. Now most young developers don't remember all the dirty tactics used year
after year by MS to kill all competition, whether commercial or open source.

~~~
jasonvorhe
Also consider the amount of people leaving and joining Microsoft since than as
well as the possibility that lots of the old people a) didn't like everything
Microsoft did back then and b) are capable of changing and developing over the
years.

------
Analemma_
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.

~~~
asveikau
I heard WINE has a rule like that but ReactOS does not.

But I also heard they borrow some code from WINE.

~~~
monocasa
ReactOS had the same process.

~~~
asveikau
I thought I remember reading on an FAQ a long time ago that they don't mind
such contributions. Can't find it now. Could be wrong.

I myself am ex msft so that's why I was curious. I have not contributed to any
of these though.

Edit: found it.

[https://web.archive.org/web/20110707221707/http://www.reacto...](https://web.archive.org/web/20110707221707/http://www.reactos.org/en/dev_legalreview.html)

Section on tainted developers says: _" Tainted Developers". There is a legal
theory that is occasionally cited in the context of producing a work-alike
implementation of a published copyrighted work. ... It is the position of the
Project that this theory is invalid for a number of reasons. As a general
rule, there is no reason that a developer who has seen non-free code cannot
write logically similar code for ReactOS._ Then talks about disclosure of
NDAs.

I read that as: if you worked at MS, disclose your NDA, but it doesn't
automatically forbid your contribution.

------
cb504
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.

~~~
mav3rick
They looked at syscall surface primarily.

------
intea
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.

~~~
codedokode
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.

~~~
intea
So you're using their "leaked" or reverse engineered information? That's just
IP theft with extra steps.

~~~
codedokode
If this is made to ensure compatibility with programs using those undocumented
structures then it is a different thing. They become a part of API.

------
dejaime
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...](https://www.computerworld.com/article/2522017/microsoft-admits-plurk-
code-was-stolen.html)

~~~
RachelF
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.

~~~
whereistimbo
These .wav files might be made by person who works under Microsoft contract,
not necessarily directly employed by Microsoft.

~~~
wildfire
Which, of course, makes it perfectly acceptable?

~~~
gattilorenz
No, but if Microsoft asked for wav files, and a contractor delivered them, is
Microsoft at fault if the contractor used a pirated editing software?

~~~
jacobush
Liable? I hope so. And then they can pass the buck on.

~~~
gattilorenz
Why would Microsoft be liable?

Do you check if your butcher has illegally bought his knife? Should you be
liable, if so?

~~~
jacobush
Hmm... you may be right. But on the other hand, is the steak licensed and
copyrighted?

~~~
gattilorenz
It's not, but metaphors and analogies only go so far :)

------
canistel
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)?

~~~
bdibs
In the U.S. it is perfectly legal to reverse anything that you obtained
legally.

~~~
d1zzy
Not if you agree to an EULA that explicitly prohibits it. See
[https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand...](https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand_and_lawsuit)

And
[https://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologie...](https://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies,_Inc).

Note that pretty much any EULA I've seen in the past 10 years has had an anti
reverse engineering clause.

------
Uptrenda
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.

~~~
toyg
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.

------
shmerl
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](https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists)

------
GreenToad5
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?

~~~
yjftsjthsd-h
> 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.

------
rkagerer
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.

~~~
SmellyGeekBoy
> 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.

------
kerng
Why reverse engineer? The Windows code has been available via shared source
license since nearly 20 years....

~~~
toyg
That license does not allow to repackage the system, rebrand it, or resell it,
afaik.

------
repolfx
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/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr.c)
[https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b...](https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/balmgr.c)

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.

~~~
codedokode
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/...](https://github.com/bowlofstew/rootkit.com/blob/master/90210/phide2/phide2.doc#L49)

------
boyadjian
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.

------
nullsmack
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.

------
fenesiistvan
Alex Ionescu on this subject:
[https://www.youtube.com/watch?v=ceQ6kT1ZMrk](https://www.youtube.com/watch?v=ceQ6kT1ZMrk)

------
rifung
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.

------
hilbert42
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.)

------
sigmapiepsilon
> 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.

------
lacampbell
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

~~~
jdsully
To be fair he did say you could compare with the leaked versions.

------
bch
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?””

~~~
whereistimbo
You are right, sorry I am not good in English.

------
StillBored
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).

------
swebs
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...](http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-
are-slower-than-other-oper/)

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 :)

~~~
echelon
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.

~~~
streb-lo
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.

------
m4r35n357
Nasty article

~~~
dang
Could you please stop posting unsubstantive comments to Hacker News?

------
GnarfGnarf
I tried ReactOS recently. Got a BSOD trying to eject a CD. Lost interest.

~~~
antoineMoPa
Well at least they implemented Microsoft's best known feature (The BSOD).

------
sigmapiepsilon
> 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.

------
tathougies
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.

~~~
monkeywork
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.

~~~
hitekker
> don't add stupid things like

Don't use the word "stupid" when another, less self-righteous word suffices.

~~~
monkeywork
Stupid: having or showing a great lack of intelligence or common sense.

I stand by my choice of descriptor for that sentence.

