Some Questions

[MugenFighter]

I have a few questions regarding the ReactOS.

1. Does anyone keep a log of the Epic Win topic? I noticed that somethings aren't 100% working.

2. How does ReactOS get it's funds? There is more than one way right?

3. How does ReactOS reverse engineer Windows without decompiling Windows? Just wondering.

[Konata]

A few people report applications working without actually testing them beyond their initial startup. Rest assured actual regressions are kept track of in the JIRA. And ReactOS does something called "clean room reverse-engineering" which means there are people who's job it is to specifically decompile Microsoft Windows, document what they find, and then do nothing else. That's the legal way to reimplement copywritten software in America. Developers also use the vast amounts of documentation out there, like the Windows Internals series of books and the Microsoft Developer Network website (MSDN).

[MugenFighter]

A few people report applications working without actually testing them beyond their initial startup. Rest assured actual regressions are kept track of in the JIRA. And ReactOS does something called "clean room reverse-engineering" which means there are people who's job it is to specifically decompile Microsoft Windows, document what they find, and then do nothing else. That's the legal way to reimplement copywritten software in America. Developers also use the vast amounts of documentation out there, like the Windows Internals series of books and the Microsoft Developer Network website (MSDN).

Thanks, that made it more clear. Just out of curiosity are the decompiled files kept for future documentation or deleted. Does the law say something about it?

[Swyter]

A few people report applications working without actually testing them beyond their initial startup. Rest assured actual regressions are kept track of in the JIRA. And ReactOS does something called "clean room reverse-engineering" which means there are people who's job it is to specifically decompile Microsoft Windows, document what they find, and then do nothing else. That's the legal way to reimplement copywritten software in America. Developers also use the vast amounts of documentation out there, like the Windows Internals series of books and the Microsoft Developer Network website (MSDN).

Thanks, that made it more clear. Just out of curiosity are the decompiled files kept for future documentation or deleted. Does the law say something about it?

Disassembling software you own is perfectly legal in the EU. But normally one does no need to decompile to see what the underlying code is doing.

Black box testing is pretty common, where you feed the code you want to re-implement inputs and get its outputs, in many cases the process is deterministic and you can re-implement most of the function empirically, without having to even look at its guts. That's what testing frameworks do, where you incrementally make more tests pass by making your implementation more correct. When most of the code pathways return the same outputs in both versions you got a mostly faithful —and extremely clean— re-implementation.

Also, being as popular as Windows is, there's public debug symbols of internal components provided by Microsoft and freely available for download, mainly aimed at driver developers and experienced engineers capable of using WinDBG.

There's also plenty of original research on undocumented parts done —and independently published on the Internet— by third-party people like Geoff Chappell, that's as clean and indirect as it gets.

[Black_Fox]

Just adding to Swyter's great answer - sometimes you can see in the commit log that a new test was created to check something, followed by a code change applying knowledge obtained from the test. Another advantage of the test suite is that it is run on every revision. If a regression appears, it can be detected by the tests.
There are also (automated) tests for specific applications, though I'm not sure about the current status.

[Konata]

Actually, yeah, I forget ReactOS does a lot of black box guesswork. A good example is the mechanism in Windows that converts long filenames into old 8.3 alphanumeric names for compatibility. I'm guessing nobody bothered to decompile/document how it worked, because the one in ReactOS functioned completely differently from the one in Windows (which isn't a bad thing, it's pretty inconsequential). The story about it can be found here, it's a great read and very informative on subjects like decompiling and reverse-engineering. It also mentions ReactOS and compares it's implementation of the function with the one in Windows.

[PurpleGurl]

I have a few questions regarding the ReactOS.

1. Does anyone keep a log of the Epic Win topic? I noticed that somethings aren't 100% working.

2. How does ReactOS get it's funds? There is more than one way right?

3. How does ReactOS reverse engineer Windows without decompiling Windows? Just wondering.

1. Some do put wins in there that don't completely work. They are still wins in that they previously might not have worked at all. They might not work at all without crashing for years, then start loading after one or more fixes, but still have other problems. Just loading doesn't mean it does its core functions. It might crash, do nothing, or do something other than expected. Or it might essentially work, but have cosmetic problems or minor program features refuse to run. So there are some working apps charts as well as reports of bugs and regressions in Jira.

2. ROS raises money a number of ways. One is just interested people donating. Another is the occasional fundraiser or campaign, such as the Community Edition campaign. There may also be things like Google SOC where ROS would be paid to take on intern coders for a brief period. Most don't do heavy lifting unless they are already a part of ROS and then qualify for GSOC when ROS is also chosen.

3. There are a number of ways here. As pointed out, there is clean room reverse engineering where people do disassemble Windows but have no ties to the project. They only go into it to see what is done, not to write code. However, they would never be allowed to write any code for ROS, at least not anywhere related to the sections they saw. There is also lots of leaked code in public including Windows 2000, NT code, and the WRK (Windows Research Kernel -- only released for academic reasons and not allowed to be used for any other purpose). Those who have seen it can only mention what it does and document it, but not write any code.

However, reverse engineering or looking at actual source is not the only way. You can also rely on documentation, trial and error, brute force testing, software monitoring (like looking at what gets passed to the stack and registers), and guesswork. There may also be cases where the internal calls are very obscure and ROS simply does things its own way. That would only be done in things that don't impact compatibility as far as known.

Then there are already some open source components. ROS contains a lot of Wine code. The SATA/ATA driver came from someone who was motivated to write it for other reasons than building an OS. He was tired of not having drivers for older, unknown, or discontinued technology, and tired of slow drivers. He was also tired of having drivers for some OSs and not others. So he wrote a replacement to work with devices which have no drivers or which have unsuitable drivers. Supposedly, the UniATA driver will work with even RLL, MFM, ESDI, and other drives that are not commonly used anymore. Along that line, that is what I like about the default ROS VGA driver. It has Windows beat in that it gives you 256 colors after a clean install, while Windows only gives 16.