JauntePE with launcher (ObjectDock)

Discuss anything related to JauntePE, the utlimate utility to help you tame non-portable applications. Share your experience about the apps that work with JauntePE, and the apps that don't.
Message
Author
redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#46 Post by redllar »

Yeah, I think you're re-covering territory Firewrath and I went through a while back. It's pretty easy to add in different types of lists to have it do different things, so maybe some future version could accomodate a list that would specify which keys could get added to the .reg while the app was running but should be cleaned out on app termination.
EDIT2: You already implemented my suggestion before I even thought about it. I tested with OSK using MemRegistry=4 and as usual it works wonderfully. Thank you for this.
I didn't really do anything. It's been there for months and months. No one ever used it though because 1) it's very experimental and 2) it was previously only available to you through the command line build switches.

Don't expect it to work with every app. There's key pieces of code missing for apps that do registry browsing for instance. In fact that goes for just about all of the in-memory .reg usage options. Some are just more complete than others.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#47 Post by Chris »

accomodate a list that would specify which keys could get added to the .reg while the app was running but should be cleaned out on app termination.
Yes, I agree with this. Then, I could just add those system module keys, so the portable registry and system regisry would be free of writes from system modules.
But, can it cleans within RAM? I mean, if it needs .reg to be written first then deletes the keys, it would not good for USB... I think.
I didn't really do anything. It's been there for months and months. No one ever used it though
For me MemRegistry=4 is important for applications that I don't want to change its settings. Usually I put it as read-only, now I can use this setting.

I know that not all can work or some may not work properly. But, I guess mostly the problem is about drivers.
And also maybe applications that need to put application path in the registry, which gives me an idea:
Perhaps option that adds application path in a defined key could be useful. Maybe also with macros of special system folders, etc.
Example, when I checked Microsoft Reader, I saw:

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EBook]
"InstallDir"="Y:\\Microsoft Reader\\"
"ClearTypeLocation"="Z:\\Program Files\\Common Files\\Microsoft Shared\\ClearType\\ctras.dll"
This kind of entry is also in GeoShell. Maybe if JauntePE has macro, this kind of registry can be made "path" portable.

I mean macros, like:
@ProgramFiles = .\Program Files\
@CurrentDir = Dir of the JPEized application
So, example for above, user needs to put this in the .reg:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EBook]
"InstallDir"="@CurrentDir\\"
"ClearTypeLocation"="@ProgramFiles\\Common Files\\Microsoft Shared\\ClearType\\ctras.dll"
So when JPEized app is started, JPE edit the JPE-reg @ProgramFiles to actual program files of the current OS. And @CurrentDir changed as the current dir of the application. So, even if the location is changed, it doesn't matter as the registry is changed also.
Or, change it within RAM, so no write in the application partition, incase it is in USB. Don't know if this worth while. Just a suggestion.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#48 Post by redllar »

But, can it cleans within RAM? I mean, if it needs .reg to be written first then deletes the keys, it would not good for USB...
I see your point. I was thinking that these specially flagged keys would only be kept in memory no matter what memory-usage setting was chosen.
Perhaps option that adds application path in a defined key could be useful. Maybe also with macros of special system folders, etc.
Example, when I checked Microsoft Reader, I saw:
Code:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EBook]
"InstallDir"="Y:\\Microsoft Reader\\"
"ClearTypeLocation"="Z:\\Program Files\\Common Files\\Microsoft Shared\\ClearType\\ctras.dll"

This kind of entry is also in GeoShell. Maybe if JauntePE has macro, this kind of registry can be made "path" portable.

I mean macros, like:
@ProgramFiles = .\Program Files\
@CurrentDir = Dir of the JPEized application
So, example for above, user needs to put this in the .reg:
Quote:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EBook]
"InstallDir"="@CurrentDir\\"
"ClearTypeLocation"="@ProgramFiles\\Common Files\\Microsoft Shared\\ClearType\\ctras.dll"

So when JPEized app is started, JPE edit the JPE-reg @ProgramFiles to actual program files of the current OS. And @CurrentDir changed as the current dir of the application. So, even if the location is changed, it doesn't matter as the registry is changed also.
Or, change it within RAM, so no write in the application partition, incase it is in USB. Don't know if this worth while. Just a suggestion.
Interesting idea, but that would have to be for way down the road.

Right now that problem can be solved by using the file system redirection capabilities. Just set up a portable equivalent to the program files common files directory, plop the needed files there, and then redirect that special directory. Also, install to program files as normal. Set up the portablized app in a portable equivalent to program files and then redirect that special directory. Those non-portable registry entries then get portablized by the jpe dll when the app makes use of them.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#49 Post by Chris »

I was thinking that these specially flagged keys would only be kept in memory no matter what memory-usage setting was chosen.
Great idea, with this user don't have to bother with unwanted entries. And maybe user also could add what entries to be kept in memory, like [RegistryKeepInMem]1= and [ModuleKeepInMem]1=.

Regarding [ModuleExclude] and Include using ObjectDock. It seems when I have ModuleExclude=*, a docklet (a module or plugin of OD) doesn't work and couple of files are not redirected. So, I believe I haven't add all necessary module in [ModuleInclude]. This example could be experienced by other user, I guess your idea could solve this problem but I want to understand more about it.
[ModuleExclude] is specifically just for application's modules, and nothing to do with child process, right?
If yes, Child process only effected with %ChildName_JauntePE.ini in the JauntePE.dll, correct?
Just set up a portable equivalent to the program files common files directory, plop the needed files there, and then redirect that special directory. Also, install to program files as normal. Set up the portablized app in a portable equivalent to program files and then redirect that special directory. Those non-portable registry entries then get portablized by the jpe dll when the app makes use of them.
Sorry, if I misunderstood your explanation. But, doesn't it mean the application that changes the system registry; and because the app changes the system registry, JPE captures that changes?
If that's what you mean, what about application that only sees (no changes or writes) the location of a file from registry?

Let me give a clearer example with GeoShell. In the GeoShell there are 2 exe, WinShellEx.exe and GeoShell.exe.
In order to run GeoShell, user only needs to run WinShellEx.exe (this exe handles tray hooking) and WinShellEx will automatically run GeoShell.exe. But, WinShellEx only knows the location of GeoShell.exe from registry entry.
So if I move the whole GeoShell folder to different location, WinShellEx will not able to run GeoShell.exe unless the registry entry is changed to point to location of the new GeoShell.exe.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#50 Post by redllar »

[ModuleExclude] is specifically just for application's modules, and nothing to do with child process, right?
If yes, Child process only effected with %ChildName_JauntePE.ini in the JauntePE.dll, correct?
If I understand your first question correctly, the module lists are not used in any way when launching a child process. The modules lists are simply another mechanism for determining registry and file system redirection.

Now, whether or not the child process uses the same JPE runtime ini as its parent depends upon the filenames of the two app's executables, the names of the JPE runtime inis that are "available" to them both, the location of the JPE runtime dlls, the locations of all of these files, and the [Registry]Ini= and [Filesystem]Ini= settings within the inis. So I can't answer yes or no unless you give me the specifics for all of the above.
Sorry, if I misunderstood your explanation. But, doesn't it mean the application that changes the system registry; and because the app changes the system registry, JPE captures that changes?
If that's what you mean, what about application that only sees (no changes or writes) the location of a file from registry?
An app may have a hardcoded path in the .reg. But it eventually is going to USE that path, yes? And in so doing it must use one of the api functions the JPE has hooked. So when the app goes to USE that hardcoded path, the JPE runtime looks at the request and says, ahha, this is a path that needs to be redirected. That's what I'm getting at. You store into the .reg, or the JPEized installer does, the normal "C:\Program Files\..." location of the file, turn on file system redirection, and tell JPE to redirect the Program Files folder.

So using your example, you "install", either automatically or manually, WinShellEx and GeoShell so that they use the same portable .reg, and preferrably, the same portable file system. You also "install" them so that they are located in redirected "Program Files" directories. And if you've done the install manually, you set WinShellEx's .reg entry for where GeoShell is to point to "C:\Program Files\GeoShell". Then when WinShellEx USEs that path in a call to launch GeoShell, JPE sees it and redirects it to the portable Program Files directory and GeoShell is launched as expected.

Here's how I would probably configure it. Note that you can pretty much get all of this automatically by successfully running the WinShellEx and GeoShell installers through JPE, if you place them both into the Portables directory.

Also please note that it doesn't have to be set up this way. This way is just pretty clean and apparent, to me anyway. Technically you don't really even need to have the two apps located anywhere "near" each other:

Code: Select all

-> Portables
   |
   | o portable.ini
   |   - contains [Registry]Use=1, [Registry]Ini=.\portable.reg, [Filesystem]Use=1,
   |     [Filesystem]Ini=.\, and [SpecialFolders]38=Files\ProgramFiles
   |   - contains other sections as desired
   |
   | o portable.reg
   |   - contains entry HKCU\WinShellEx\ShellLocation whose value is
   |     "C:\Program Files\GeoShell\geoshell.exe"
   |
   -> Files
      |
      -> ProgramFiles
         |
         -> GeoShell
         |  o geoshell.exe
         |  o all of its other files and directories
         |  o JauntePE_jauntePE.ini
         |    - contains ONLY [Registry]Ini=..\..\..\portable.ini
         |    - contains ONLY [Filesystem]Ini=..\..\..\portable.ini
         |
         -> WinShellEx
         |  o winshellex.exe
         |  o all of its other files and directories
         |  o JauntePE_jauntePE.ini
         |    - contains ONLY [Registry]Ini=..\..\..\portable.ini
         |    - contains ONLY [Filesystem]Ini=..\..\..\portable.ini
To continue with the example, you JPElaunch WinShellEx. Its injected JPE runtime uses the Portables\portable.ini to load its settings. Registry redirection is on. File system redirection is on. And special folder #38 (the current user's "Program Files" folder) has a portable equivalent of Portables\Files\ProgramFiles.

WinShellEx "reads" the registry value at HKCU\WinShellEx\ShellLocation. This gets registry redirected by the JPE runtime, so from the .reg the value of "C:\Program Files\GeoShell\geoshell.exe" is returned to it.

WinShellEx then "launches" the executable given in the "read" registry value. This gets file system redirected by the JPE runtime, so the system is told to launch "Portables\Files\ProgramFiles\GeoShell\geoshell.exe instead. Since miscellaneous redirection is on by default, the JPE runtime also injects itself into the newly created process. That process's JPE runtime makes use of the same Portables\portable.ini to load its settings from and away it goes.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#51 Post by Chris »

the module lists are not used in any way when launching a child process. The modules lists are simply another mechanism for determining registry and file system redirection.
Thank you to make it clear, I just want to make sure it won't effecting the child process.

I think I understand what you mean about the GeoShell. Basically, try to redirect it to special-system directory, example "program files". So, when the app reads the registry, it will search in c:\program files (according to the .reg). And even though I put it in different location, JPE redirects it there, right?
But, I think I would have problem as my "program files" is in z: drive. So, even though JPE redirects GeoShell to z:\program files, WinShellEx is looking in c:\program files according to the .reg. I would still need to edit the .reg manually if I were to use the app on different PC.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#52 Post by redllar »

So, even though JPE redirects GeoShell to z:\program files, WinShellEx is looking in c:\program files according to the .reg. I would still need to edit the .reg manually if I were to use the app on different PC.
The .reg would be fine for the computer and user account that you set up the apps for. Remember the other [SpecialFolders=computer/user] sections that got added to the JPE ini at runtime with the 011 build? What I'm going to add back in is a way for you to specify any special folders for a given computer and user pairing. That way you'll tell the jpe runtime that any "Z:\Program Files" paths that come along should be converted to the current system's equivalent if the app is not being run from the specified computer and user account.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#53 Post by Chris »

Yes, I remember about 011 which creates special folders info in the ini. Actually, I don't feel comfortable to have a specific user info or setting within the ini. That's why when I was using 011, I set the ini as read-only to prevent any "SpecialFolders" entries, because it feels like not clean anymore if there's entry not necessary when used on different computer. Only my feeling though. But if you think that's the best way, I will agree with you, not a biggie. Hopefully, it won't effect the performance like you explained before, so you remove this feature. Maybe an option to use this feature or not would be a good idea.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#54 Post by redllar »

Maybe an option to use this feature or not would be a good idea.
Yes, it'll be an option the JPE user will have control over, just like the other ini entries. And the section names will just be [SpecialFolders#], where # is any valid number, numbered from 1 onwards.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#55 Post by Chris »

I tried to JPEized GeoShell but I got some strange behavior.
With my own settings, GeoShell only shows the gripper. Gripper is like the base of all modules from GeoShell. Then, I tried to use the settings of new install. It shows everything (taskbar & tray); but if I add or remove a module, GeoShell hangs.

If you have time please check it, here is the downloads.
I tested it not with installer, so I downloaded the zip.
All you need to do after unziping it is: in the WinShellEx folder, edit WinShellEx.reg to point to the location of GeoShell.exe, import the WinShellEx.reg, and then run the WinShellEx.exe.

One more thing. I tested FileSystem redirection using regedit.exe. I run JPEized regedit, click import and it will open a dialog. Within that dialog, I copied a file to "Program Files" directory, because I didn't see the file is added, I re-paste it and dialog confirm of replace is popped. Then, regedit would hang whatever option I chose.
This maybe the same with the browse bug you said, but just want to let you know maybe could be useful.

EDIT: I tried to JPEized Firefox 2.0.0.6, FF saves its settings in "AppData". I read there is a work around in the 012 changelog. Is this the work-around? "added ability to manually add a "Documents and Settings\%username%\<something>"...". I add that to the ini under [FilesystemInclude], also change %username% to mine, but firefox still creates its settings in the "AppData". Any suggestion?

One more thing, within the command-line what is the difference between using JauntePE.exe and JauntePE_cmdline.exe? They both can build portable exe and launch application as portable.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#56 Post by redllar »

I tried to JPEized GeoShell but I got some strange behavior.
With my own settings, GeoShell only shows the gripper. Gripper is like the base of all modules from GeoShell. Then, I tried to use the settings of new install. It shows everything (taskbar & tray); but if I add or remove a module, GeoShell hangs.

If you have time please check it, here is the downloads.
I tested it not with installer, so I downloaded the zip.
All you need to do after unziping it is: in the WinShellEx folder, edit WinShellEx.reg to point to the location of GeoShell.exe, import the WinShellEx.reg, and then run the WinShellEx.exe.
Okay, I'll give it a try. It might take me a week to get back with any info though.
One more thing. I tested FileSystem redirection using regedit.exe. I run JPEized regedit, click import and it will open a dialog. Within that dialog, I copied a file to "Program Files" directory, because I didn't see the file is added, I re-paste it and dialog confirm of replace is popped. Then, regedit would hang whatever option I chose.
This maybe the same with the browse bug you said, but just want to let you know maybe could be useful.
I tried that here several times but couldn't get it to hang. But the file I copied didn't get redirected, so I need to look into why. You might have run into a problem with multiple threads being redirected at the same time when going after the same set of data. I'm pretty sure there's a window of opportunity for a dead-lock condition when that happens, which would cause the app to hang with no cpu usage.
EDIT: I tried to JPEized Firefox 2.0.0.6, FF saves its settings in "AppData". I read there is a work around in the 012 changelog. Is this the work-around? "added ability to manually add a "Documents and Settings\%username%\<something>"...". I add that to the ini under [FilesystemInclude], also change %username% to mine, but firefox still creates its settings in the "AppData". Any suggestion?
No, the work-around is for %userprofile%, not %appdata%. %appdata% is a special folder unto itself, so there are specific special folder numbers for it that should be used. If you search through the [SpecialFolders] section of the distributed JauntePE_jauntePE.ini you will find them. The work-around is for those cases where an app stores directly into the user profile directory, either with its own file(s) or own directory(s).
One more thing, within the command-line what is the difference between using JauntePE.exe and JauntePE_cmdline.exe? They both can build portable exe and launch application as portable.
There shouldn't be any difference between using either JPE exe from the command line. They both share the same code base for that processing so they should act the same. The _cmdline version was meant for use on thumb drives where space is at a premium and you didn't need to make use of the JPE launchpad or other gui features.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#57 Post by Chris »

It might take me a week to get back with any info though.
It is not a problem at all, I'm already happy and grateful that you would want to check it out.
The GeoShell problem I encountered when I load or unload a module was using 50 cpu on taskman, so I guess this was not a dead-lock condition.
I tried that here several times but couldn't get it to hang. But the file I copied didn't get redirected, so I need to look into why.
JauntePE was able to redirect filesystem for me, but I couldn't see the file immediately after coping it. And for the hanging, I think it was not because filesystem redirection as it goes to hang whatever option I chose (when I was asked to overwrite it or not). Also regedit.exe was using 0 cpu when hang, so it should be a dead-lock condition that you explained.

Also, I notice in the "Program Files" dir when JPE redirects a file there, I could only see (or regedit only read) the file I just copied (no other directories that supposed to be in the "Program Files" dir). Does it mean JPE allows JPEized-apps to read system-dirs (per directory, based on the special folder) that have no file is redirected there; and if I redirect an app in "Program Files", that app can not read other dir or file within "Program Files" dir?

AVG-antivirus creates a dir outside [special folders], maybe a good idea to allow user to define him or herself what folder to be redirected (outside special folders). Could be useful for other apps that may be doing the same like AVG, just a thought though.
No, the work-around is for %userprofile%, not %appdata%. %appdata% is a special folder unto itself, so there are specific special folder numbers for it that should be used. If you search through the [SpecialFolders] section of the distributed JauntePE_jauntePE.ini you will find them.
I'm sorry, but I couldn't find the %userprofile% you mentioned in the JauntePE_jauntePE.ini & [SpecialFolders] section. These are the entries in my JauntePE_jauntePE.ini:

Code: Select all

[SpecialFolders]
0=Files\Desktop
1=Files\Internet
2=Files\StartMenu\Programs
3=Files\Computer\Controls
4=Files\Computer\Printers
5=Files\Documents
6=Files\Favorites
7=Files\StartMenu\Programs\Startup
8=Files\RecentDocs
9=Files\SendTo
10=Files\Desktop\RecycleBin
11=Files\StartMenu
12=Files\Documents
13=Files\Documents\Music
14=Files\Documents\Video
15=Files\Unknown
16=Files\Desktop
17=Files\Drives
18=Files\Network
19=Files\NetHood
20=Files\Windows\Fonts
21=Files\Templates
22=Files\StartMenu
23=Files\StartMenu\Programs
24=Files\StartMenu\Programs\Startup
25=Files\Desktop
26=Files\AppData
27=Files\PrintHood
28=Files\AppData
29=Files\Startup
30=Files\Startup
31=Files\Favorites
32=Files\INetCache
33=Files\INetCookies
34=Files\INetHistory
35=Files\AppData
36=Files\Windows
37=Files\Windows\System
38=Files\ProgramFiles
39=Files\Documents\Pictures
40=Files
41=Files\Windows\System
42=Files\ProgramFiles
43=Files\ProgramFiles\Common
44=Files\ProgramFiles\Common
45=Files\Templates
46=Files\Documents
47=Files\StartMenu\Programs\AdminTools
48=Files\StartMenu\Programs\AdminTools
49=Files\Connections
50=Files\Unknown
51=Files\Unknown
52=Files\Unknown
53=Files\Documents\Music
54=Files\Documents\Pictures
55=Files\Documents\Video
56=Files\Windows\Resources
57=Files\Local\Resources
58=Files\OEM
59=Files\AppData\CDBurnArea
60=Files\Unknown
61=Files\ComputersNearMe
62=Files
The ObjectDock also stores its setting within user profile directory, but JPE redirects it even I don't add [FilesystemInclude]. I wonder why Firefox needs additional setting?
EDIT: I guess, JPE able to redirect ObjectDock easily because OD uses [SpecialFolders], unlike Firefox.
Last edited by Chris on Sun Sep 02, 2007 4:28 am, edited 1 time in total.

crownixx
Posts: 403
Joined: Sat May 12, 2007 6:26 am

#58 Post by crownixx »

Chris wrote:I read there is a work around in the 012 changelog. Is this the work-around? "added ability to manually add a "Documents and Settings\%username%\<something>"...". I add that to the ini under [FilesystemInclude], also change %username% to mine, but firefox still creates its settings in the "AppData". Any suggestion?
redllar wrote:No, the work-around is for %userprofile%, not %appdata%....The work-around is for those cases where an app stores directly into the user profile directory, either with its own file(s) or own directory(s).
Chris wrote:I'm sorry, but I couldn't find the %userprofile% you mentioned in the JauntePE_jauntePE.ini & [SpecialFolders] section.
redllar make this work-around when i had a problemhere with wxDownload Fast downloader.. hope this help
another good example i found is SciTE Editor which also add its settings files under %userprofile%

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#59 Post by Chris »

Thanks crownixx for the info. From the thread I got this:
The way to tell this is to see if it shows up in the "JPE Settings->File System->Exceptions->Includes->Add->Special File Folder Paths" drop down list. If it does, and if using it adds a 1=40 line to the [FilesystemInclude] section
I check on the drop down list, I could see my %userprofile% folder paths. However, I didn't see the folders that mozilla are using which are:
.\Documents and Settings\%UserName%\AppData
.\Documents and Settings\%UserName%\Local Settings\AppData

I always able to redirect FileSystem on different folders without any problem, example in: .\Documents and Settings\%UserName%\Application Data. So, I guess the problem is: the paths what Firefox uses are not SpecialFolder.

I tried to add ".\Documents and Settings\%UserName%\AppData" in the Exceptions->Includes and run FireFox via the launcher, but FF still creates entries there. Can I manually define or add [SpecialFolders]?

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#60 Post by redllar »

Chris wrote:Thanks crownixx for the info. From the thread I got this:
The way to tell this is to see if it shows up in the "JPE Settings->File System->Exceptions->Includes->Add->Special File Folder Paths" drop down list. If it does, and if using it adds a 1=40 line to the [FilesystemInclude] section
I check on the drop down list, I could see my %userprofile% folder paths. However, I didn't see the folders that mozilla are using which are:
.\Documents and Settings\%UserName%\AppData
.\Documents and Settings\%UserName%\Local Settings\AppData

I always able to redirect FileSystem on different folders without any problem, example in: .\Documents and Settings\%UserName%\Application Data. So, I guess the problem is: the paths what Firefox uses are not SpecialFolder.

I tried to add ".\Documents and Settings\%UserName%\AppData" in the Exceptions->Includes and run FireFox via the launcher, but FF still creates entries there. Can I manually define or add [SpecialFolders]?
Chris, I think you're running into this problem because you haven't set up your portable file system correctly and the JPEized FF is mistaking the redirected AppData subdirectory name for the real subdirectory name for Application Data. If you have the root of your portable redirected file system in the FF program's folder, then that's probably what the problem is.

A way around this without changing everything should be to add in some FilesystemInclude entries. Specifically, one for %40%\AppData and one for %62%\AppData. But make sure that in the SpecialFolders section that entries 26 and 28 both have AppData as their subdirectorys.

To give you an idea of what I'm talking about, here's a JauntePE_jauntePE.ini I set up for running IcoFX with a portable file system rooted within the directory that the app is in:

Code: Select all


[RegistryExclude]
1=*

[RegistryInclude]
1=HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

[RegistryIgnore]

[FilesystemExclude]
1=*

[FilesystemInclude]
1=26
2=28
3=35
4=%40%\AppData
5=%62%\AppData

[FilesystemIgnore]

[ModuleExclude]
1=*

[ModuleInclude]
1=%appname%.exe

[SpecialFolders]
26=Files\AppData
28=Files\AppData
35=Files\AppData
40=Files
62=Files
IMHO, the best thing would be to go back and run the FF installer through JPE and get a portable file system directory structure set up that has FF installed in a portable ProgramFiles directory. And then anchor the portable file system back at the initial portable directory that you ran the installer from.

If this is confusing to you I'd be glad to help you further but I'm a bit swamped with other stuff right now, so if you could give it a go on your own I'd really appreciate it. I've already covered what I'm talking about in our discussion of setting up WinShellEx and GeoShell, so hopefully that will help.

Post Reply