JPE AutoWizard v2.0.3 -no longer support-
JPE AutoWizard v2.0.3 -no longer support-
JPE AutoWizard v2.0.3
Info:
JPE AutoWizard is a fronted GUI for JauntePE commandline.Normally ,the application/program need to be launch via JauntePE
Launchpad to make it portable. Since the JauntePE is very flexible, it is possible to create portable application that
is independent with JauntePE launchpad by using its "application executable-specific portable launcher executable".
JPE AutoWizard comes in handy where it can easy your work in creating the independent JPE portable application.
NOTE This program is no longer needed since in the latest version of jauntePE, redllar made a better tool called JPE Quickie. It will assist you creating portable app without editing a single line of config file
Info:
JPE AutoWizard is a fronted GUI for JauntePE commandline.Normally ,the application/program need to be launch via JauntePE
Launchpad to make it portable. Since the JauntePE is very flexible, it is possible to create portable application that
is independent with JauntePE launchpad by using its "application executable-specific portable launcher executable".
JPE AutoWizard comes in handy where it can easy your work in creating the independent JPE portable application.
NOTE This program is no longer needed since in the latest version of jauntePE, redllar made a better tool called JPE Quickie. It will assist you creating portable app without editing a single line of config file
Last edited by crownixx on Tue Jan 27, 2009 7:29 am, edited 14 times in total.
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
Suggestion
Just a little Suggestion try rewriting your autoit script so that it runs the command line version and makes it more slient
Re: Suggestion
actually, that was my first idea but the reddlar's readme lack of information about the command line version so i decided to abandon the idea and go for the simple one.thibeaz wrote:Just a little Suggestion try rewriting your autoit script so that it runs the command line version and makes it more slient
or if you know about the parameters used, mybe you can help me out.
mirror added. look into the first postGiGi34 wrote: I went to the link and tried to download, but it seems that the link is broken. I gives me error when trying to download the file
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
Sure
Sure all the commands found in the juantepe command line should show when you run the app. hmm I just tried and it won't show the command dialogue.
But however if I remember all the keyboard commands are also available in the Gui version of JauntePE should be the same for the commandline and probably uses the same options as default in the ini file.
Have you ever decided to work with C++ if so we could work on Translating your wizard into C++ if not I understand
But however if I remember all the keyboard commands are also available in the Gui version of JauntePE should be the same for the commandline and probably uses the same options as default in the ini file.
Have you ever decided to work with C++ if so we could work on Translating your wizard into C++ if not I understand
Re: Sure
the command parameters suppose can be found in the redllar's readmethibeaz wrote:Sure all the commands found in the juantepe command line should show when you run the app. hmm I just tried and it won't show the command dialogue.
my problem is on the last switches. which switch is the same as "keep registry in memory"? i dont want to make a guess so the "simulate the keys in JauntePE GUI" is the safest way
Command line usage
===============
Syntax:
JauntePE.exe [switches] path-to-executable
-or-
JauntePE_cmdline.exe [switches] path-to-executable
The optional [switches] parameters default to -l. Separate
each parameter by at least one space.
Build switches:
-b - build an application executable-specific portable
launcher executable (do not rename the resulting file)
-a - use the application executable's icon as the portable
launcher executable's icon
-e - stuff the application's executable into the portable
launcher executable (will be extracted at runtime if
necessary)
-i - stuff the application's existing ini and/or .reg into
the portable launcher executable (these files must be
in the same directory as the application executable)
(will be extracted at runtime if necessary)
Launch switches:
-l - launch an application executable
Build and launch switches:
-w - leave the current working directory alone
(otherwise change it to the application executable's
directory)
-s - launch screensavers in display mode
(otherwise bring up the screensaver's settings)
-f - portablize the special folders file system changes
into a common directory (rooted off of the JauntePE
home directory)
-F - portablize the special folders file system changes
into an application-specific directory (rooted off
of the application executable's directory)
-r - portablize the registry changes into a common .reg
(JauntePE_registry.reg, located in the JauntePE home
directory)
-R - portablize the registry changes into an application-
specific .reg (located in the application executable's
diretory)
-m - reads into memory, and makes use of an application-
specific text .reg in memory - changes are written
immediately to the application-specific text .reg)
The following build and launch switches are still very much
untested and experimental:
-M - reads text or binary .reg into memory - writes full
text .reg during a normal app end
-Mt - reads text or binary .reg into memory - writes full
text .reg during a normal app end
-Mb - reads text or binary .reg into memory - writes full
binary .reg during a normal app end
-Mn - reads text or binary .reg into memory - updates are
discarded - using this switch with the -b -i switches
will also cause the stuffed .reg to be passed to the
application directly without first writing it to a
file - this is the fastest way to launch an app
i dont understand. Do you mean that the keyboard command in GUI is the shortcut key (like alt+n)?thibeaz wrote: But however if I remember all the keyboard commands are also available in the Gui version of JauntePE should be the same for the commandline and probably uses the same options as default in the ini file.
we can only used the switches/parameters for the JauntePE_commandline.exe
sorry i dont know C++ but why you want to translate it to C++?thibeaz wrote: Have you ever decided to work with C++ if so we could work on Translating your wizard into C++ if not I understand
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
Well
C++ I find to be more rebust than autoit and personally I need something to do in C++ so that I can work things out (Just learning myself)
as for the commandline switches it shouldn't be hard at all. I could probably write the frontend in nsis using only the jauntepe commandline app
as for the commandline switches it shouldn't be hard at all. I could probably write the frontend in nsis using only the jauntepe commandline app
Use -m, as it's the one that's not "untested and experimental."reddlar's readme lack of information about the command line version
BTW, there's a bug in the Build Wizard re: the "Updates are written immediately" radio button. In the current public version it should always be disabled and should always be checked when the "Keep portable registry in memory" button is checked and should always be unchecked when the other is unchecked.
So you might want to get rid of the "Updates..." checkbox in your wizard, along with the associated verbiage.
And just some background on all of that. What I did to try and counteract a lot of usb writes was to check if the registry value actually changed. If it didn't then JPE just ignores the app's write request and tells it the write was successful. If it did change then the write occurs immediately. This occurs whether you use the in-memory option or not. The in-memory option really is there to prevent a lot of the "is the requested value in the portable registry" checks back to the .reg file. For the current public version at least. I had added other in-memory options towards the end. Those are the ones listed as "untested and experimental" command line options and as the disabled radio buttons on the Build Wizard (the "Updates are written at app-end" and "Updates are never written" buttons.) As noted in the readme, an ideal usb usage case would be a binary .reg that is stuffed into the portable launcher, unstuffed into memory at runtime, and never touchs the usb drive on reads or writes. You can't do that through the Build Wizard since they're disabled.
But one thing that's not apparent is that using the command line switchs vs the Build Wizard will always cause the portable launcher to assume the JPE runtime files are in the directory where the JPE exe is, since there's no command line switch to specify that path like there is in the Build Wizard. I honestly didn't think anyone would really want to have multiple copies of the JPE runtime around all over the place, so I never considered such a switch, and no one ever asked for one. There's a couple of other good reasons to keep the JPE runtime only in the JPE directory but I think I'll save all of that for a Performance topic and discussion thread.
One final thing though. The absolute easiest way to do a "build portable" is via a SendTo target link. 2 clicks is all it takes after you set it up. And there's little utilities available to portablize the links. I've got a whole folder of them that I carry around. So there's really no reason to even use a wizard other than for the options the command line switchs don't provide, such as copying over the JPE runtime. You really shouldn't be creating an empty app_jpe.ini though as it can kill performance. But that's for another thread too.
Do you mean that "keep portable registry in memory" should always come along with "updates are writen immediatelly"? Thanks for the information. But are you want to update your JauntePE? i dont know if my AutoWizard still relevan if new JauntePE is comingredllar wrote:
Use -m, as it's the one that's not "untested and experimental."
BTW, there's a bug in the Build Wizard re: the "Updates are written immediately" radio button. In the current public version it should always be disabled and should always be checked when the "Keep portable registry in memory" button is checked and should always be unchecked when the other is unchecked.
So you might want to get rid of the "Updates..." checkbox in your wizard, along with the associated verbiage.
thibeaz,
There you go. You got yourself somethings to work out
I just thought that bring the "independent JPE portable app is more simple, less complicated and easy to maintain. And the JPE runtime files (jauntePE.dll+madCHook.dll+launcher.exe=259kb) not hurt the storage much..redllar wrote: But one thing that's not apparent is that using the command line switchs vs the Build Wizard will always cause the portable launcher to assume the JPE runtime files are in the directory where the JPE exe is, since there's no command line switch to specify that path like there is in the Build Wizard. I honestly didn't think anyone would really want to have multiple copies of the JPE runtime around all over the place, so I never considered such a switch, and no one ever asked for one. There's a couple of other good reasons to keep the JPE runtime only in the JPE directory but I think I'll save all of that for a Performance topic and discussion thread.
But if running portable app from the "main JauntePE" can give more performance, i'll look into that
I dont understand in this sentence (hehe,still improving my english) :p . Is it SendTo target link is the *ini pointed to another *ini like example PStart1?redllar wrote: One final thing though. The absolute easiest way to do a "build portable" is via a SendTo target link. 2 clicks is all it takes after you set it up. And there's little utilities available to portablize the links.
I've got a whole folder of them that I carry around. So there's really no reason to even use a wizard other than for the options the command line switchs don't provide, such as copying over the JPE runtime.
No, JPE AutoWizard do not create an empty app_jpe.ini. It add the configuration correspond to the user input. For example, if the user choose "redirect special folder", inside app_jpe.ini will beredllar wrote: You really shouldn't be creating an empty app_jpe.ini though as it can kill performance.
Code: Select all
[Filesystem]
Use=1
Data=.\Filesystem
But if the user choose "Do not redirect special folder", inside app_jpe.ini will be
Code: Select all
[Filesystem]
Use=0
The whole JPE AutoWizard works based on Firewrath guideline.
I mean ignore "Updates are written immediately". I've reviewed the Build Wizard code and that button's value isn't used in the current public version. Treat it as if it weren't there. Unless you want to use the command line version as your "server." Then use the readme as a guide as it's complete re: the switches.Do you mean that "keep portable registry in memory" should always come along with "updates are writen immediatelly"?
Yeah, I have a new version that I hope to get out soon. But I'm pretty sure your work will still be relevant since it's a single dialog box solution and is very useful for those that don't need all of the extra fluff of a normal wizard and also don't want to use SendTos or the command line version.But are you want to update your JauntePE? i dont know if my AutoWizard still relevan if new JauntePE is coming
No, it's not that. It has to do with the app_jpe ini and what's in it, if anything, in the way of module and/or registry includes/excludes to help the JPE runtime not have to go to the .reg file to process the literally tens of thousands of registry accesses that the Explorer shell dlls make on behalf of an app. This impacts app loading and app file system browsing. It's hard for me to explain unless you know how JPE handles the registry requests. That's why I need a whole separate topic to discuss it.But if running portable app from the "main JauntePE" can give more performance, i'll look into that
Sorry. No, I'm talking about the ability that Explorer and other file managers have. File->Send To under Explorer: 1) create a shortcut to the JPE exe, 2) add the required switches onto the end of the Target edit field, 3) move it to your SendTo directory, 4) select an exe you want to portablize, 5) File->SendTo->BuildPortable. Repeat 4 & 5 as many times as necessary. Something like that anyway.I dont understand in this sentence (hehe,still improving my english) :p . Is it SendTo target link is the *ini pointed to another *ini like example PStart1?
Sorry. I'm assuming too much again. This is basically the same issue as I noted above. Let me try another way of explaining it though. The more you, meaning the person attempting to portablize a non-portable app, can give the JPE runtime in terms of how the app uses the registry, the better. Because JPE is really, really, stupid. It needs help from you so that it can then skip as much code as possible that takes a lot of time to execute. If you don't provide it with any of this help then JPE needs to execute all of the code every time. You provide the help via the Module and Registry Include and Exclude sections. By creating app-specifc jpe inis without this help, especially those I provided through the distribution jpe_jpe ini, your forcing JPE to assume a worst case scenario and check every registry request the app makes against the .reg file. Even if it's in memory this is still very time consuming because JPE doesn't create a tree-structured virtual registry; it uses a simple file line-based linked list.No, JPE AutoWizard do not create an empty app_jpe.ini. It add the configuration correspond to the user input. For example, if the user choose "redirect special folder", inside app_jpe.ini will be
Code:
[Filesystem]
Use=1
Data=.\Filesystem
and a folder "Filesystem" will automatically created.
But if the user choose "Do not redirect special folder", inside app_jpe.ini will be
Code:
[Filesystem]
Use=0
and no folder is created.
I'm not placing blame here, other than on me. I'm just trying to correct some mis-understandings due to my poor documentation. I'm sure his guideline would have been a bit different. As would your app.The whole JPE AutoWizard works based on Firewrath guideline.
Does any of this help?
thanksBut I'm pretty sure your work will still be relevant since it's a single dialog box solution and is very useful
check, will be removed in the next versionI mean ignore "Updates are written immediately".
i'm interested, what else of the extra fluff i can add?...don't need all of the extra fluff of a normal wizard
aah..i know, i need to add more configuration in the app_JauntePE.ini..That's why in my readme i wrote "minimal configuration".The more you, meaning the person attempting to portablize a non-portable app, can give the JPE runtime in terms of how the app uses the registry, the better. Because JPE is really, really, stupid. It needs help from you so that it can then skip as much code as possible that takes a lot of time to execute
OK, should i add those configuration automatically or should i let the user add the configuration mannually as i instructed in my readme?However, you can choice to configure the app_JauntePE.ini manually. You might want to
1.Add the registry exclude in the app_JauntePE.ini (don't ask me why excluding this registry as i
get this configuration on reddlar's package. you can add or remove the configuration as you like.)
===============================================
[RegistryExclude]
1=HKEY_CURRENT_USER\Software\Microsoft\DirectInput
2=HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
3=HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
4=HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
5=HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam
6=HKEY_LOCAL_MACHINE\Software\Microsoft\Direct3D
7=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectDraw
8=HKEY_LOCAL_MACHINE\Software\Microsoft\DirectInput
9=HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
10=HKEY_LOCAL_MACHINE\System\CurrentControlSet
===============================================
2. FileSystem Exclude,Include/Ignore
==============================================
i. Run JauntePE.exe.Go to Settings > File System > Exception
ii. Add the FileSystem settings of your choise using those GUI
iii.When it is done, exit the JauntePE.exe and a JauntePE_JauntePE.ini will be created
iv. Cut the configuration in JauntePE_JauntePE.ini and paste it in the app_JauntePE.ini
v. delete the JauntePE_JauntePE.ini if you want
And one interesting idea is here
yes, really helpfull.thanksDoes any of this help?