48 ms·

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

532 points by whereistimbo 7y ago

kickitover 7y ago
What a fscking bootlicker.
- naikrovek 7y ago
  How extraordinarily fair and thoughtful of you...
jchw 7y ago
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.
- jacobush 7y ago
  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.
- hermitdev 7y ago
  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).
  - jchw 7y ago
    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-and-long-road-03 https://www.reactos.org/reset-reboot-restart-legal-issues-an...
    - hermitdev 7y ago
      Sadly that link is currently erroring out for me with a database error. There is also a difference between stated policy and what actually ends up happening (not that I'm making any accusations, because I'm not). But what happens publicly isn't necessarily representative of what happens privately. I mean, I can't contribute to it, because I have seen some source or disassembled components of Windows over the years. But excepting my public declaration of that here and now, who is to know?
      - jchw 7y ago
        Oh definitely, I choose not to speculate on that because again, its futile; it’s not really realistically possible to prove that it wasn’t done illegitimately. Clean-room reverse engineering can very well end up with indistinguishable results from just stealing code carefully.
  - daurnimator 7y ago
- thom_nic 7y ago
  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 7y ago
    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.microsoft.com/mspress/books/sampchap/4354a.aspx https://web.archive.org/web/20151214014944/http://www.micros...
- indigodaddy 7y ago
  Is Stardock still a thing?
Analemma_ 7y ago
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 7y ago
  I heard WINE has a rule like that but ReactOS does not. But I also heard they borrow some code from WINE.
  - monocasa 7y ago
    ReactOS had the same process.
    - asveikau 7y ago
      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.reactos.org/en/dev_legalreview.html https://web.archive.org/web/20110707221707/http://www.reacto... 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.
- riffraff 7y ago
  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.
asveikau 7y ago
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.
monocasa 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        You can get knowledge of the internals and ideas of the algorithms from reverse engineering the released Windows binaries
        TomMarius 7y ago
rs23296008n1 7y ago
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 7y ago
  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?
  - dingo_bat 7y ago
    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?
  - zyang 7y ago
    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 7y ago
      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.
GnarfGnarf 7y ago
I tried ReactOS recently. Got a BSOD trying to eject a CD. Lost interest.
- darkwinx 7y ago
  It's still in alpha version. Could also be an compatibility issue with your hardware.
- antoineMoPa 7y ago
  Well at least they implemented Microsoft's best known feature (The BSOD).
canistel 7y ago
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 7y ago
  In the U.S. it is perfectly legal to reverse anything that you obtained legally.
  - canistel 7y ago
    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.
  - opportune 7y ago
    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.
  - d1zzy 7y ago
    Not if you agree to an EULA that explicitly prohibits it. See https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand_and_lawsuit https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand... And https://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies,_Inc 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.
rincebrain 7y ago
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
- unstatusthequo 7y ago
  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?
  - dvfjsdhgfv 7y ago
    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.
  - riffraff 7y ago
    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.
    - miohtama 7y ago
      Also, attempting to take it down would surely cause reputation damage to Microsoft. The "old" Microsoft is somewhat infamous. Going after the small guy would not help their image.
  - HeWhoLurksLate 7y ago
    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.
dejaime 7y ago
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-admits-plurk-code-was-stolen.html https://www.computerworld.com/article/2522017/microsoft-admi...
- RachelF 7y ago
  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.
  - citrusui 7y ago
    As far as I could research, I only found articles about Windows XP. Close enough. https://www.tomshardware.co.uk/pirated-software-used-to-create-help-content-in-microsofts-windows-xp,news-14167.html https://www.tomshardware.co.uk/pirated-software-used-to-crea...
  - whereistimbo 7y ago
    These .wav files might be made by person who works under Microsoft contract, not necessarily directly employed by Microsoft.
    - wildfire 7y ago
      Which, of course, makes it perfectly acceptable?
      - gattilorenz 7y ago
        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?
        7y ago
sitharus 7y ago
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-and-long-road-03 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.
- deleted 7y ago
  [deleted]
- opportune 7y ago
  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...
  - SllX 7y ago
    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.
    - opportune 7y ago
      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 who translates that to code feels a lot more like stealing than that.
daurnimator 7y ago
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.
CalChris 7y ago
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 7y ago
  Its bullshit too, there is not much public by MS but there is plenty of third party work done on documenting it.
m4r35n357 7y ago
Nasty article
- dang 7y ago
  Could you please stop posting unsubstantive comments to Hacker News?
zzzzzzzzzzz 7y ago
Alex Ionescu - Reversing Without Reversing https://www.youtube.com/watch?v=2D9ExVc0G10 https://www.youtube.com/watch?v=2D9ExVc0G10
intea 7y ago
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.
- rvp-x 7y ago
  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.
- codedokode 7y ago
  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 7y ago
    So you're using their "leaked" or reverse engineered information? That's just IP theft with extra steps.
    - 7y ago
Uptrenda 7y ago
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 7y ago
  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.
kerng 7y ago
Why reverse engineer? The Windows code has been available via shared source license since nearly 20 years....
- toyg 7y ago
  That license does not allow to repackage the system, rebrand it, or resell it, afaik.
tathougies 7y ago
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 7y ago
  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.
  - ivolimmen 7y ago
    I wish everyone would read their Facebook stream with your eyes...
  - hitekker 7y ago
    > don't add stupid things like Don't use the word "stupid" when another, less self-righteous word suffices.
    - monkeywork 7y ago
      Stupid: having or showing a great lack of intelligence or common sense. I stand by my choice of descriptor for that sentence.
  - Haga 7y ago
    Why? It's public knowledge that most company code, except Google maybe, is "good enough code". That is literally one of the reason why people dev open source.. to write clean implementations and restore their self worth. Azure e. G. is a mess so bad, Microsoft can't find internal hires for it. Do you sincerely doubt the efficiency of capitalism when it comes to code bases?
tjpnz 7y ago
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.
- segfaultbuserr 7y ago
  Upvoted. The history of Microsoft is well-documented, including the accusation of "stealing" code. Not sure why your comment has been downvoted.
- wruza 7y ago
  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.
- jle17 7y ago
  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.
- codedokode 7y ago
  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 https://www.nirsoft.net/kernel_struct/vista/index.html [2] http://msdn.mirt.net/ http://msdn.mirt.net/
bch 7y ago
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 7y ago
  You are right, sorry I am not good in English.
projectileboy 7y ago
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.
- icemelt8 7y ago
  pathetic comment.
hitekker 7y ago
>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?
axelriet 7y ago
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?
moring 7y ago
> 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.
- jegs 7y ago
  > On the internet, the burden of proof is on the accused. True, unfortunately.
- msiyer 7y ago
  Maybe, you are looking for this: https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363 https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41...
- codedokode 7y ago
  "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/
GreenToad5 7y ago
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 7y ago
  > 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.
- swdev281634 7y ago
  > 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.
cb504 7y ago
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 7y ago
  They looked at syscall surface primarily.
jeditobe 7y ago
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
- notus 7y ago
  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.
  - michaelmrose 7y ago
    You mean the accusations for which the accuser refuses to provide any proof?
  - codedokode 7y ago
    What "points"? Axel didn't provide a single example of what could be allegedly copied code.
- amrrs 7y ago
  Why would you call it a PR campaign if it wasn't favoring you? Just curious.
  - johnmarcus 7y ago
    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 7y ago
      The controversy is just unverifiable claims from a Microsoft employee. ReactOS comes out looking pretty good.
  - jeditobe 7y ago
    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 $)
swebs 7y ago
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-we-are-slower-than-other-oper/ 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 :)
- echelon 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - ido 7y ago
    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.
  - streb-lo 7y ago
    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.
- dang 7y ago
  We detached this subthread from https://news.ycombinator.com/item?id=20341933 https://news.ycombinator.com/item?id=20341933.
lacampbell 7y ago
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 7y ago
  To be fair he did say you could compare with the leaked versions.
nullsmack 7y ago
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.
shmerl 7y ago
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
dboreham 7y ago
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 7y ago
  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.
  - deleted 7y ago
    [deleted]
repolfx 7y ago
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.c https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr... https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/balmgr.c 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.
- amaccuish 7y ago
  > 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?
rkagerer 7y ago
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 7y ago
  > 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.
rifung 7y ago
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.
sigmapiepsilon 7y ago
> 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.
sigmapiepsilon 7y ago
> 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.
deleted 7y ago
[deleted]
StillBored 7y ago
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).
fenesiistvan 7y ago
Alex Ionescu on this subject: https://www.youtube.com/watch?v=ceQ6kT1ZMrk https://www.youtube.com/watch?v=ceQ6kT1ZMrk
hilbert42 7y ago
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.)
boyadjian 7y ago
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.

532 points by whereistimbo 7y ago

kickitover 7y ago

What a fscking bootlicker.

naikrovek 7y ago
How extraordinarily fair and thoughtful of you...

jchw 7y ago

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.

jacobush 7y ago
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.
hermitdev 7y ago
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).
- jchw 7y ago
  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-and-long-road-03 https://www.reactos.org/reset-reboot-restart-legal-issues-an...
  - hermitdev 7y ago
    Sadly that link is currently erroring out for me with a database error. There is also a difference between stated policy and what actually ends up happening (not that I'm making any accusations, because I'm not). But what happens publicly isn't necessarily representative of what happens privately. I mean, I can't contribute to it, because I have seen some source or disassembled components of Windows over the years. But excepting my public declaration of that here and now, who is to know?
    - jchw 7y ago
      Oh definitely, I choose not to speculate on that because again, its futile; it’s not really realistically possible to prove that it wasn’t done illegitimately. Clean-room reverse engineering can very well end up with indistinguishable results from just stealing code carefully.
- daurnimator 7y ago
thom_nic 7y ago
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 7y ago
  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.microsoft.com/mspress/books/sampchap/4354a.aspx https://web.archive.org/web/20151214014944/http://www.micros...
indigodaddy 7y ago
Is Stardock still a thing?

Analemma_ 7y ago

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 7y ago
I heard WINE has a rule like that but ReactOS does not. But I also heard they borrow some code from WINE.
- monocasa 7y ago
  ReactOS had the same process.
  - asveikau 7y ago
    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.reactos.org/en/dev_legalreview.html https://web.archive.org/web/20110707221707/http://www.reacto... 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.
riffraff 7y ago
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.

asveikau 7y ago

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.

monocasa 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        You can get knowledge of the internals and ideas of the algorithms from reverse engineering the released Windows binaries
        TomMarius 7y ago

rs23296008n1 7y ago

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 7y ago
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?
- dingo_bat 7y ago
  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?
- zyang 7y ago
  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 7y ago
    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.

GnarfGnarf 7y ago

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

darkwinx 7y ago
It's still in alpha version. Could also be an compatibility issue with your hardware.
antoineMoPa 7y ago
Well at least they implemented Microsoft's best known feature (The BSOD).

canistel 7y ago

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 7y ago
In the U.S. it is perfectly legal to reverse anything that you obtained legally.
- canistel 7y ago
  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.
- opportune 7y ago
  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.
- d1zzy 7y ago
  Not if you agree to an EULA that explicitly prohibits it. See https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand_and_lawsuit https://en.wikipedia.org/wiki/Bnetd#Blizzard_takedown_demand... And https://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies,_Inc 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.

rincebrain 7y ago

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

unstatusthequo 7y ago
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?
- dvfjsdhgfv 7y ago
  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.
- riffraff 7y ago
  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.
  - miohtama 7y ago
    Also, attempting to take it down would surely cause reputation damage to Microsoft. The "old" Microsoft is somewhat infamous. Going after the small guy would not help their image.
- HeWhoLurksLate 7y ago
  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.

dejaime 7y ago

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

RachelF 7y ago
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.
- citrusui 7y ago
  As far as I could research, I only found articles about Windows XP. Close enough. https://www.tomshardware.co.uk/pirated-software-used-to-create-help-content-in-microsofts-windows-xp,news-14167.html https://www.tomshardware.co.uk/pirated-software-used-to-crea...
- whereistimbo 7y ago
  These .wav files might be made by person who works under Microsoft contract, not necessarily directly employed by Microsoft.
  - wildfire 7y ago
    Which, of course, makes it perfectly acceptable?
    - gattilorenz 7y ago
      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?
      - 7y ago

sitharus 7y ago

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-and-long-road-03 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.

deleted 7y ago
[deleted]
opportune 7y ago
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...
- SllX 7y ago
  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.
  - opportune 7y ago
    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 who translates that to code feels a lot more like stealing than that.

daurnimator 7y ago

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.

CalChris 7y ago

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 7y ago
Its bullshit too, there is not much public by MS but there is plenty of third party work done on documenting it.

m4r35n357 7y ago

Nasty article

dang 7y ago
Could you please stop posting unsubstantive comments to Hacker News?

zzzzzzzzzzz 7y ago

Alex Ionescu - Reversing Without Reversing https://www.youtube.com/watch?v=2D9ExVc0G10 https://www.youtube.com/watch?v=2D9ExVc0G10

intea 7y ago

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.

rvp-x 7y ago
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.
codedokode 7y ago
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 7y ago
  So you're using their "leaked" or reverse engineered information? That's just IP theft with extra steps.
  - 7y ago

Uptrenda 7y ago

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

kerng 7y ago

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

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

tathougies 7y ago

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 7y ago
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.
- ivolimmen 7y ago
  I wish everyone would read their Facebook stream with your eyes...
- hitekker 7y ago
  > don't add stupid things like Don't use the word "stupid" when another, less self-righteous word suffices.
  - monkeywork 7y ago
    Stupid: having or showing a great lack of intelligence or common sense. I stand by my choice of descriptor for that sentence.
- Haga 7y ago
  Why? It's public knowledge that most company code, except Google maybe, is "good enough code". That is literally one of the reason why people dev open source.. to write clean implementations and restore their self worth. Azure e. G. is a mess so bad, Microsoft can't find internal hires for it. Do you sincerely doubt the efficiency of capitalism when it comes to code bases?

tjpnz 7y ago

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.

segfaultbuserr 7y ago
Upvoted. The history of Microsoft is well-documented, including the accusation of "stealing" code. Not sure why your comment has been downvoted.
wruza 7y ago
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.
jle17 7y ago
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.
codedokode 7y ago
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 https://www.nirsoft.net/kernel_struct/vista/index.html [2] http://msdn.mirt.net/ http://msdn.mirt.net/

bch 7y ago

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 7y ago
You are right, sorry I am not good in English.

projectileboy 7y ago

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.

icemelt8 7y ago
pathetic comment.

hitekker 7y ago

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

axelriet 7y ago

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?

moring 7y ago

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

jegs 7y ago
> On the internet, the burden of proof is on the accused. True, unfortunately.
msiyer 7y ago
Maybe, you are looking for this: https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363 https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41...
codedokode 7y ago
"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/

GreenToad5 7y ago

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 7y ago
> 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.
swdev281634 7y ago
> 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.

cb504 7y ago

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 7y ago
They looked at syscall surface primarily.

jeditobe 7y ago

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

notus 7y ago
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.
- michaelmrose 7y ago
  You mean the accusations for which the accuser refuses to provide any proof?
- codedokode 7y ago
  What "points"? Axel didn't provide a single example of what could be allegedly copied code.
amrrs 7y ago
Why would you call it a PR campaign if it wasn't favoring you? Just curious.
- johnmarcus 7y ago
  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 7y ago
    The controversy is just unverifiable claims from a Microsoft employee. ReactOS comes out looking pretty good.
- jeditobe 7y ago
  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 $)

swebs 7y ago

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-we-are-slower-than-other-oper/ 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 :)

echelon 7y ago
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.
- deleted 7y ago
  [deleted]
- ido 7y ago
  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.
- streb-lo 7y ago
  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.
dang 7y ago
We detached this subthread from https://news.ycombinator.com/item?id=20341933 https://news.ycombinator.com/item?id=20341933.

lacampbell 7y ago

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 7y ago
To be fair he did say you could compare with the leaked versions.

nullsmack 7y ago

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.

shmerl 7y ago

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

dboreham 7y ago

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 7y ago
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.
- deleted 7y ago
  [deleted]

repolfx 7y ago

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.c https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr... https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/balmgr.c 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.

amaccuish 7y ago
> 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?

rkagerer 7y ago

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

rifung 7y ago

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.

sigmapiepsilon 7y ago

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

sigmapiepsilon 7y ago

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

deleted 7y ago

[deleted]

StillBored 7y ago

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

fenesiistvan 7y ago

Alex Ionescu on this subject: https://www.youtube.com/watch?v=ceQ6kT1ZMrk https://www.youtube.com/watch?v=ceQ6kT1ZMrk

hilbert42 7y ago

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

boyadjian 7y ago

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.