JPE AutoWizard v2.0.3 -no longer support-

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

JPE AutoWizard v2.0.3 -no longer support-

#1 Post by crownixx »

JPE AutoWizard v2.0.3

Image

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.

User avatar
nycjv321
Posts: 181
Joined: Wed Feb 15, 2006 12:42 pm

...

#2 Post by nycjv321 »

cool thx gonna try it out later

rilwis
Posts: 7
Joined: Sun Mar 18, 2007 11:26 am
Contact:

#3 Post by rilwis »

Thank you very much. It makes everything easier!

GiGi34
Posts: 2
Joined: Tue Jun 19, 2007 8:11 pm

#4 Post by GiGi34 »

Where can I donwload Autowizard?

I cannot find the download link anywhere

GiGi34
Posts: 2
Joined: Tue Jun 19, 2007 8:11 pm

#5 Post by GiGi34 »

Sorry. I said it wrong.

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

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Suggestion

#6 Post by Zach Thibeau »

Just a little Suggestion try rewriting your autoit script so that it runs the command line version and makes it more slient ;)

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

Re: Suggestion

#7 Post by crownixx »

thibeaz wrote:Just a little Suggestion try rewriting your autoit script so that it runs the command line version and makes it more slient ;)
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.

or if you know about the parameters used, mybe you can help me out. :)
GiGi34 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
mirror added. look into the first post

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Sure

#8 Post by Zach Thibeau »

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++ :D if so we could work on Translating your wizard into C++ :D if not I understand ;)

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

Re: Sure

#9 Post by crownixx »

thibeaz 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.
the command parameters suppose can be found in the redllar's readme

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
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
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.
i dont understand. Do you mean that the keyboard command in GUI is the shortcut key (like alt+n)?
we can only used the switches/parameters for the JauntePE_commandline.exe
thibeaz wrote: Have you ever decided to work with C++ :D if so we could work on Translating your wizard into C++ :D if not I understand ;)
sorry i dont know C++ :lol: but why you want to translate it to C++?

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Well

#10 Post by Zach Thibeau »

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

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

#11 Post by crownixx »

UPDATE
change the download package. i have to respect JPE licence and madhook licence

thibeaz,
see you in pm :D

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

#12 Post by redllar »

reddlar's readme lack of information about the command line version
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.

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.

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

#13 Post by crownixx »

redllar 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.
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 coming
thibeaz,
There you go. You got yourself somethings to work out
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.
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..
But if running portable app from the "main JauntePE" can give more performance, i'll look into that
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.
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: You really shouldn't be creating an empty app_jpe.ini though as it can kill performance.
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: Select all

[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: Select all

[Filesystem]
Use=0
and no folder is created.

The whole JPE AutoWizard works based on Firewrath guideline.

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

#14 Post by redllar »

Do you mean that "keep portable registry in memory" should always come along with "updates are writen immediatelly"?
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.
But are you want to update your JauntePE? i dont know if my AutoWizard still relevan if new JauntePE is coming
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 if running portable app from the "main JauntePE" can give more performance, i'll look into that
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.
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. 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.
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.
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.
The whole JPE AutoWizard works based on Firewrath guideline.
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.

Does any of this help?

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

#15 Post by crownixx »

But I'm pretty sure your work will still be relevant since it's a single dialog box solution and is very useful
thanks :D
I mean ignore "Updates are written immediately".
check, will be removed in the next version
...don't need all of the extra fluff of a normal wizard
i'm interested, what else of the extra fluff i can add?
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
aah..i know, i need to add more configuration in the app_JauntePE.ini..That's why in my readme i wrote "minimal configuration".
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 ;)
OK, should i add those configuration automatically or should i let the user add the configuration mannually as i instructed in my readme?
And one interesting idea is here
Does any of this help?
yes, really helpfull.thanks

Post Reply