User Ideas for ReactOS
From time to time, users propose ideas for ReactOS. Here's a place to put them. We might never use most of them, but here is a place to showcase them.
- 1 Base MSHTML renderer on Webkit or Blink
- 2 Bidirectional firewall
- 3 DirectX 10, 11, 12, Vulkan, future renderers
- 4 Flatten registry writes
- 5 Host Outreachy & Rails Girls
- 6 Modern hardware compatibility
- 7 Registry firewall
- 8 "Remove" CSRSS
- 9 Security access for apps
- 10 Segregate mostly read-only files from frequently updated files
- 11 Use the GPU as a computational resource
- 12 Fine tune ReactOS for specific hardware
This would be beneficial for not only ReactOS but Windows too. Then ANY browser can take advantage of the fastest renderer code, even very tiny ones such as OffByOne or Dillo, perhaps making them faster than Chrome. Currently, there are no plans to do this since ReactOS currently uses Gecko. Even that is likely better than Trident as used by Windows XP/2003. Now if someone were to write such a wrapper for Webkit or Blink, perhaps to use in Windows, and maybe use Gecko code to fill in what's missing that mshtml.dll might need, then this idea might be worth consideration.
Windows XP only has an inbound firewall, while Windows 7 has a bidirectional firewall. Not everyone understands the value of an outbound firewall. An inbound firewall protects from inbound attacks such as hackers, unexpected incoming packets, and programs with backdoors loading things into your system. An outbound firewall helps reduce the chances of compounding the problems of malware that you already have. It could help keep your PC from leaking sensitive information about you and from attacking other machines. As a second-line defense, it doesn't keep you from being hacked or infected, but it can help minimize the impact.
DirectX 10, 11, 12, Vulkan, future renderers
Windows XP is currently only capable of running DirectX 9 and OpenGL. Many games are now using more modern renders, like DirectX 11, 12 and Vulkan. Using the latest rendering techniques will attract a lot of gamers to ReactOS since gaming is a major reason why people use Windows.
Flatten registry writes
This involves using a small area of memory to track the last so many unique writes to the registry. The idea is to check pending writes against this list and to not write again if any identical transactions are there. That way, redundant requests are acknowledged without any further action. This helps prevent unnecessary disk accesses. That may help preserve the life of NAND-based SSD drives. It might also reduce hard drive contention and slightly speed up overall disk I/O. This doesn't have to be too fancy or too large.
The behavior of the Magic Jack VOIP device is an example of where this feature could be useful. At least some versions of the softphone software will hammer the registry with the exact same things at least once every three seconds.
A clarification is that this is not really a cache. Unique writes are allowed, but redundant ones are not. It is more of a transaction log that is checked before writing, thus preventing useless writes.
As for disadvantages, in a rare case, if there is a way the registry is somehow modified by something other than ReactOS while it is being used, then future registry writes might not overwrite what was changed. At the least, it could take a while before the tracking gets flushed and an additional write could be considered appropriate. However, this should not be possible under normal conditions, since you'd expect ROS to have exclusive access to the registry. The other disadvantage would be the CPU time and memory access overhead needed to check each transaction against recently previous ones.
Host Outreachy & Rails Girls
Outreachy is an internship program that is very similar to GSoC. However, it is a twice a year program and is offered to members of specific minority groups -- mainly women, transgender folks, and those with African, Asian, Pacific Islander or Aboriginal descent.
While at least one user raised concerns in the forums about the possible political implications of involvement in such programs, it is not conceivable as to how that would be any more of an issue for us than just participating in GSoC. Yes, there are clear agendas behind the motivations of these programs in terms of the organizers, but that doesn't mean that the interns would share such attitudes. More than likely, they just want to code and get the skills needed to find good jobs. So my (PurpleGurl (talk)) proposal is to try it at least once. If the completed work is not suitable or more time is spent arguing or being disruptive, then we could simply not apply to participate again. However, if they turn out great work, then who they are wouldn't matter. If this works, we could have more benefit than what GSOC currently provides and have a greater chance of acceptance into at least 1 program per year.
Modern hardware compatibility
Windows XP lacks a lot of compatibility with newer hardware, such as NVMe support for SSDs, trim support for SSDs, and AMD's new Ryzen processors. Without modern hardware compatibility, we exclude many users.
This means monitoring the most abused registry hooks. For instance, the user would get a prompt if something tries to write to the Run key in the registry unexpectedly. This behavior could be disabled in the control panel (and/or a registry key or Services console). This could be taken further by automatically adding the blocked items to a blacklist. Taking that even further, there could be an option to automatically block a given key for the rest of the session without further prompting. That way, if loaded malware rapidly attempts to add the unwanted keys, then this feature won't render the system useless for the rest of the session. In that case, it might be wise to add a prompt to reboot if a process already in memory keeps adding itself.
This could be combined with the registry access flattening idea. Instead of preventing redundant writes, the presence of the bad key in the flattening list or an unwanted keys list would prevent it from being written at all.
Due to debate, length, untenability, and obsolescence, this idea has been moved to it's own section. Our kernel needs to behave as close to Windows as possible.
Security access for apps
Make the properties app to where it can change permission to access the functions of reading and writing files, Internet access, and even the registry. This approach allows users to restrict access to questionable applications without additional software and be truly protected (how on Sandboxie app). [CORE-11548]
Segregate mostly read-only files from frequently updated files
This is a way to get some gains from using SSD drives while helping to extend their lives. Files that are only occasionally written to can go on the SSD while frequently updated files can go on a mechanical hard drive. You can manually do this in Windows already if you copy the files, play with the registry locations, and change some settings. What would be nice would be a wizard to automate this. That would allow you to keep things like registry hives, temp files, cookies, the swap file, and search indexes off of the SSD drive and do so in a rather safe manner. However, it is possible that Optane and similar NV memory will become mainstream before anyone considers this, thus making this proposal less attractive.
Use the GPU as a computational resource
Modern PCs use video cards which have computational abilities. There are also coprocessor cards that are similar to video cards in that they have hundreds, if not thousands of shader engines, though they are not used to process graphics. It would be nice if such abilities were recognized and made available for more general computing tasks. For instance, what if the kernel needs floating point operations? So far, the proposal has been to use an FP emulator for this, due to it being problematic to switch states and this requiring high overhead. Using emulation is also costly and slow, though less likely to cause race conditions under these circumstances. Now, what if that could be offloaded to the GPU or to a supercomputing adapter if one exists?
Writing such code will likely be tricky as there are multiple standards and the operations are greatly different from what a general purpose CPU would provide. You'd likely need your own GPU kernel and some sort of abstraction layer. Then you might need alternative versions of APIs and some sort of scheduler or arbiter to make sure the most appropriate device is chosen for that moment. Other disadvantages would be increased power consumption, heat, and noise (from cooling fans). Often, using these computational abilities requires entering the video' card's high-performance mode.
Fine tune ReactOS for specific hardware
It seems like writing a number of highly tuned kernel files and other files for specific hardware would be favorable to squeeze every ounce of performance out of ReactOS. That way, there won't be any code that your machine doesn't need. Trying to be compatible with everything at once can sacrifice performance. One way to implement such alternate files could be to have a wizard to configure this feature and copy in the necessary files.
Common objections raised are that this could increase problems migrating to a new system and possibly render the machine unbootable if the wrong set of alternative files get used. However, a way around this would be to always include the standard files and implement a way to fall back to those. We could make the Safe Mode always use the generic set of files. That would allow you to change to a different set of files since you could then boot into Safe Mode and access the wizard to change to the generic set or a more appropriate set. Another idea would be to allow the user to switch to the default set by using the F8 boot options. There could be a few sanity tests added early in the boot process in case glaring incompatibilities present themselves or the alternative files are missing (such as a corrupted installation or copying certain kernel parts into an actual 2003 Server installation). Then the default files would be used.