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?