10 Mar
2009
10 Mar
'09
5:59 p.m.
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
10 Mar
10 Mar
6:40 p.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
6:53 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
7 p.m.
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.
7:15 p.m.
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
7:49 p.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 
7:02 p.m.
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.
8:09 p.m.
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".
5680
days inactive
5680
days old
7 comments
6 participants
participants (6)
-
Ged -
Maya Posch -
Richard Campbell -
Richard Campbell -
Timo Kreuzer -
Zachary Gorden