JauntePE 0.3.0 has one important and a few other limitations that you need to be aware of in order to get the most out of its capabilities.
-
Limitation/Problem: Portably running applications with full file system redirection on, from the Desktop, My Documents, Program Files, or other special folders, i.e. non-portable folders, causes unspecified problems.
Work around: Don't portably run applications, with any type of file system redirection on, from the Desktop, My Documents, Program Files, or other special folders.
You can try turning on the ExcludeAppDir option but that's really only of use when the entire portable file system is contained within the portablized application's executable's directory. You can also try adding the root of the portable file system as an excluded file system path. But both of these suggestions may cause other, unknown, problems.
Reason: JauntePE accomplishes file system portablization through a simple technique known as redirection. When an application makes a file system related request, the JauntePE runtime intercepts the request, takes a look at it to see if it needs to be modified, modifies it as necessary, and then passes the request onto the system to complete the processing. Part of the modification of the request may be the changing of a path rooted in a special folder to an equivalent portable path rooted elsewhere. If the equivalent portable path is also rooted in a redirectable special folder, problems can occur. What the actual problems are have not been documented.
Example: Let's say you've created some new text in a portablized Notepad window that you wish to save into your "My Documents" folder. An example file system path to that folder would be "C:\Documents and Settings\myusername\My Documents\mytext.txt". The JauntePE runtime takes this request and compares it against the configuration settings it was started with. Based on the comparisons, JauntePE decides the file system path that the application wants to store the file to is one that is included for redirection. So it changes the path to one that is within its configuration's portable file system and then passes the request on to Windows for completion. For a portable file system that has a root path of "F:\myPortables\Notepad\JPE", the redirection path for the above "save file" request would be "F:\myPortables\Notepad\JPE\User\Documents\mytext.txt".
Using the above as an example, let's now say that your portable Notepad file system has a root path on your desktop. So instead of "F:\myPortables\Notepad\JPE" as its portable file system's root path, you now have "C:\Documents and Settings\myusername\Desktop\myPortables\Notepad\JPE" as its root path. As you hopefully have surmised, this path is also redirectable. -
Limitation/Problem: Under certain situations, portably running multiple applications, or multiple instances of the same application, that use the same in-memory portable registry, can cause unspecified problems.
Work around: If a problem arises (you get an error message, etc.) that alludes to the possibility of missing or inconsistent or out-of-sync registry entries, try changing the in-memory registry setting to 0. If that works and it wasn't set to 1 to begin with, try setting it to 1, which will get you at least partial benefits from in-memory portable registry use.
Reason: The in-memory portable registry used by a given process (running instance of an application executable) is only accessible to that one process. It is not shared amongst all portably run processes, even if they are all using the same configuration ini that specifies the same portable registry path.
The only way a given portable registry is completely shared amongst all of the processes that make use of it is with a MemRegistry setting of 0. This setting completely turns off in-memory use and causes all reads and writes from and to the portable registry to occur immediately and against the portable registry .reg file directly. Keep in mind, however, that turning off in-memory use also turns off a number of other useful registry-related features, such as FillRegistry, RegIgnDel, and RegMerge.
Using a setting of 1 (which is the default for most of the supplied config examples and for Quickie packages) will cause each process that makes use of a given portable registry to read it into memory when the application is started, and to not read it again. This means any changes a given process makes to a portable registry won't be seen by any of the other currently running processes unless they have a setting of 0 and the process making the changes has a setting of 1 (since a setting of 1 means that updates are immediately written to the portable registry .reg file.) If all of the processes have a setting of 1, only newly started processes will pick up any changes made since the original processes were started. -
Limitation/Problem: On Windows versions newer than XP, JauntePE may not redirect every call made by an application to the system registry and file system api functions.
And for Vista (or newer) targeted applications, browsing the file system may not display the portable files and sub-directories at all.
Work around: There are no known work arounds.
Reason: The JauntePE runtime dll was coded against the system registry and file system api functions specifications as defined in the Windows XP SP2 Microsoft Platform SDK. It was also tested for the most part on that version of Windows. Since then newer versions of Windows have been released that greatly expand the number of system registry and file system api functions that an application may make use of. Primarily on Vista.
Also on Vista, major changes have been made to the shell interface functions that an application may make use of, such as the new replacement dialog box for the previously used File Open/Save dialog box. Not only has the user interface changed, but the Microsoft shell dlls appear to have been recoded to bypass the normal system registry and file system api functions and to instead directly call the publically undocumented NTDLL functions themselves. As JauntePE does not redirect at this level, these calls are missed and not redirected as needed. -
Limitation/Problem: JauntePE only works with 16 bit or 32 bit processes, and only works with 16 processes that are run on Windows 2000 or newer.
Work around: There are no known work arounds.
Reason: The JauntePE runtime dll is a 32 bit runtime executable. Which means that it is only usable within a 32 bit process.
On Windows NT or 2000 or newer, there is an option when creating a 16 bit process to have it run within a separate 32 bit process known as a WoW VDM (Win16 on Win32 Virtual DOS Machine.) The application talks to the VDM and the VDM passes the requests on to the 32 bit api functions. This is what JauntePE takes advantage of in order to portably run 16 bit applications on Windows 2000 or newer. -
Limitation/Problem: JauntePE does not correctly process Unicode-based ini configuration files.
Work around: There are no known work arounds.
Reason: All JauntePE executables, including all of the JauntePE runtime dlls, only support ANSI-based ini configuration files. Which means that it isn't possible to specify replacement or help text, that requires Unicode characters, for any of the GUIs. It also means that it isn't possible to specify any registry or file system paths, that require Unicode characters, for any launch or runtime ini configuration file. -
Limitation/Problem: JauntePE's default IdentMode does not provide visual feedback 100% of the time on an application's top-level windows.
Work around: Try switching to one of the other modes or just turn it off all together if you don't need any visual feedback.
Reason: MS Windows. -
Limitation/Problem: The JauntePE runtime dll's determination of the log file's "waiting for input" point in time is still inconsistent between 9x and NT-based versions of the OS.
Work around: Perform all of your "waiting for input" tests on NT-based versions.
Reason: MS Windows.