diff --git a/FAQ.mediawiki b/FAQ.mediawiki
index 5c63786..abefcca 100644
--- a/FAQ.mediawiki
+++ b/FAQ.mediawiki
@@ -28,9 +28,9 @@ There are a few issues to be taken into account with with pre-packaged applicati
 
 1. Using a pre-packaged portable app introduces another 3rd party relationship. Once the original author releases a new version of the software,  somebody has to notice and create a new portable app package. This can introduce delays in the update process as PhoenixPE has no control over when or if the package maintainer updates the portable app for the new version. It also leaves us vulnerable to the package maintainers opinion/idea of what a portable app package includes and what features are available.
 
-2. Disk Space. In the case where pre-packaged portable apps are useful (ie. its not a standalone app that is by nature portable on it's own), the application files are compressed into a self extracting installer, then extracted to a temp directory at runtime. This can pose some challenges in a WinPE environment because temporary directories are located either in the file system overlay (FBWF/WinPE Cache), or in a RAM Drive. Both typically have very limited space available. FBWF/WinPE Cache is typically 1GB or less and needs to be available to the operating system for it's activities and temp files, and RAM Drives are likewise only configured to use a fraction (10% or so) of the available RAM. Depending on the extracted size of the portable app package and the number of portable app packages a user runs in a given session, this can exhaust temp disk space rather quickly. There are to many trade offs to consider. Make the RAM drive too large and if the user doesn't have enough RAM the drive creation either fails, or it succeeds and there is not enough RAM left for the OS or other applications. Make the RAM drive too small and space is exhausted after only a couple of apps are launched. Either scenario is unacceptable to the end user, who most likely does not understand they need to anticipate and calculate extracted size, physical RAM available on every computer they plan to boot, frequency of use, and the number and disk space requirements of other apps/temp space/etc. in the first place, and can't be relied upon to configure the environment correctly at build time.
+2. Disk Space. In some cases the application files are compressed into a self extracting installer (SFX), then extracted to a temp directory at runtime. This can pose some challenges in a WinPE environment because temporary directories are located either in the file system overlay (FBWF/WinPE Cache), or in a RAM Drive. Both typically have very limited space available. FBWF/WinPE Cache is typically 1GB or less and needs to be available to the operating system for it's activities and temp files, and RAM Drives are likewise only configured to use a fraction (10% or so) of the available RAM. Depending on the extracted size of the portable app package and the number of portable app packages a user runs in a given session, this can exhaust temp disk space rather quickly. There are to many trade offs to consider. Make the RAM drive too large and if the user doesn't have enough RAM the drive creation either fails, or it succeeds and there is not enough RAM left for the OS or other applications. Make the RAM drive too small and space is exhausted after only a couple of apps are launched. Either scenario is unacceptable to the end user, who most likely does not understand they need to anticipate and calculate extracted size, physical RAM available on every computer they plan to boot, frequency of use, and the number and disk space requirements of other apps/temp space/etc. in the first place, and can't be relied upon to configure the environment correctly at build time.
 
-3. Customization. Most portable apps are not designed to be pre-configured. By extracting the original setup file ourselves we can allow the user to configure some application settings via the script interface, such as language, layout, preferences, etc. We can also register and make use of shell extensions, menu integrations, file handlers, etc. that are typically disabled and/or removed altogether in a portable app package, as they just don't make sense in that context.
+3. Customization. Portable apps may not be designed to be pre-configured, and even if they are the process is not any easier then making the needed registry/config modifications at build time. By extracting the original setup file ourselves we can allow the user to configure some application settings via the script interface, such as language, layout, preferences, etc. We can also register and make use of shell extensions, menu integrations, file handlers, services, drivers, etc. that are typically disabled and/or removed altogether in a portable app package, as they just don't make sense in that context.
 
 = Win11 Support =