Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time.
The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative!
Thanks, Richard Campbell
I made some more general project structure suggestions a while ago, so it's not so strange that I find myself agreeing with these suggestions. While I feel that some of them, like the Windows version-specific branches, could use a bit more discussion, I do agree on the note of focusing on getting more feature-parity with one specific version of Windows. My vote would be on 2k3 (NT 5.2) as it's the most mature version of the NT 5.x series in many respects. What runs on XP will (generally) run on 2k3 as well.
Having the Vista/Win7 APIs in another branch or whatever is an option, but we should discuss the feasibility and practicality of this first, in my opinion.
As for hacks and tests, I'm in full agreement. A hack means that someone can't or doesn't know how to do something elegantly/the right way, whether it's due to ignorance or lack of interest. Unit tests are an absolute requirement to get working code and should not be skimped on in any way.
Maya
Richard Campbell wrote:
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time.
The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative!
Thanks, Richard Campbell _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On that note, I figured i'd elaborate on a couple things:
1) I personally prefer Windows XP, because while Windows 2003 is 'generally' compatible with software', Windows XP IS compatible with software. Games like Doom 3 do not install under 2003 without hacks, for instance.
2) Vista/Win7 has quite a few major changes, especially under the hood. Things like the Display Driver Model were totally revamped. The entire Windowing System is now 3d accelerated, etc. Dumping those in the mainline trunk would break things. Instead, stick with XP, and branch for breaking (Vista/7) changes. Also, things like DLL hooking can be OS dependent, so having a custom/wierd hybrid Vista/XP Winsock DLL would keep those apps from working.
On Tue, Mar 10, 2009 at 2:40 PM, Maya Posch maya@nyanko.ws wrote:
I made some more general project structure suggestions a while ago, so it's not so strange that I find myself agreeing with these suggestions. While I feel that some of them, like the Windows version-specific branches, could use a bit more discussion, I do agree on the note of focusing on getting more feature-parity with one specific version of Windows. My vote would be on 2k3 (NT 5.2) as it's the most mature version of the NT 5.x series in many respects. What runs on XP will (generally) run on 2k3 as well.
Having the Vista/Win7 APIs in another branch or whatever is an option, but we should discuss the feasibility and practicality of this first, in my opinion.
As for hacks and tests, I'm in full agreement. A hack means that someone can't or doesn't know how to do something elegantly/the right way, whether it's due to ignorance or lack of interest. Unit tests are an absolute requirement to get working code and should not be skimped on in any way.
Maya
Richard Campbell wrote:
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time.
The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative!
Thanks, Richard Campbell _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
There a bug with the ML or something? Cause this message got sent twice. Anyways.
1. I personally don't see a problem with a moving target with the Win32 side, and the kernel has been held at 2003 for quite some time now. But that's for the people working on those components to comment on, whether they want to deal with working on branches. And as I pointed out in the latest newsletter and Ged's additional comments on osnews, the project has Vista has its Win32 target, so there's nothing wrong when developers do implement Vista specific items in Win32. Assuming you're objecting to this, I disagree with going for a "frozen" target since the nature of software development and the IT field works against such a model. This doesn't mean I don't have reservations about going after a moving target, but I find it more strategically advantagenous in the long term.
2. I've seen quite a bit of the former, but I'm not really aware of any apps being hacked in order to run on ROS. It's been the position of the project for a really long time that people don't introduce hacks to get things to work on ROS. Those that have in recent times do get called out for it. If you see it, then point it out.
3. I wish you the best of luck getting the devs to do this. Trying to mandate it isn't going to work if the devs themselves aren't willing to put forth the effort to do it. That's not to say the idea is bad, but going for an all out test-centric development methodology may not be practical.
4. Again, people who do this today get called out on it and the rest of the devs have been spending a considerable amount of time trying to untangle the old code that was doing this.
In response to your second email, the driver stuff is kernel side, not user side. We'll cross that bridge when we decide to go for a NT6 kernel.
Maya Posch schrieb:
A hack means that someone can't or doesn't know how to do something elegantly/the right way, whether it's due to ignorance or lack of interest.
I have to disagree. While working on amd64 branch I added a shitload of hacks. To later remove them again. Why? Because to get things going initially, it's often reasonable to introduce a hack somewhere.
Another thing is that we are all working on different parts of the OS, all having different abilities and knowlege. Someone might work on module A, that requires some functionality from module B that isn't implemented. Example: MmSecureVirtualMemory. It's needed in win32k at several places. It's unimplemented. I currently don't have the knowledge to implement it. Most of us probably don't. I added HackSecureVirtualMemory to win32k, that should work in a similar way and can be used as a replacement (jimtabor said it's broken though, but it's an example) We could also wait until it's properly implemented in the kernel but that might take a while and might slow down further development in win32k.
What I agree on, is that adding hacks to usermode apps to make them work on ros is definitely wrong. And hacks should be marked as hacks and not used as a base for futher code design (the hacks-on-top-of-hacks-design)
Timo
Well, those 'hacks' you added I would classify as 'supports', i.e. temporary constructs which allow you to continue writing code and which you'll properly fill in later on.
What I would call a real hack is something which is like a shortcut, a quick and dirty way to accomplish something without the intent of fixing it ASAP. We have all known the temptation of doing something quickly because it would be easy to do so, instead of doing it right and taking significantly longer. One leads to quality code, the other doesn't.
Maya
Timo Kreuzer wrote:
Maya Posch schrieb:
A hack means that someone can't or doesn't know how to do something elegantly/the right way, whether it's due to ignorance or lack of interest.
I have to disagree. While working on amd64 branch I added a shitload of hacks. To later remove them again. Why? Because to get things going initially, it's often reasonable to introduce a hack somewhere.
Another thing is that we are all working on different parts of the OS, all having different abilities and knowlege. Someone might work on module A, that requires some functionality from module B that isn't implemented. Example: MmSecureVirtualMemory. It's needed in win32k at several places. It's unimplemented. I currently don't have the knowledge to implement it. Most of us probably don't. I added HackSecureVirtualMemory to win32k, that should work in a similar way and can be used as a replacement (jimtabor said it's broken though, but it's an example) We could also wait until it's properly implemented in the kernel but that might take a while and might slow down further development in win32k.
What I agree on, is that adding hacks to usermode apps to make them work on ros is definitely wrong. And hacks should be marked as hacks and not used as a base for futher code design (the hacks-on-top-of-hacks-design)
Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Richard Campbell wrote:
First Issue: Moving Target
We've already done this a few years ago. See this month's newsletter and this link for more info http://www.osnews.com/thread?351945
Ged.
Richard Campbell schrieb:
Hi Guys,
...
First Issue: Moving Target
...
This sounds like a good way to make life harder for everyone ;-) Branches are a pain in the ass. I also think that Incompatibilities due to moving target are a no-issue atm. We have a lot of other more important issues to solve: Bad design, bugs in existing implementations, missing implementations etc. The only time I had a problem with the moving target was when trying to load a wine-dll on windows XP, which failed, because it was using Vista only api. But that's wine code.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it.
I agree on that. But afair we only add app hacks to releases to make reactos look more shiny than it is. If you know of other examples, please point out where, so we can fix it and slap someone... ;)
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework.
I have started a testing framework. It's for gdi32/user32 and win32k so far. I am going to add win32k kenel mode tests soon. And we accept patches.
Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN.
Oh, do you know how many APIs there are? ntoskrnl alone has more than 1500 exports. And how many tests are you going to write? :-P
If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically.
It might especially help to find regressions faster and automatically. Might be an idea to get more people involved in writing tests.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue.
Can you specify this a little more? We use a few ros specific system calls in gdi32 and user32, and these shall go away eventually. But that needs time. I don't know of any other location where we use "ReactOS specific kernel mode code in userland".
-
Ged -
Maya Posch -
Richard Campbell -
Richard Campbell -
Timo Kreuzer -
Zachary Gorden