Understanding JauntePE better

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.
Post Reply
Message
Author
crownixx
Posts: 403
Joined: Sat May 12, 2007 6:26 am

Understanding JauntePE better

#1 Post by crownixx »

the "readme" and "example readme" is a little bit hard to understand for me. and i read them many times to make more simple explaination below. Of course correct me if some of the information below is wrong.
-----------------------------------------------

JauntePE have 2 ways (strategy) to run the application as portable
  • 1. Using JauntePE Launchpad
    2. Using Build Portable to create specific application launcher and Application-specific ini (manually created)
on strategy 1
a) all applications settings can be controll/edit by JauntePE GUI
b)all applications settings are stored in JauntePE_jauntePE.ini and JauntePE_launchPad.ini.
c) all aplications registry settings will be stored into only one registry file, i.e jauntePE_registry.reg
d) all applications will share the same Filesystem together, i.e Files folder

on strategy 2
a) application will have its own settings and independent with main JauntePE
b) the application stores its settings in appname_JauntePE.ini
c) application have its own registry files, i.e appname_registry.reg
d) application have its own Filesystem


Disadvantage on strategy 1
a) they have same settings in JauntePE_jauntePE.ini
b) need to open the JauntePE 1st before launching our portable


Disadvantage on strategy 2
a) the JauntePE.dll & madCHook.dll should be in each of the application directory
b) had to manually create appname_jauntePE.ini and its configuration


Difference between JauntePE_jauntePE.ini and appname_jauntePE.ini
*i know we can use JauntePE_jauntePE.ini name in strategy 2 but let fix into one name to reduce confusion.

JauntePE_jauntePE.ini
--------------------------------------
[RegistryExclude]

[RegistryInclude]

[RegistryIgnore]

[FilesystemExclude]

[FilesystemInclude]

[FilesystemIgnore]

[ModuleExclude]

[ModuleInclude]

[SpecialFolders]
----------------------------------------------

appname_jauntePE.ini.. The difference is it has 2 more configuration
----------------------------------------------
[Registry]
Ini=
Use=
Data=

[Filesystem]
Ini=
Use=
Data=


[RegistryExclude]

[RegistryInclude]

[RegistryIgnore]

[FilesystemExclude]

[FilesystemInclude]

[FilesystemIgnore]

[ModuleExclude]

[ModuleInclude]

[SpecialFolders]
--------------------------------------------

Firewrath guide basically using strategy 2 and i made JauntePE AutoWizard using Firewrath guide..
If the above is right, i will add HOWTO portable using those 2 strategy with simple way, of course
Last edited by crownixx on Fri Jun 29, 2007 8:45 am, edited 1 time in total.

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

#2 Post by redllar »

Sorry, but you seem to be missing some crucial points here. You're thinking too specific when in fact the JPE runtime environment for an app is very generalized. There's also very little difference between how you launch the app in terms of what settings get used and what portable registry and/or filesystem gets used. Your strategies are just too narrowly defined. Hopefully I can help make some sense of this for you.

Okay, the JPE runtime makes use of a certain "set" of settings. I'll call these the runtime settings. Within the runtime settings is a subset of settings that I'll call the launch settings. For the most part the launch settings are the yes/no, on/off types of settings. The runtime settings include those plus all of the inclusion/exclusion/ignore settings, the special folder settings, and any others I can't think of off the top of my head. Basically all of the settings that the JPE runtime uses to manage a portablized app.

In the built portable case, the launch settings are stored within the portable launcher executable itself. These are the answers to the questions asked of you via the wizard, or are the values given via the build command line switchs: portable registry - yes or no, portable file system - yes or no, etc. These also include the launchpad's Settings->Identification settings which are not available via the wizard or the build command line switchs.

Using the launchpad, the launch settings are stored within the launchpad ini. And to be clear, using the launchpad gui you do have the choice of indicating whether you want to use an app-specific portable setup or a common one. It's right there in the launchpad app icon's Properties dialog box's "App-specific registry storage" checkbox. Also keep in mind that the Settings dialog box's settings are only used as defaults for the equivalent Properties dialog box's settings.

Now, unlike the launch settings, the runtime settings are completely independent upon the launch method used. It doesn't matter whether you launch via a built portable, via a drag-n-drop onto the JPE executable, via a SendTo command, via a command shell script, or via the JPE launchpad. And as I indicated earlier, since the runtime settings are all inclusive, they may completely override the launch settings.

The way it works is all detailed in the "Examples ReadMe.txt" file in the "JPE Examples" directory in Firewrath's zip. But I'll try again here:

1) You launch an app. The app has certain launch settings associated with it that serve as defaults for some, not all, of the runtime settings. It doesn't matter where the launch settings came from. At this point, they just are.

2) The launch settings are passed on to the JPE runtime executing within the launched app.

3) The JPE runtime begins looking for a file which may or may not be used to override the launch settings. If such a file is found and it contains launch settings values, then those are used. If not, then the passed launch settings are used. The runtime also uses that file to specify the remaining, non-launch runtime settings.

The search for this file is done in a specific order:

1st - In app exe dir: %appname%_jauntePE.ini - affects only the app
2nd - In app exe dir: JauntePE_jauntePE.ini - affects all apps in the app dir
3th - In parent's data dir: %appname%_jauntePE.ini - affects only the app
4th - In parent's data dir: JauntePE_jauntePE.ini - affects all apps in the data dir
5rd - In parent's ini dir: %appname%_jauntePE.ini - affects only the app
6th - In parent's ini dir: JauntePE_jauntePE.ini - affects all apps in the ini dir
7th - In JPE dll dir: %appname%_jauntePE.ini - affects only the app
8th - In JPE dll dir: JauntePE_jauntePE.ini - affects all apps, period

As you can see, the search order bounces between app-specific to app-generic, within a hierarchy of directories. So there's really no need to copy over the runtime to your app directory. The runtime itself is perfectly capable of finding the ini you set up as long as you follow the search order pattern given above. Once an ini is found the searching is stopped and that ini is used as the defacto specifier for all runtime settings (unless a Path= setting is given - please see the above mentioned file for more on that.) Any launch settings not found in this file default back to the launch settings passed to the runtime via its parent, which may be a launcher or a process launched by a launcher, etc.

All of this was done for several reasons. The first was to minimize the necessary ini files that you need to set up and manage since most apps can make use of the same set of registry and fileystem and module inclusion/exclusion and ignore settings. That's what the launchpad's Settings dialog boxes are for. It's only those special apps or special situations that require something different. That's what the launchpad's app-icon-specific Properties dialog box is for. That's also where you get into the alternative, or overriding, JPE runtime inis.

The second reason this was done was to allow an alternative launcher such as PStart to be used and still give you the control over the launched app's JPE runtime settings that you would have gotten had you used the JPE launchpad or JPE built portable launcher.

This was also done to allow for the capability of grouping apps together so that they use the same portable registry and/or file system. For instance, you could have all of the SysInternals apps using the same app-group-specific registry. You could have all of the Mozilla apps using the same registry and file system.

BTW, the new version of the JPE launchpad's app-icon-specific Properties dialog box has been initially extended to allow you to create and edit all of the runtime settings inis, so that you may use it to create app-specifc and app-group-specific JPE runtime inis as well. It's still a work-in-progress but my goal is to allow any of the inis you need to setup to be edited via the gui. Unless you just like to muck with inis, that is.

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

#3 Post by crownixx »

sory for that..i hope my assumption mistake here can be guide for others JauntePE newbie like me

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

#4 Post by crownixx »

sory for that..i hope my assumption mistake here can be guide for others JauntePE newbie like me.
and yes, this time i get more clear picture how JauntePE works

Post Reply