PDF X-C is now working well. It is no longer locking me into re-directed folders within its own folder. Yay.
I suspect what happened earlier is that you were running the app from a folder that JPE was told to redirect. Like running the app from the desktop without excluding the desktop from redirection.
The "FileSystem" folder I created in the app folder is still totally empty, so JPE does not create any re-directed folders.
Is this a good thing or are you saying that JPE is not redirecting the file system properly?
But, a couple of minor issues, which probably just need an INI tweak, but I'm not sure how to handle them. Neither of them are deal-breakers, and I can live with these two tiny quirks.
1 -- When I re-open the app, and go to open a file, it will by default open the Most Recently Used folder. But it can't maintain the Most-Recently-Used file list on the Open menu. Those files also do not appear on the Start Menu “Recent Files” list. And on second “stealthy” thought, I am happy that they don’t show up there Smile.
Sorry, me being thick here. Thanks for the info you've given, but I can't figure out what exactly you're asking for. Could you please provide me with a "I want JPE to allow me to..." statement?
2 -- It does not remember custom toolbar layouts, but always returns to default settings upon re-opening. (this might be a quirk of the app itself, I've never used it on a "normal" install, so can't be sure.)
The app probably isn't storing the toolbar info into the registry itself but is using one of the system dlls to do it. I think it's comctl32.dll so you might try adding that to the ModuleInclude list. You might also try JPE's Discovery mode since it will tell you what modules are doing what to what registry keys. Meanwhile I'll download the app to make sure and then get back to you.
This is the INI file I created :
Code: Select all
[Registry]
Use=1
Data=.\_Registry\PDFXCview_registry.reg
[Filesystem]
Use=1
Data=.\_File System\
[FilesystemExclude]
1=*
[FilesystemInclude]
1=26
2=28
3=35
[ModuleExclude]
1=*
[ModuleInclude]
1=PDFXCview.exe
2=ISTask.dll
Yeah, this looks to be a fairly good, minimalist starting point, if you are reasonably sure that the app is only storing file system data in the %appdata% folders and that all app-related reg mods are being made by those two modules. But keep in mind that not all apps are built the same. Unfortunately there is no "one size fits all" when it comes to portablizing these apps.
The other approach is to initially redirect everything, find out what the app's using re: the registry and file system, and then pare down the ini to eventually only include those paths. I hope to have a new Discovery mode option in place soon that will help create inis based upon this approach.
After running the app, JPE had added a setting for [SpecialFolders] with a list of approx 75 – 80 settings for Windows and Documents&Settings.
That output was an idea I had to help portablize non-portable paths that non-portable apps like to store, such as for their own "most recent" file lists. But, since that output was taking up a large amount of a JPEized app's startup time, especially from a flash drive, the 012 version of JPE no longer spits them out. So you might want to grab that version when possible.
I did a "first-run" snapshot compare using RegShot --- almost all the entries are for MRU items ---
can those even be avoided? Would we even want to avoid them??
Are they from the app's MRU list or explorer's? The app's MRU can probably be redirected if you want to. Whether you wanted them or not would depend upon whether you find them useful when re-running the portablized app.
If they're explorer's MRU reg entries, such as the "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StreamMRU" entries, then I can't remember whether they can be redirected or not. It depends on when, in an app's life cycle, they get created. In any event, I don't think you want them in the portable .reg, as they're not useful to the app. I had an idea a while back about having a new JPE list for these types of entries, and JPE would make sure that they were not put into the portable .reg or the system reg. This would make for a more stealthy portablized app. For now, I'd say they should be added into the ini's RegistryExclude list so that they don't get put into the portable .reg. Take a look at the JauntePE_jauntePE.ini that's in the JPE zip and you'll see a number of reg keys like those that I added as initial RegistryExcludes.
The one entry I do wonder if it should be re-directed is
C:\WINDOWS\system32\config\software.LOG
Is that possible? Is that desirable?
I'm not sure, but I don't think it's possible to redirect that file's modification with the api-hooking dll I'm using. IIRC, it's being modified during the initing of one of the system dlls, so that piece of code gets executed before any of the JPE runtime code even gets started. As for whether it's desirable to have it redirected or not, I'm afraid I can't say as I don't know what Windows is using that file for.