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".