17 May
2009
17 May
'09
12:28 a.m.
Zachary Gorden wrote:
The analogy between comparing a Linux distro and ROS
doesn't work, since the
components within ROS are interdependent pretty much by design. One isn't
supposed to be developing them independently of each other.
Uhhm... where did you
get that from? Heard of MinWin? MS has finally
addressed the issue of a huge interdependency mess and get a cleaner
layered design. Now you want to totally ignore it and repeat old
mistakes or make it even worse?
The only major
component that can get away with it, specifically some of the user mode DLLs
for win32, are already being done by Wine, not us. All those DLLs come from
Wine and we only occasionally modify them to fix a bug or an
incompatibility.
Probably all other dlls that we forked or always developed on our own
(except ntdll, gdi32, user32, kernel32) could be developed against Windows.
And what about drivers, services, cpls, shell extensions, explorer, cmd,
user mode apps, ...
I'm getting the impression that people are
confused as to what exactly the
ROS team develops. The team works on essentially the kernel mode side of
things, which includes the kernel side of the Win32 subsystem, and the NT
kernel itself, along with the basic drivers one needs to get going. On the
Maybe that's the reason for discussing about things like an ftp server,
which is surely not a kernel or core component. ;-)
In earlier times I remember a kind of "if you need it, you can download
and install it" philosophy, but not anymore it seems.
Talking about "consistency": There's tons of stuff that Windows has,
where we could import 3rd party code. Where do we draw the line?
Drivers? Media stuff? Web browser? More server stuff? If we really
decide to put everything that windows has into the main folder we really
need a new build system or we will soon end up with unbearable
compilation times.
Talking about build system changes. We don't have them. Is anyone even
working on them? It is something that might be there in the future, but
not now. And will it help me updating selected components from svn? Will
it help builtbot to rebuild only that part of the code that the last
commit affected? I guess not.
user mode side, we also need to do all the stuff that
acts as the interface
between kernel and user mode. This can't be split as some kind of third
party effort, as it's tied in too directly to the kernel design.
No it
isn't. NT doesn't need win32 and win32 can live without all those
fancy highlevel dlls. Network, sound DirectX, all of them optional.
Would be
pretty much pointless since no one else would have a use for it and we would
need to guarantee compatibility between the two anyway.
Yes, that's what we need anyway. That's why we can split stuff. But the
discussion didn't start with the shell, but with an ftp server.
The majority of user mode applications are all third
party. Paint and Calc
were done by people that frequent the ROS forum while the rest I'm pretty
sure are from Wine. A lot of the user mode DLLs are also from Wine, as I
mentioned above, and Wine is doing their own stuff development wise.
The only thing that I can think of which could legitimately be split off
would be the explorer shell, but it literally is of no use to anyone except
us, since it's essentially duplicating the old Windows 2000 style. It's not
radical or experimental or whatever, it is just a clone of the interface.
Quite frankly, there really aren't many ways to actually split ROS. The
major components all are tied to each other and the smaller/other stuff
either are already completely third party or were done because no one else
out there was interested in it but we needed it.
It's not about whether
it's 3rd party, it's about if and where we put it
in our sources.
As an example: If I work on some stuff in win32k, I would like to
totally ignore all changes to the kernel or to wine dlls or to the
networking stuff. Because it doesn't affect my work. So I can do as
developers often seem to do: not update my local copy for weeks. That
works as long as you are the only dev working on a certain component.
But then another dev commits to that component or a related part. Say
someone changes a bunch of stuff in user32. I can't ignore that any
longer. I need to get my local copy in sync. And with this I am forced
to sync the whole of trunk. Including dozens of wine syncs, rbuild
changes, header changes, kernel changes, network changes, ftpservers....
forcing a full rebuild. Always. What for?
Every component added to trunk/reactos is one component more that gets
changed or synced and forces me to rebuild things, wasting my and every
other developers and the buildslaves time. That is why I'd like to keep
it small. I'd love to see a "MinRos" folder that includes only the core
and an independend win32core folder and a wine folder and a network
folder and an apps folder. I am not talking about splitting the project,
only about source reorganisation to reflect the actual
layers/dependencies instead of putting all modules that happen to have
the same file format into the same folder no matter what they are used for.
BTW: guess what I am currently doing. Compiling, because I wanted to
apply a small patch to win32k and a few changes to win32k/user32 forced
me to update and rebuild everything.
Regards,
Timo
PS: ReactOS is c0re! ;)