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! ;)