PDF X-Change Viewer "portable", back to the drawin

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
User avatar
grannyGeek
Posts: 218
Joined: Mon Mar 26, 2007 10:54 pm

PDF X-Change Viewer "portable", back to the drawin

#1 Post by grannyGeek » Thu Aug 02, 2007 6:16 pm

My earlier effort (with big assist from FireWrath) to portablize this with JauntePE was pretty successful, but then I goofed it up when creating a new wrapper while working on a different computer, it started re-directing document folders again. (Just when I was going to add it to the “apps that work under JauntePE” thread )

So, I downloaded and installed JauntePE 011.
I used RegSeeker to clean out my registry, and started over, using Redllar's example ini.

PDF X-C is now working well. It is no longer locking me into re-directed folders within its own folder. Yay. The "FileSystem" folder I created in the app folder is still totally empty, so JPE does not create any re-directed folders.

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 :).

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.)


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
After running the app, JPE had added a setting for [SpecialFolders] with a list of approx 75 – 80 settings for Windows and Documents&Settings.


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??

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?

Since this app is actually working, I don't NEED fixes, but they would be nice.
Any advice for me?

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

#2 Post by redllar » Thu Aug 02, 2007 8:38 pm

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.

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

#3 Post by redllar » Thu Aug 02, 2007 9:08 pm

PDF X-C is now working well.
Hey gg, google doesn't think PDF X-C is an app. There is a PDF/X-3 Inspector in its results list though. Is that the app?

User avatar
grannyGeek
Posts: 218
Joined: Mon Mar 26, 2007 10:54 pm

#4 Post by grannyGeek » Thu Aug 02, 2007 9:36 pm

Hi Redllar, and thank you for such speedy response!
I'm sorry if my post was vague, I've been accused of being too wordy, and wanted to keep it concise. :)
you were running the app from a folder that JPE was told to redirect.

Yes, I had at first mistakenly told JPE to re-direct all folders, so then I couldn't access any folder from the PDFxc File> Open menu that had not been opened during its first run.
Is this a good thing or are you saying that JPE is not redirecting the file system properly?
Yes, a good thing --- Now I can access all document/data folders on any drive.
But it can't maintain the Most-Recently-Used file list on the Open menu. . . . . . . . . .
. . . . . . . . Could you please provide me with a "I want JPE to allow me to..." statement?
The PDF XC File menu includes a sub-menu for "Recent Files", and I would like JPE to let those Most Recently Used files be listed there. (if possible without breaking anything)

JPE had added a setting for [SpecialFolders] . . . . . . .
. . . . . . the 012 version of JPE no longer spits them out.
I just downloaded v 012, and will try it tonight.
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?
They are entirely from Explorer --- which is why I felt they were probably unavoidable.

I'll try discovery mode with v 012, and see how things turn out.
Thanks much.

whoops, just saw your new post --- again, so sorry for not including link earlier

http://www.docu-track.com/home/prod_user/pdfx_viewer/

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

#5 Post by crownixx » Thu Aug 02, 2007 11:32 pm

The PDF XC File menu includes a sub-menu for "Recent Files", and I would like JPE to let those Most Recently Used files be listed there. (if possible without breaking anything)
sorry to interupt, but i think i know what grannyGeek want. i already create the PDF XC portable using X-launcher, and of course with help of JauntePE capturing mechanism.. the Most Recently Used for PDF XC is stored here

[HKEY_CURRENT_USER\Software\Tracker Software\PDFViewer\Documents\LastOpened\0001]
"DPosX"=hex:00,00,00,00,00,d4,73,c0
"FileName"="E:\\My Documents\\BORANG.pdf"
"IPosY"=dword:fffffffb
"PageLayout"=dword:00000001


I can disable this using x-launcher by erasing the orange key in the *.reg file before PDF XC launch. But i think JPE still doesnt have those ability yet or is there other trick to do this in JPE?
JauntePE the portable maker: <<JauntePE Google Site >>

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

#6 Post by redllar » Fri Aug 03, 2007 4:59 am

Thanks for that info crownixx. JPE definitely should be able to redirect those entries. They're just normal user reg entries after all. Hopefuly they're just getting created by a system module that's not in the module inclusion list.

BTW, I have what I think is a neat idea for your build wizard I hope you're interested in. I just haven't had the time to post to your thread yet with all of this other stuff going on. It has to do with your scenarios concept you had explored earlier.

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

#7 Post by redllar » Fri Aug 03, 2007 8:20 am

Okay granny, I was able to verify that the app's "last opened" and "latest view" reg keys and data, which contain the mru and toolbar and pane associated info, are getting redirected into the app's portable reg. And it is the app's exe module that's processing the data. So the JPE runtime ini you created is good as it stands.

The problem is that when the app starts up and begins a conversation of sorts with the JPE runtime in order to retrieve this info, the app quits asking for the info pre-maturely. More than likely this is because JPE returned the data in a manner it didn't like or JPE gave it a return code that it didn't like.

So, it's definitely a bug in JPE but I think the problem is solvable. I just need to play computer a bit more to find the solution.

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

#8 Post by redllar » Fri Aug 03, 2007 2:35 pm

Good news gg.

I was able to figure out what this app does differently with the registry than any other I've run across and have gotten JPE to provide the app with the info it needs so that the app's MRU list is now being displayed and the toolbars and panes are now being displayed as previously set.

I still have some work to do because the change requires storing a registry key's class info into the portable .reg, but as soon as I get the code finalized I'll put up a new version for you to try out. Maybe by the end of the weekend.

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

#9 Post by crownixx » Fri Aug 03, 2007 5:43 pm

redllar wrote:BTW, I have what I think is a neat idea for your build wizard I hope you're interested in. I just haven't had the time to post to your thread yet with all of this other stuff going on. It has to do with your scenarios concept you had explored earlier.
yes, i am intersted.
it is ok..JauntPE priority come first. heard that mybe there will be v0.1.4
JauntePE the portable maker: <<JauntePE Google Site >>

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

#10 Post by redllar » Sat Aug 04, 2007 10:14 am

heard that mybe there will be v0.1.4
It's probably going to be 014 for some more JPE runtime changes and then a 015 for the gui. Then 020 for the plugin stuff then I'm done.

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

#11 Post by redllar » Sat Aug 04, 2007 11:01 am

@crownixx:

I don't know if you can do this with x-launcher or not but I thought I'd pass on the info to you just in case you can.

The PDFXCview app is making use of a reg key's class name for any of its numbered subkeys for the LastOpened, LatestView\Bars, LatestView\Panes, View\Bars, and View\Panes keys. It looks as if the app pulls all of the reg info into itself in one shot and then parses out the MRU, toolbar, and viewpane info based on the reg key class name, which for those numbered subkeys is "ParamItem".

So you will need to be able to save and restore the key classnames in order for things to work properly. At least that's the new functionality I had to add into JPE to get the portablized app to work like the non-portablized app.

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

#12 Post by crownixx » Sat Aug 04, 2007 6:19 pm

The PDFXCview app is making use of a reg key's class name for any of its numbered subkeys for the LastOpened, LatestView\Bars, LatestView\Panes, View\Bars, and View\Panes keys. It looks as if the app pulls all of the reg info into itself in one shot and then parses out the MRU, toolbar, and viewpane info based on the reg key class name, which for those numbered subkeys is "ParamItem".
urm..i'm quite dont understand what you're write there..
i did try to run the application and look into the registry but didnt find a single clue about reg key's class name(is it you register it in HKCR), didnt find the subkey "ParamItem" or MRU.... i'm just an amateur :p

could you post the exact registry
JauntePE the portable maker: <<JauntePE Google Site >>

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

#13 Post by redllar » Sun Aug 05, 2007 5:49 am

Unfortunately I can't post it for you as I'm on 2K and the 2K regedit doesn't give you access to any of the meta-data associated with a key, such as its class name or its security settings or its creation time or last write time, etc.

On XP you can get into regedit, select the "HKEY_CURRENT_USER\Software\Tracker Software\PDFViewer" key, and then chose File->Export. Make sure to set the "save as type" to "text files" and then select Save. Then open the text file it created and there should be a "Class Name:" line for each of the listed keys. Most of them will say <NO CLASS>, but the subkeys under the LastOpened, LatestView, etc. keys, should have a "Class Name:" of "ParamItem". That's the value I'm talking about. The app uses that class name value as a flag of sorts. Without that class name value the app won't treat any subkeys under the LastOpened key as ones that it adds to its MRU (most recently used) menu.

So you need a way to create registry keys that have something other than the default class name associated with them. And it has to be done when the key is created as the Windows registry api doesn't give you any way to modify that value afterwards. As far as I know there's no way to do that using regedit to "merge" a .reg file into the registry. I thought maybe x-launcher had this capability so I wanted to let you know about it.

User avatar
grannyGeek
Posts: 218
Joined: Mon Mar 26, 2007 10:54 pm

#14 Post by grannyGeek » Sun Aug 05, 2007 6:52 pm

Jeesh, I'm off-line for a couple of days, and look at all the activity in this thread.
Since I'm not a programmer, I can't take full advantage of the information posted here, and will have to "rely on the kindness of strangers" (Blanche DuBois said that in "A Streetcar Named Desire", and I take it as my mantra.)

I will poke around with JPE some more, and see how things turn out.

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

#15 Post by redllar » Sun Aug 05, 2007 7:30 pm

gg, I'm still plugging away at this app. I get the MRU list all the time now. And the portable .reg entries the app's creating all look good. But for some reason it's refusing to reposition and size itself properly now. So, still a work in progress. PM me if you want the latest JPE dll to play with.

Post Reply