Any more ideas for improvements or things that could make ROS outperform Windows? I mean deliberately. Yes, in some ways, we already outperform Windows. Part of that is because so much is missing. But once more is added, stability and compatibility will increase, but performance may decline.
Now, I've already discussed the compatibility thing. On one hand, the most important aspects are 100% driver and application compatibility. The alternative kernel ideas show there may be room to optimize things internally and make things more efficient. However, it is hard at this point to know what truly won't affect compatibility. So right now, they are doing things as close to Windows as they know, even in areas that could safely be deviated. Then at the same time, I imagine there are parts where it is critical to be like Windows but we aren't because we lack that data and knowledge. So, at this point, it is probably best to stick to duplicating Windows behavior, even in things that don't directly involve drivers or software. Once the foundation is laid, then varying things and seeing how far things can be optimized might become more attractive. To put it short, we just want it to work and do so reliably for now.
Now, if things can be done more directly with less code, that can go a long way towards being reliable so long as too many shortcuts are not taken. When you start getting into too many entry points for things, self-modifying code (except where it cannot be done any other way), using non-standard opcodes (unless using multiple code paths and only use the nonstandard commands on the hardware that can use it), then things become messy and cause problems such as race conditions. So just because you can save bytes doesn't mean you should.
It is interesting that Wine on Linux can outperform Windows in a number of cases. Apparently, there is less overhead in the kernel or the kernel is more efficient. One person it seems had blamed the whole console server runtime subsystem. I don't know if that is where the weakness with Windows is over Linux, but it is one place to start.
Then there is the hardware thing. There is a problem with having lots of different equipment that shares a lot of the same standards. There is no way to write one piece of code and tune it for just one type of machine. With different motherboards, socket configurations, CPU types, and CPU brands, you really only have 2 choices. You either write general purpose code to support most of everything, or you write different snippets for different hardware. Obviously it will run better if you can write for each variation in hardware. However, there is extreme cost, since it requires more labor and storage space. That is what so many don't like about Windows installation diskettes and CDs/DVDs, as they used to be full of many drivers for obsolete printers and modems, among other things.
If you go with multiple code paths tuned for different machines, then you have to make some parts more complex to decide which alternate code path is run. Either you'd do that in the kernel, perhaps during initialization, and determine all that each time you bring up the machine, or you would do so in the installer. However, if you do so in the installer, then you have the problem of portability. I mean, you fry the motherboard, for instance, and replace it and hope ReactOS or whatever still runs. If the installer tuned the files and code paths used, then you could be stuck not being able to boot if you have to use another motherboard that's a little different. Like if you replace an Intel board with AMD or vice versa, there would be a problem if your installation required opcodes that only one of the CPUs involved has. So it is a choice between mediocre for everyone or it only working for some and it working well. Obviously Windows has room for both approaches. There are basic platform drivers that work for everyone for the most part, and if they need more performance or more capabilities, then there are custom drivers -- and most manufacturers have their own drivers. And the way Windows is, if you are missing certain drivers, you generally can still use the machine. If some obscure built-in sound card cannot find its driver, then no harm other than not being able to hear anything through it. Then of course, you can always install such a board if you have a slot. Or you can go to one of the driver repository sites (and risk breaking copyright, corrupting things with the wrong driver, or picking up malware).