Back to Website

User Ideas for ReactOS

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

User Ideas for ReactOS

Postby PurpleGurl » Wed Apr 19, 2017 5:06 am

Since certain ideas keep coming up, I started a wiki page on it.

https://www.reactos.org/wiki/User_Ideas_for_ReactOS

That way, there is a centralized place to list them.
PurpleGurl
 
Posts: 1493
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: User Ideas for ReactOS

Postby ROCKNROLLKID » Wed Apr 19, 2017 6:38 am

I added 2 points myself, DirectX 10, 11, 12, Vulkan, future and future hardware compatibility.

About making a 2-way firewall: Yes it would be nice, but only if you added notifications for outbound rules. Otherwise, if you make it just like Windows does, it's pretty pointless because in Windows 7 and also Windows 10, it's not very easy to make outbound rules.

I guess a good thing is ReactOS doesn't need stuff like DEP/exploit mitigation found in Windows 10 (DEP since XP), because with ReactOS being open-source and as long as all the developers keep the code as clean as possible, we shouldn't have too many issues with exploits/vulnerabilities.

There are some other things I would like to see, but not really something that needs to be done anytime soon, like maybe a game mode similar to the one that was added in the creators update for Windows 10, and maybe some HOST file improvements, like support for sub-domains and IP addresses.

Maybe a good idea for the wiki page is to section them off, like make a section for top priority ones where the developers should concentrate on first, then moderate priority where they are good ideas but can be done later, then low priority ones where people would like to see stuff, but doesn't have to be done anytime soon.
ROCKNROLLKID
 
Posts: 178
Joined: Mon Oct 17, 2016 3:19 am

Re: User Ideas for ReactOS

Postby PurpleGurl » Wed Apr 19, 2017 8:29 am

Excellent suggestions! Yes, this is a work in progress. I was sorting by ABC order, but yes, sections sounds good. The sections can be by priority and/or feasibility.

Obviously, Webkit/Blink-based MSHTML is more of a wish, since there's already a Gecko wrapper which is sufficient. But if a 3rd party were to use Blink code to create their own mshtml.dll that works well in Windows, then the idea may be more appealing.

Then the idea of totally reworking the kernel (removing CSRSS, eliminating LPC communication, converting consoles to drivers, etc.) would go more into the lowest priority as well. I mean, if some hobbyists want to do it as proof of concept, nobody is stopping them, but right now, we are after more compatibility and stability. It can be argued that it wouldn't violate our primary goals, since as long as the driver model and application compatibility is the same, then the project aims are being achieved. At the same time, it is simpler to do things closer to Windows even when one doesn't have to, since that can reduce a lot of fumbling with the code later. Then if they later want to use a more ROS-specific or more Unix-like approach, it will be after having already tried a proven way that's already known to work. That's better than assuming something won't adversely affect compatibility, having hard to diagnose bugs, and then realizing a glaring wrong assumption is the cause.

Personally, I believe we should use DEP like even XP uses. The main blocker there is the PAE support. Microsoft enabled PAE, not to use the 4 selector lines of the CPU (making a 32-bit CPU act more like it has 36 address lines), but due to the hardware DEP support that is only available in PAE mode. Just because we might have more eyes on the code doesn't mean all buffer overrun/underrun risk is eliminated. It would be better to have both types of security.
PurpleGurl
 
Posts: 1493
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: User Ideas for ReactOS

Postby dizt3mp3r » Wed Apr 19, 2017 8:51 pm

PurpleGurl wrote:Since certain ideas keep coming up, I started a wiki page on it.

https://www.reactos.org/wiki/User_Ideas_for_ReactOS

That way, there is a centralized place to list them.


I like this wiki page, it is a good idea.

Bi-directional firewall? Not really a priority. There are plenty of good working free/abandonware firewalls for XP including Sygate that users can install as per their preference and there are open source firewalls that the team could recommend.

DirectX 10, 11, 12, Vulkan, future renderers and Modern hardware compatibility are the other priorities as far as I am concerned - but of course all this is all rather academic until ReactOS achieves stability and usability.

Top priority should be a steampunk interface. Obviously.
Last edited by dizt3mp3r on Wed Apr 19, 2017 11:00 pm, edited 3 times in total.
dizt3mp3r
 
Posts: 884
Joined: Mon Jun 14, 2010 5:54 pm

Re: User Ideas for ReactOS

Postby ROCKNROLLKID » Wed Apr 19, 2017 10:21 pm

Well ya, ReactOS can still get buffer overruns/vulnerabilities/etc. I guess there is no harm to having DEP added in.

We should probably discuss what ideas should be more top priority and what ideas are more low priority. I think Remove CSRSS, bidirectional firewall, and Webkit/Blink should be low priority, as well as my ideas for the host file and game mode, and stuff like future hardware compatability, directx10-12, Vulkan, future renders, registry firewall, and flatten registry writes should be more top priority. The rest could probably be in between or something.
ROCKNROLLKID
 
Posts: 178
Joined: Mon Oct 17, 2016 3:19 am

Re: User Ideas for ReactOS

Postby PurpleGurl » Thu Apr 20, 2017 12:16 am

My registry idea is not high priority. I mean, it might be nice, but is not necessary, and I am not how feasible it would be or how it would work practically speaking. The segregation/movement of frequently written data would be easier and have more immediate gains. So if you want to do a hybrid HDD install, where you put the most written data to older but more reliable types of drives while still getting higher speed reads, then it would be nice to have a wizard to set that up. It can change whatever settings and registry keys involved as well as copy things to the new locations. Then you'd reboot. Then there could also be options in the utility to put things back to default (like if you are reconfiguring or replacing drives).

The graphics things might need to wait until we change compatibility targets. That would be simpler than trying to write forward compatibility shims. The problem there is the mix and match API problem. If the software is older, it might not know to look for version 10+, if it it newer, it might get confused if it finds some Vista/7+ APIs . We don't want to break things to force it to run games that XP won't support.

As for Steampunk, well, couldn't that be a themes pack?
PurpleGurl
 
Posts: 1493
Joined: Fri Aug 07, 2009 5:11 am
Location: USA


Re: User Ideas for ReactOS

Postby PurpleGurl » Thu Apr 20, 2017 3:18 am

Yes, I know, but can't a person get a joke and also take it at face value at the same time? Or is that now against the rules? ;)
PurpleGurl
 
Posts: 1493
Joined: Fri Aug 07, 2009 5:11 am
Location: USA


Re: User Ideas for ReactOS

Postby justincase » Thu Apr 20, 2017 6:49 pm

dizt3mp3r wrote:let's make the steampunk theme priority one.
W00T!!
I reserve the right to completely ignore any portion of any post if I deem it not constructive and/or likely to cause the discussion to degenerate.
justincase
 
Posts: 324
Joined: Sat Nov 15, 2008 4:13 pm

Re: User Ideas for ReactOS

Postby PurpleGurl » Thu Apr 20, 2017 7:48 pm

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).
PurpleGurl
 
Posts: 1493
Joined: Fri Aug 07, 2009 5:11 am
Location: USA


Return to General Discussion and Feedback

Who is online

Users browsing this forum: No registered users and 17 guests