Just a simplification idea

[a_flj_]

First off, apologies in advance if I sound rude or offensive (since I give advice on a project I didn't contribute to and I don't know very well) - I don't mean to.

To speed things up and get traction, you may be able to play with priorities. Make things like non-critical features of critical apps and non-critical apps low priority, and critical issues such as USB support, SATA support, extensive and complex partitioning and disk format support, Win32Api completeness and compatibility, driver compatibility etc. high priority. (I may be wrong and stupid, but it didn't seem to me that this is how it's done now, while looking at the critical tasks for milestones.) One could copy an explorer from an existing Windows installation or run Windows commander, as long as he can reliably install drivers and run 3rd party apps on ReactOS, but no matter how nice and feature-complete the ReactOS Explorer would be, if the graphics driver for his system doesn't install on ReactOS, he can't use it. Once apps can be deployed reliably, users would start to use ReactOS and spread the word, which would mean more traction and possibly more developers/contributors.

[Z98]

The roadmap doesn't give a very complete picture. It indicates a few goals, but does not at all indicate everything that must be accomplished to achieve those goals. And I can't help but notice that you only picked a single thing out of the roadmap that you believe to be of minor priority. Anyway, let's consider what is needed to get the new explorer shell running. First is fixing various parts related to drawing in the Win32 libraries. Then there is completing the shell32 library and COM interface that shell32 relies on. Then there are various window management components that also need to be fixed/written. So the stated desire may be, "get new explorer" or whatever, but the effect is "finish a large component of the Win32 subsystem."

With respect to your idea of prioritization, the people who are capable of working on what you call high priority parts are already working on them. The people working around the edges are often those in the process of learning about the components they're working on. Tossing them onto a "high priority" piece won't speed up development since they wouldn't know what to do. Someone working in the kernel may not have a clue as to what to do in Win32, and vice versa. And all of the developers are working on some piece of ROS that needs to get fixed to make the system functional. If people want to work on a higher level component, we're perfectly happy to have them help. Having people pick up easier projects can only free up more time for other developers to deal with low level issues, if the people know what they're doing. Trying to force everyone to work on something that is ostensibly "high priority" is not going to work, especially if they have no idea how the "high priority" component works in the first place.

[mrugiero]

The roadmap doesn't give a very complete picture. It indicates a few goals, but does not at all indicate everything that must be accomplished to achieve those goals. And I can't help but notice that you only picked a single thing out of the roadmap that you believe to be of minor priority. Anyway, let's consider what is needed to get the new explorer shell running. First is fixing various parts related to drawing in the Win32 libraries. Then there is completing the shell32 library and COM interface that shell32 relies on. Then there are various window management components that also need to be fixed/written. So the stated desire may be, "get new explorer" or whatever, but the effect is "finish a large component of the Win32 subsystem."

With respect to your idea of prioritization, the people who are capable of working on what you call high priority parts are already working on them. The people working around the edges are often those in the process of learning about the components they're working on. Tossing them onto a "high priority" piece won't speed up development since they wouldn't know what to do. Someone working in the kernel may not have a clue as to what to do in Win32, and vice versa. And all of the developers are working on some piece of ROS that needs to get fixed to make the system functional. If people want to work on a higher level component, we're perfectly happy to have them help. Having people pick up easier projects can only free up more time for other developers to deal with low level issues, if the people know what they're doing. Trying to force everyone to work on something that is ostensibly "high priority" is not going to work, especially if they have no idea how the "high priority" component works in the first place.

AND (I think you forgot to remember him) using explorer from MS-Windows is not legal...

[Haos]

To speed things up and get traction, you may be able to play with priorities. Make things like non-critical features of critical apps and non-critical apps low priority, and critical issues such as USB support, SATA support, extensive and complex partitioning and disk format support, Win32Api completeness and compatibility, driver compatibility etc. high priority.

I do agree that those tasks are quite important for ROS. Could you point then things for what we should lower the priority?

[PurpleGurl]

I think the comment about copying Explorer was limited to the end users who wanted to do so, who presumably already own a copy of Windows. If Reactos did it, or an end user who doesn't own any legal copies of Windows, then I can see that as obviously illegal. What the end user does on their own machine is really on them.

As for the topic at hand, I think the developers have said it well. Those who can code the hard stuff are already doing so, and those who cannot are doing other things.

The 2 main things I'd like to see are improved USB driver support (Reactos crashes on mine if USB 2.x support is enabled in the CMOS, and legacy USB support is erratic and buggy under Reactos), and NTFS support. It is funny that they claim the USBDriver.sys crash bugs were fixed a couple of years ago or whenever, yet I cannot load Reactos on real hardware without disabling USB 2.x.

I would love to see SMP or multi-core support too. Sure, Reactos is more robust than Windows, but imagine how it would run if multi-core processors were fully implemented... There is no such thing as too much performance (or too much hard drive space). Even if Reactos is written well, it doesn't mean that the end user applications are.