Difference between revisions of "User Ideas for ReactOS"

From ReactOS Wiki
Jump to: navigation, search
m (Future hardware compatibility: -- Rename section since the intention is clearly contemporary hardware, not yet to be invented hardware.)
m (Host Outreachy & Rails Girls: Brevity)
 
(34 intermediate revisions by 5 users not shown)
Line 2: Line 2:
  
 
==Base MSHTML renderer on Webkit or Blink==
 
==Base MSHTML renderer on Webkit or Blink==
This would be beneficial for not only us, 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 we currently use Gecko. Even that is likely better than Trident as used by Windows XP/2003. Now if someone else 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 we might consider it.
+
This would benefit both ReactOS and Windows XP/2003. Then ANY browser can use the fastest renderer code, even very tiny ones such as OffByOne or Dillo, perhaps making them faster than Chrome. There are currently no plans to do this since ReactOS uses Gecko, for now. Even that's likely better than Trident as used by Windows XP/2003. Now, if someone were to write such a wrapper for Webkit or Blink and maybe use Gecko code to fill in what's missing that mshtml.dll might need, then this idea might be considered.
  
 
==Bidirectional firewall==
 
==Bidirectional firewall==
Windows XP only has an inbound firewall, while Windows 7 has a bidirectional firewall. A lot of people don't understand the value of an outbound firewall. The inbound one is what protects you from inbound attacks like hackers, unexpected incoming packets, and programs with backdoors loading things into your system. An outbound one is for just in case you already have malware, to keep from compounding the problem. That would help keep your PC from leaking sensitive information about you and from attacking other machines. It is a second-line defense. It doesn't keep you from being hacked or infected, but can help minimize the impact.
+
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==
 
==DirectX 10, 11, 12, Vulkan, future renderers==
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.
+
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==
 
==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 they are here. So any redundant requests are acknowledged without any further action. This helps prevent unnecessary disk accesses. That will likely help preserve the life of NAND-based SSD drives and possibly reduce hard drive contention and slightly speed up overall disk I/O.
+
This uses 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 identical transactions again. Redundant requests are acknowledged without further action. This helps prevent unnecessary drive 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. This is more of a transaction log than a cache. Unique writes are allowed and dispatched immediately, but redundant ones are not.
  
==Modern hardware compatibility==
+
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 hammer the registry with the exact same things at least once every three seconds.
Windows XP lacks a lot of future hardware compatibility, such as NVMe support for SSDs, trim support for SSDs, and AMD's new Ryzen processors. Without modern hardware compatibility, we exclude a big portion of Windows users.
+
 
 +
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 would 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==
 +
[https://www.gnome.org/outreachy/ Outreachy] is an internship program that is very similar to GSoC. However, it is a twice a year program and is offered mainly to women, transgender folks, and those with African, Asian, Pacific Islander or Aboriginal descent.  
  
==Registry firewall==
+
[http://railsgirls.com/ Rails Girls] offers the [https://railsgirlssummerofcode.org/ Rails Girls Summer of Code]. The goals are similar to those of Outreachy, but it is geared more towards women and gender non-binary folks.
This means monitoring the most abused registry hooks. For instance, if something tries to write to the Run key in the registry unexpectedly, the user would get a prompt. This behavior could be turned off 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 keys back, then our feature won't render the system useless for the rest of the session.  
 
  
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 would prevent it from being written at all.
+
While at least one user raised concerns in the forums about the possible political implications of involvement in such programs, it might not be any more of an issue for us than 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 [[User:PurpleGurl|PurpleGurl's]] 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, it wouldn't matter who they are if they turn out great work. If this works, this could benefit us more than just having GOC, with a greater chance of acceptance into at least 1 program per year.
  
==Remove CSRSS==
+
==Modern hardware compatibility==
This is a rather radical suggestion that came from KJK::Hyperion. It is doubtful this would be considered. However, if someone were to develop this for an existing Windows install and demonstrate that it won't adversely affect driver or application compatibility, then it might be worthy of consideration.
+
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.
  
Get rid of the CSRSS monstrosity for good. Forget the NT-compatible design: it's half-baked and ultimately broken. It's a memory hog, it's inflexible, it duplicates kernel data structures for no good reason, and it's the single worst bottleneck of process startup time. Its sole presence makes running user-mode processes and threads from kernel mode (piece of cake on UNIX) a nightmare. Console handles not being valid handles is plain stupid and introduces all sorts of limitations and baroque workarounds. If win32k.sys needs a process to map the shared data in read-write mode and run worker threads (the only good reason to have CSRSS still around), it can still fork the System process. CSRSS as a hard error handler is laughable: it just spams all desktops with the stupid stay-on-top message box we all know - even the MS-DOS hard error handler was friendlier than that. CSRSS as a debug proxy server is useless - LPC-based debugging is a thing of the past. Really, you can't do half efforts at a microkernel: it's a microkernel or it's not.
+
==Registry firewall==
 +
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.
  
Instead of the csrss-style architecture, the consoles will become true devices. The console driver will still be just a bridge between client applications and a server, but this shouldn't be underestimated. The slave side requires a server process, because it's just better, and if said server process can be user-defined (plain impossible with CSRSS - if not for anything else, no way you could signal a console client from a console server running under a different account), it's even better. Using I/O for inter-process communication *may* be even less efficient than LPC, but there's the big advantage that I/O is exponentially easier to use in kernel-mode, and supporting a kernel-mode console server is vital (imagine the headless server scenario. A simple kernel-mode console server is efficient - cutting on all the fancy user-friendliness that a headless server rarely needs - and removes the need for win32k.sys, while still exposing a decently usable console). Console handles, as a side effect, will be true, full-fledged handles, with correct handle semantics. The RunAs command always opens a new console because console handles aren't true handles (see previous paragraph). True handles mean that, when switching from text-only mode to GUI, the text-mode console server could spawn a child process (the GUI console server) and hand over the ownership of the slave side to it by simply duplicating its handle - thus preserving all the consoles you opened in text mode. True handles mean you could attach to any console and write to it - message broadcasts in text mode anyone? If this sounds a bit like UNIX, then that's the point.
+
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.
  
Preserving the old console control semantics (creating a dispatcher thread that goes through the list of registered handlers) won't be hard once you remove the requirement for threads to be registered with CSRSS: you just create the thread. End of the story. Threads created from outside kernel32.dll will lack the default exception handler, so what? If you're really interested in that, you write it by yourself - the default exception filter does all the magic, and it's a public function. The real point is that you can happily call Win32 functions (and - especially - write to consoles) with no special initialization steps. Let's not go into what unholy steps are to be taken on Windows to trick CSRSS into accepting a Win32 process that wasn't started, in turn, from a Win32 process (let's just say it involves a disassembler - in your code, not as a development tool - and a lot of testing). Really, ReactOS will be a much better place without CSRSS.
+
=="Remove" CSRSS==
 +
Due to debate, length, untenability, and obsolescence, this idea has been moved to [[Remove CSRSS|it's own section]]. Our kernel needs to behave as closely to Windows as possible.
  
No CSRSS means that nothing must be started before you can start anything else. No CSRSS, nor SMSS: If I want the kernel to run a batch file at startup instead of SMSS, I should be able to - in fact, a boot-time script should be the *default*. Boot time activities, such as loading the well known DLLs, creating the swap files, saving the crash dump to a file, etc. will be assigned to startup scripts and applications, to allow a better granularity of configuration. The whole concept of a "boot verification program" will be obsolete. You'll be able to decrypt the SAM with a custom procedure, instead of being limited to a measly three options (see SysKey), none of which sounds all that exciting (what if you want to use SHA-1 + AES? what if you want to use a smart card? etc.). Winlogon and the SCM will be two normal user-mode applications, with nothing really special about them: you'll be able to start and stop them at will, or kill them if they misbehave (all too common for such a complex beast as Winlogon) - or not run them at all. The setup program could even be a Win32 app! To whomever is currently developing it: imagine being able to debug USetup in Visual Studio (or your favorite debugger/IDE), instead of... whatever you're using now. You could use Format and Fdisk (maybe implementing a console server in USetup to better control them), instead of duplicating their features inside USetup, and the future transition to a GUI installer would be seamless. Also, phasing out CSRSS alone could be the single biggest step towards the mythical one-phase setup.
+
==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). [https://jira.reactos.org/browse/CORE-11548 [CORE-11548<nowiki>]</nowiki>]
  
Hard errors will be handled per-thread, with callback semantics, like they're meant to be (except those with an action of ShutdownSystem, that are meant to cause a controlled BSOD). The PEB has room for several callback pointers: it won't hurt to reserve one for hard errors, and an extra one called by win32k.sys to convert a thread into a GUI thread, that could be handled in user32.dll by, among other things, replacing the hard error handler with one that shows a message box (possibly thread-modal, certainly not broadcasted). For those unsure: yes, it has to be a callback - it's vital for out ntdll!Ki* symbols to strictly match those of Windows, because the awareness of the hidden, locked potential of the Native layer is growing, and it would be gratuitous to change well-known stuff "just because". Having few, predictable entry points from which execution can resume is good design, too: just look at all the pains the Valgrind team is going through to catch all signals, lacking Linux well-defined points at which execution resumes (not counting the NtContinue and NtSetContextThread anomalies, Windows has exactly four - namely, user-mode APC, callback, exception and system exception. Five, if we count LdrInitializeThunk in).
+
==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.
  
CSRSS as a host for win32k.sys kernel-mode worker threads is useless. It's documented in "Inside Microsoft Windows 2000". Try to terminate CSRSS, just for fun: observe how the GUI freezes. Win32k.sys can either exploit the under-used System process (it typically has just less than 500 KBs of virtual memory), or fork it with PsCreateSystemProcess.
+
==Use the GPU as a computational resource==
 +
Modern PCs use video cards that 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 costly and slow, though less likely to cause race conditions under these circumstances. Perhaps it could be offloaded to the GPU or a supercomputing adapter if one exists.
  
CSRSS as a debugging proxy server is an outdated concept: Windows XP and later have abandoned the old LPC-based debugging API in favor of a more traditional object-oriented native API, so let's do exactly the same.
+
Writing such code will likely be tricky as there are multiple standards and the operations are quite different from what a general-purpose CPU provides. 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 choose the most appropriate device for that moment. Other disadvantages would be increased power consumption, heat, and noise (from cooling fans). Often, using these computational abilities activates the video card's high-performance mode.
  
Removing CSRSS will give you backward *and* forward compatibility. "Forward" because you'll be able to use Windows applications in contexts where it used to be impossible. Moving the consoles to a driver just begs to be done, even if it's difficult, and it's the key to unlock a better Windows.
+
==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.  
  
==Segregate mostly read files from frequently updated 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.
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 the mechanical hard drive. You can manually do this in Windows 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 way, you can 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.
 
  
==Use the GPU as a computational resource==
+
[[Category:Community]]
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, but 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? As for writing such code, it will likely be tricky as there are multiple standards and the operations are greatly different than what a general purpose CPU would provide. You'd likely need some sort of abstraction layer and your own GPU kernel. 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.
+
[[Category:Ideas]]

Latest revision as of 21:21, 3 May 2020

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.

Base MSHTML renderer on Webkit or Blink

This would benefit both ReactOS and Windows XP/2003. Then ANY browser can use the fastest renderer code, even very tiny ones such as OffByOne or Dillo, perhaps making them faster than Chrome. There are currently no plans to do this since ReactOS uses Gecko, for now. Even that's likely better than Trident as used by Windows XP/2003. Now, if someone were to write such a wrapper for Webkit or Blink and maybe use Gecko code to fill in what's missing that mshtml.dll might need, then this idea might be considered.

Bidirectional firewall

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 uses 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 identical transactions again. Redundant requests are acknowledged without further action. This helps prevent unnecessary drive 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. This is more of a transaction log than a cache. Unique writes are allowed and dispatched immediately, but redundant ones are not.

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 hammer the registry with the exact same things at least once every three seconds.

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 would 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 mainly to women, transgender folks, and those with African, Asian, Pacific Islander or Aboriginal descent.

Rails Girls offers the Rails Girls Summer of Code. The goals are similar to those of Outreachy, but it is geared more towards women and gender non-binary folks.

While at least one user raised concerns in the forums about the possible political implications of involvement in such programs, it might not be any more of an issue for us than 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 PurpleGurl's 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, it wouldn't matter who they are if they turn out great work. If this works, this could benefit us more than just having GOC, with 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.

Registry firewall

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.

"Remove" CSRSS

Due to debate, length, untenability, and obsolescence, this idea has been moved to it's own section. Our kernel needs to behave as closely 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 that 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 costly and slow, though less likely to cause race conditions under these circumstances. Perhaps it could be offloaded to the GPU or a supercomputing adapter if one exists.

Writing such code will likely be tricky as there are multiple standards and the operations are quite different from what a general-purpose CPU provides. 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 choose the most appropriate device for that moment. Other disadvantages would be increased power consumption, heat, and noise (from cooling fans). Often, using these computational abilities activates 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.