ReactOS audit
Moderator: Moderator Team
-
- Posts: 86
- Joined: Wed Sep 28, 2016 11:53 pm
ReactOS audit
How often does ReactOS Team audit ReactOS´s code to ensure that is safe, legal, functional ?
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: ReactOS audit
On the legal thing, I imagine it is whenever someone sees the need. Plus there are safeguards. The devs have to sign contracts and everything, and they must disclose everything. ReactOS is coded in C while older Windows is mostly in Assembly, and there is quite a bit of work to trying to convert Assembly to C.
As for safe and functional, it depends how you mean. I believe they submit it to Coverity a couple of times a year, and the PVS Studio folks regularly run their software against ReactOS. That type of code analysis looks for certain types of bugs, vulnerabilities, redundant code (may mean something else wasn't assigned or coded), memory leaks, resource leaks, race conditions, etc. Buffer overruns and underruns relate to safety (code overwriting or cutting into other code can allow malware to run), while memory leaks relate more to stability.
As for overall usability, the fans take care of that. If something isn't working, they will put it in Jira.
As for safe and functional, it depends how you mean. I believe they submit it to Coverity a couple of times a year, and the PVS Studio folks regularly run their software against ReactOS. That type of code analysis looks for certain types of bugs, vulnerabilities, redundant code (may mean something else wasn't assigned or coded), memory leaks, resource leaks, race conditions, etc. Buffer overruns and underruns relate to safety (code overwriting or cutting into other code can allow malware to run), while memory leaks relate more to stability.
As for overall usability, the fans take care of that. If something isn't working, they will put it in Jira.
Last edited by PurpleGurl on Wed Dec 28, 2016 2:10 pm, edited 1 time in total.
- EmuandCo
- Developer
- Posts: 4734
- Joined: Sun Nov 28, 2004 7:52 pm
- Location: Germany, Bavaria, Steinfeld
- Contact:
Re: ReactOS audit
All fine, but one thing is wrong. Windows is made in Visual C and thus in a C language, not Assembler.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
If my post/reply offends or insults you, be sure that you know what sarcasm is...
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: ReactOS audit
Yes, but wasn't the leaked stuff in assembly?
Re: ReactOS audit
Anyone that knows the answer to this, cannot be a developer as they have seen leaked Windows code, and it sounds like you've seen it. Also, I would have to say no it's not mainly in assembly, that would be insane and impossible to code/maintain. Any modern operating system is mainly written in C with a little assembly code wherever it is absolutely necessary.PurpleGurl wrote:Yes, but wasn't the leaked stuff in assembly?
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: ReactOS audit
Nope, haven't seen it. I just heard the 2000 leak was thousands of include files and assembly files.
And no, there is not a complete rejection here. You are not allowed to code the areas you've seen. So if you saw inside of HAL, then you'd have to avoid kernel coding, but would still be free to write unrelated drivers and userspace code. And if you have seen it, you're not barred from discussing what you've seen in the most general terms with those who are writing whatever section. For liability reasons, it is always best to do it through a mediary -- such as a copyright attorney. They can double-check to make sure you aren't passing specifics and code examples.
And the joke source code "leak" doesn't count. It is 20-30 lines total, calls the BSOD code, and then jumps to itself in a dead loop.
But even if I did see it, and I haven't, I would still have no clue about any of it and would have no idea what I was looking at. I've made no serious efforts to become a coder. And most who have seen it would never admit it. There are generally only 3 leaked streams in wide distribution. (Those who disassemble tend to keep most of that to themselves except for snippets.) The 3 streams are the leaked NT 3.x code, the Windows 2000 code, and the Windows Research Kernel.
The WRK is most troublesome in that you might have seen that in college and are barred from working with ROS kernel code. There are versions written around the WRK, but they cannot legally distribute them beyond their class or use them for anything but personal use. (Derivative works clause.) The WRK seems like a rather sneaky, anticompetitive strategy. The idea is to contaminate the coders who would be most able to write their own Windows-like OS to encumber them so they won't do so (or can be legally vulnerable and exposed if they do).
And no, there is not a complete rejection here. You are not allowed to code the areas you've seen. So if you saw inside of HAL, then you'd have to avoid kernel coding, but would still be free to write unrelated drivers and userspace code. And if you have seen it, you're not barred from discussing what you've seen in the most general terms with those who are writing whatever section. For liability reasons, it is always best to do it through a mediary -- such as a copyright attorney. They can double-check to make sure you aren't passing specifics and code examples.
And the joke source code "leak" doesn't count. It is 20-30 lines total, calls the BSOD code, and then jumps to itself in a dead loop.
But even if I did see it, and I haven't, I would still have no clue about any of it and would have no idea what I was looking at. I've made no serious efforts to become a coder. And most who have seen it would never admit it. There are generally only 3 leaked streams in wide distribution. (Those who disassemble tend to keep most of that to themselves except for snippets.) The 3 streams are the leaked NT 3.x code, the Windows 2000 code, and the Windows Research Kernel.
The WRK is most troublesome in that you might have seen that in college and are barred from working with ROS kernel code. There are versions written around the WRK, but they cannot legally distribute them beyond their class or use them for anything but personal use. (Derivative works clause.) The WRK seems like a rather sneaky, anticompetitive strategy. The idea is to contaminate the coders who would be most able to write their own Windows-like OS to encumber them so they won't do so (or can be legally vulnerable and exposed if they do).
Re: ReactOS audit
Well, how often does Microsoft audit its code to make sure nobody of their devs smuggles in programs in breach of the GPL?
The reality is: having an established rule-set is all that can be required. NOBODY does "permanent audits". And nobody has to.
The reality is: having an established rule-set is all that can be required. NOBODY does "permanent audits". And nobody has to.
Re: ReactOS audit
Microsoft has violated the gpl license http://www.zdnet.com/article/microsoft- ... e-license/Aeneas wrote:Well, how often does Microsoft audit its code to make sure nobody of their devs smuggles in programs in breach of the GPL?
The reality is: having an established rule-set is all that can be required. NOBODY does "permanent audits". And nobody has to.
http://www.theregister.co.uk/2009/07/23 ... violation/
Re: ReactOS audit
The first link sais that microsoft contracted a third-party developer to make the tool, and merely didnt catch the gpl violation; I dunno the legal terms involved, but i would lay blame at the 3rd party developer for that case.
I didnt understand the second link too much about what happened.
I didnt understand the second link too much about what happened.
Who is online
Users browsing this forum: No registered users and 76 guests