In preparation to hist talk at the upcoming FOSDEM conference in Brussels, ReactOS project leader Aleksey Bragin in an interview details the code audit that the project is going trough, and reveals the intellectual property minefield that such a large reverse engineered OS brings. “I can’t stress this enough: up to now, no suspicious or illegal code has been found during the audit. Buggy code – yes, this was either fixed or rewritten. Also, another part which is sometimes speculated about – that the remaining 3% of the unaudited codebase is illegal – this is completely wrong.”
“I can’t stress this enough: up to now, no suspicious or illegal code has been found during the audit.”
Absolutely not true, but just let the ReactOS users believe that until they discover the truth one day ;-(
And how would you know this? Are you part of the audit team? Do you have access to Microsoft sourcecode and have you compared it the ReactOS sourcecode? I doubt it. Stop spreading FUD.
No, I’m not on the current audit team, but I was a ReactOS developer from 1999 to 2006.
I have a few examples as the evidence you seek.
The FAT32 boot sector was and still is copied from Windows 9X. Compare it to your bootsector of any Windows 9X and you will see that they are very similar. The boot sector code has not yet been replaced, and the people doing the audit has marked it as “clean” so I guess they have no intention of reimplementing it. I can understand that. Low-level assembly code is time-consuming to write. It is much easier to just copy it from Windows.
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/boots…
The Bye Bye thread is still there (this is what started the audit):
http://www.reactos.org/archives/public/ros-dev/2006-January/007393….
> The FAT32 boot sector was and still is copied from Windows 9X.
> Compare it to your bootsector of any Windows 9X and you will see that
> they are very similar.
A boot sector is 512 bytes long. (This may even include the partition table if it’s the MBR). The code to load a boot image requires only a fraction of that – using BIOS calls you can write such a loader in about 50 bytes. This 50-byte-long code performs BIOS calls through a standard interface. For simple technical reasons the parameters to these calls are determined – otherwise the code wouldn’t do the same.
Present to me a boot loader code that does the same and does not look “similar”, to support your implication that the code was copied from windows. You may also look at boot loaders from other OSes to see that they look “similar” too, simply because there is little variation possible in a boot loader.
If all your claims focus on the boot loader, you have little point. You should really find a better example, because this one won’t hold for a second.
The boot sector code has not yet been replaced,
> and the people doing the audit has marked it as “clean” so I guess they
> have no intention of reimplementing it.
Every cleanroom re-implementation would again look similar, for the reasons stated above.
> I can understand that. Low-level assembly code is time-consuming
> to write. It is much easier to just copy it from Windows.
Since you claim the boot loader to be copied based on similarity, I heavily question your technical expertise. It is very bold to claim you understand the issue under these premises. Your implication that the code was copied was based purely on your “understanding”, and has thus no ground to stand on, and is pure defamation.
Anyway, thanks for the link to the “Bye Bye” thread.
EDIT: Made this look less like an ad hominem attack.
Edited 2007-02-03 19:50
> Since you claim the boot loader to be copied based
> on similarity, I heavily question your technical
> expertise. It is very bold to claim you understand
> the issue under these premises. Your implication
> that the code was copied was based purely on
> your “understanding”, and has thus no ground to
> stand on, and is pure defamation.
From early in the audit phase:
Add boot sector
Modified: trunk/suspect_code.txt
———————————————————————- ———-
Modified: trunk/suspect_code.txt
— trunk/suspect_code.txt 2006-01-28 18:28:52 UTC (rev 9)
+++ trunk/suspect_code.txt 2006-01-30 00:21:41 UTC (rev 10)
@@ -150,3 +150,6 @@
reimplementation and documentation found at
http://www.microsoft.com/whdc/driver/kernel/dma.mspx (note: the paper is
temporary unavailable, but I’ll make a copy available on request) ~ filip2307
+
+* Boot sector code was copied from Microsoft operating systems.
+gvg: Confirmed by brianp
As said before, it would be close to impossible to write a boot sector that does *not* look copied. You’d have to artificially make it look different, but then you could do the same with copied code too. Do you have a more striking example of copied, but marked ‘audited’ code?
Well, show us the evidence
Since all lead developers keep saying (also internally) that no illegal code has been found, I don’t see a reason not to trust them.
Frankly, these negative people that want to shoot-down every open-source project they can find are truly baffling to me.
I don’t get it – good, honest people are spending their lives dedicated to writing groundbreaking software – and the best thing some dummies can do with their time is kick developers in the face.
I consider the integrity of the ReactOS group to be much MUCH higher than most corporate entities. If we want to discuss the illegal actions of a software development group, Microsoft has the longest list of offenes I can think of (whether actually criminal or just sinister). The fact that the ReactOS group has the confidence and sheer determination to clear their name from all the public poo-slinging like the above post from ‘exception’ – I believe they will come out smelling like roses.
“I can’t stress this enough: up to now, no suspicious or illegal code has been found during the audit.”
That’s not true. There was a lot of compromised kernel code found in reactos. Of course it has been rewritten now but that doesn’t change the fact that he’s lying.
I recall seeing some logs on reactos and some conversations bettween the developers that proved this.
At least the good new is that when the code audit is over, someone or some people will have learned not to include illegal code again.
Since the mailing lists are archived and open, you should be able to produce a reference to this conversation, right?
Since the mailing lists are archived and open, you should be able to produce a reference to this conversation, right?
WRONG. The “Bye bye” thread on the mailing list discussing some of these issues was apparently deleted. If that’s not suspicious, I don’t know what is.
Ask yourself why wine doesn’t accept any ReactOS derived code. Wine was also audited and you can read on wine’s development mailing list all about what wine developers think of ReactOS.
wine was audited by an outside group. ReactOS was audited only internally.
wine’s audit took almost 2 years. ReactOS’s audit went very quickly.
wine has tests to prove undocumented behaviour, ReactOS has very few.
ReactOS is associated with the tinykrnl project, which doesn’t practice clean-room reverse engineering required in some countries.
Things mentioned on the Bye-bye thread (I’ve got it archived, if anyone wants to see) included how with each successive revision, the code that makes a system call converges more and more to the Windows XP code, and how there’s suspicious magic numbers in the ReactOS version.
As a wine hacker, I’m not touching a highly questionable project Redmond is already keeping an eye on.
> Ask yourself why wine doesn’t accept any ReactOS derived
> code. Wine was also audited and you can read on wine’s
> development mailing list all about what wine developers
> think of ReactOS.
“Because ReactOS has bad PR” as Julliard stated many times.
> wine was audited by an outside group. ReactOS was
> audited only internally.
> wine’s audit took almost 2 years. ReactOS’s audit
> went very quickly.
Maybe because reactos is not nearly as big as Wine and has much more developers ?
> ReactOS is associated with the tinykrnl project, which
> doesn’t practice clean-room reverse engineering
> required in some countries.
This is all about creating the docmentation for clean room reversing.
> Things mentioned on the Bye-bye thread (I’ve got it
> archived, if anyone wants to see) included how with
> each successive revision, the code that makes a system
> call converges more and more to the Windows XP code
True.
> .. and how there’s suspicious magic numbers in the ReactOS version.
Wine is full of magic numbers.
> As a wine hacker, I’m not touching a highly
> questionable project Redmond is already keeping an
> eye on.
I bet that they also keep an eye on wine and other foss projects.
Oh, and reactos is public so that everyone can check it, while wine’s audit is done secretly. If that’s not suspicious, I don’t know what is.
Edited 2007-02-03 13:38
The advantage of an open source project is that everyone knows nothing is hidden–it’s all available for anyone to inspect. If there’s stolen code then there is good incentive for the victim to get busy and find it and complain. I don’t hear any complaining.
The real issue is how to be sure that closed source projects haven’t stolen code.
I’d suggest you post a link (or two) that proves your point, before your post gets modded down to -5 for “personal attacks/offensive language” *.
– Gilboa
* IMHO calling someone a liar with nothing to back it up is both a personal attack and offensive language.
Edited 2007-02-03 00:16
Nice operating system study, but an usable operating system? Get serious.
> Nice operating system study, but an usable operating system? Get serious.
Why not ?
Edited 2007-02-03 13:39
Every few weeks I try loading the latest Reactos SVN live/boot CD iso into a VMWare server (the one that is free!) virtual machine, it seems to crash earlier during installation each time. Perhaps the Reactos people think as long as Reactos always crashes MSFT will leave them alone whether the code is audited or not; maybe they have a private version (not for download) that doesn’t crash. Reactos doesn’t seem useful for any purpose at this point, it seems to be pre-pre-alpha 0.0.0.1.
Any commit of a file does set the state of this file to audited. This means most of the code wasn’t audited. The audit is simply a big fake.
> Any commit of a file does set the state of this file to
> audited. This means most of the code wasn’t audited. The
> audit is simply a big fake.
Umm, hmm, … No ?