Live data from Hacker News

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

quora.com

101–110 of 291 posts

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

#101
post #46

Earlier quoted context omitted.

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.

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 desc…

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

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

#102
post #88

> 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 compatibili…

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

True, unfortunately.

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

#103
post #3

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 possibl…

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 h…

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.

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

#104
post #98
post #12

Earlier quoted context omitted.

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?

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

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

#105
post #61

Earlier quoted context omitted.

Does a software license in this case count as a contract? Moreover, interoperability is not the same as distribution no? Honestly ReactOS's lengths do not seem like overkill to me, quite the contrary. Even re-implementing an API is legally suspect these days (see: Oracle vs. Google re: Android). Copying the internals of a piece of software by having one person explain verbally exactly how it works to another person w…

Yes, EULA is a contract and has been successfully tested in court against reverse engineering: https://www.eff.org/cases/blizzard-v-bnetd

For the contract portion of the EULA to be enforceable, you have to get the user to explicitly and willingly agree to it.

Tricking the user with a shrink-wrap license ("by opening this package you have agreed...") would not hold in court.

Asking users to click "I Agree" in installers also has dubious value due to the widespread practice of clicking these buttons to proceed without really reading the contract; their true intention was proceeding to the next question rather than entering any agreement.

In other words: if most reasonable persons wouldn't expect to be actually bound to the conditions listed in the contract, then Microsoft cannot effectively enforce them in a court.

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

#106
post #100

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.

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

#107
post #67

Earlier quoted context omitted.

I don't think Microsoft cares that much, but I'm sure they view it for what it is: illegal, unauthorized usage of their intellectual property. (I'll hold off on my personal views of 'intellectual property' and whatnot; I'm not a lawyer, and those opinions are hardly relevant to the reality here.) Still, even if Microsoft doesn't care, Wine Project and ReactOS care. My employer might care. There are unfortunately lega…

What stops someone from viewing that repo over Tor, on a different git server, or at a public library, unsecured WiFi network, etc and being considered tainted? At what point is someone considered untainted? This seems like a grey area that slows the pace of R&D in countries that believe code is copyrightable & patentable (the US and select Western countries) compared to say New Zealand & China, where these aren't an…

Where did you get that idea about New Zealand copyright? Code is copyrightable here, see e.g. [1] or [2].

And it's not about belief, but definition. Copyright and patents are human inventions defined by countries' laws (which is why different countries have different rules: different definitions). In NZ, as in many countries, "Computer software follows the rules for literary work" ([2] again).

[1] http://www.burgess.co.nz/copyright-ownership-and-software-de...

[2] https://www.consumer.org.nz/articles/copyright-law

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

#108
post #3

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 possibl…

Is Stardock still a thing?

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

#109

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 DD…

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.
Post reply on HN