elie/PhoenixPE
1
0
Fork 0
mirror of https://github.com/PhoenixPE/PhoenixPE.git synced 2025-09-17 18:48:04 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ (mediawiki)

Jonathan Holmgren
2022-09-18 18:39:02 -05:00
parent 18cd4576b8
commit 196bce5e7b
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
FAQ.mediawiki

@@ -22,6 +22,14 @@ PhoenixPE on the other hand targets basic/advanced users as well as developers l
'''TL;DR: No. It's an alternative. The developers of both projects are part of a vibrate community that works together and shares their knowledge and experience. Use the one that best meets your needs. You can't go wrong.'''
== Why don't you just use PortableApps.com, SFX Constructor, etc instead of developing your own App Scripts? ==
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.
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.
= Win11 Support =
== Building from a Win11 source with explorer shell causes blackscreen on boot. ==