1. 6
    What do you think about ReactOS? osdev quora.com

Axel Rietschin, Kernel Engineer at Microsoft, explains why he thinks ReactOS is a ripoff of the Windows Research Kernel. Here is the hackernews thread with some additional context.

  1.  

  2. 12

    …thinks ReactOS is a ripoff of the Windows Research Kernel.

    Worth noting that in this context, “ripoff” means “stolen”, not “shoddy copy of”. Reitschin thinks that ReactOS uses stolen code.

    I’m not saying that’s true, just clarifying for those who haven’t read TFA.

    1. 4

      Windows a clone and modification of OpenVMS. ReactOS a clone and modification of Windows. Pot, meet kettle.

      1. 4

        Calling NT a “clone” of VMS is going a bit far. They’re not binary compatible, for one thing. And I really doubt Cutler straight-up copied code (even though syscalls etc are similarly named).

        For one thing, Cutler strikes me as the kind of person who’d take it as a point of pride not to copy anyone’s work, even his own,

        1. 3

          “Clone” might be overdoing it. There was lots of copying as described here.

      2. 3

        It seems to me that this is just repeating FUD, as seen in the orange site thread.

        1. 3

          I encourage Mr. Rietschin to look at the Haiku project as an example of how much kernel compatibility can be attained without access to the source code.

          1. 17

            His claim is a little more nuanced than “kernel compatibility is impossible”[0] and goes like this:

            1. ReactOS uses the same symbols and sometimes macros in a couple of places (where somebody with access to both cared to look)

            2. The only way to get to such detailed information (that he is aware of, see below) is through the “Microsoft confidential” marked binders he posted a photo of.

            3. Therefore there must have been knowledge leaking into ReactOS that can only have been attained through copyright violating means (or worse)

            4. Since ReactOS, for the most part, aims for a circa Windows 2003 architecture, and since there were leaks of that code base, that must have been the source they tapped.

            What he’s not considering is that it’s kind of a sport for lots of folks to dig up all details they can get about the internals, and entire books were written detailing the design. Software that hooks into Windows in unstable interfaces was also rather common in the 90s and early 2000s.

            Sources for this stuff were, for example: “checked” builds that Microsoft released to driver developers for a long time (build with debug flags and all assertions in - and there are many assertions in Windows code, and for compatibility reasons they even keep the wrong ones once they’ve made it in[1]); insufficiently stripped symbol data on their symbols server (windbg et al can download symbols to binaries for easier analysis) that were released every now and then.

            There are hoarders that collect stuff like that. Sometimes they write books about the knowledge they gleam from that, sometimes they’re available for answering pointed questions.

            That also explains why ReactOS is remaining broadly in the Win2003 era: people did a lot of digging back then, and a lot of documenting, and it’s a reasonable base for a reimplementation because most of today’s software can still be made to work on “Win2003 + a select few APIs”.

            Since then, Microsoft got in the habit[2] of using their software vendors (who did such time consuming work) as market research, obsoleting their work with something that ships in the next Windows version for free: no use competing with that, which is why the Windows ecosystem became a lot more dull in the last ~15 years.

            [0] Besides: Haiku isn’t kernel driver level compatible, both because it’s not worth keeping that level of compatibility with a kernel that never had many drivers to begin with, and because, while newOS was started by one of BeOS’ kernel developers (who’s now working on Fuchsia’s kernel Zircon), it’s a rather different beast.

            [1] See https://www.coreboot.org/ACPI#Using_checked_builds: When I was debugging ACPI in coreboot for Windows XP compatibility, I ran into blue screens that simply made no sense. The issue was that the assert was inverted, something alone the lines of (very freely paraphrased) handleElseOp() { ASSERT(prevOp == IfOp, “Else must only follow If”); … }. It should have been “prevOp != IfOp”. That issue appeared in Windows 2000 as far as I can tell, and XP still kept in that assert (which had only an effect on checked builds), apparently to prevent platforms from using that opcode now that there are (developer-only) Windows versions that fail on it. It usually works out because iasl and similar ACPI compilers do away with the “Else” (presumably for Windows 2000 :-) ), but coreboot has its own ACPI code generator for a few tasks, and we weren’t aware of that constraint.

            [2] they did before, but in my opinion that only grew worse.

            1. 5

              All good points, though they’re not nearly as pithy as mine ;)

              I’ll add to your differences that Haiku has the luxury of dealing with an unmoving target. Nobody is producing new BeOS versions, so nobody can get suspicious that Haiku is targeting compatibility with 2001 software.

              I’ll also add an important point to your criticism of the author: accusations like this were persistent enough that the project performed a complete code audit and added strict rules regarding reverse engineering over a decade ago. That audit did not find any suspicious code, and the new rules make it unlikely any has been added in the meantime.

              1. 3

                [0] Besides: Haiku isn’t kernel driver level compatible, both because it’s not worth keeping that level of compatibility with a kernel that never had many drivers to begin with

                This is incorrect; Haiku was for a long time driver-level compatible. We are much less so now (notably filesystem drivers changed KABI, and audio drivers changed ioctl interface versions, among other things.) But in theory if you have a random special sauce PCI driver from BeOS R5, you can run it against a current Haiku kernel and it will (potentially) still work; and if it doesn’t, making it work is likely just a recompile away.

                and because, while newOS was started by one of BeOS’ kernel developers (who’s now working on Fuchsia’s kernel Zircon), it’s a rather different beast.

                Indeed it is.

            2. 3

              If there were substantial similarities, I’m very sure Microsoft wouldn’t have flinched even a second to send some very expensive lawyers into the bedrooms of the people working on ReactOS.

              1. 13

                You seem to believe lawyers have a more action-packed workday than most.

                1. 1

                  One man’s laywer is another man’s hired goon.

                  1. 1

                    Well yes, but most lawyers tend to work 9-5 (or 9-9) in an office. Busting doors to bedrooms is seldom part of the workday outside of TV shows.

                    (Or Stross novels - there’s a fun scene in Accelerando featuring them)