Don't worry about that. We need to see if we can even get it working first. Performance issues come after.


This is all very confusing and wasn't really what I was talking about. I was suggesting that you get a feel for how JPE can affect explorer by seeing if you could see the fake drives that the jpeCrypto plugin creates from within the explorer window. That's it. That one simple test. I don't even know what to say about all of that other stuff you tried. Of course it won't work. Something as complicated as what you want to do has to be approached in a logical manner to make sure you know exactly what's going on at each step. And it needs to be properly researched so that a proper jpe ini can be created for explorer.


ARGGHHH!!!! Sorry. I just had to get that out.


regedit browses the registry. Which is different from most regular apps that just go after specific keys. As a registry browser, it needs to be given the entire key hierarchy in order to be tricked into thinking that the .reg is in fact the system registry. That's what the currently disabled code does.

Also, what did you do to ensure that regedit was using a sensible jpe ini? The one provided won't do the trick since that's for running regedit against the system registry.

But if you still want to try this I can walk you through the manual steps necessary. It's not pretty though. That's why I wrote the code to do it for me.

Oopps, I thought the doable in "But I know this is doable..." was about the context menu.

Sorry, I used the wrong word. I didn't mean it would import to real reg and file system like normal wrapper. Import, I meant was import in RAM for that JPEized application, set the reg & file system using RAM redirection (maybe?), so that when JPEized app read reg it would read the JPE-reg.

I would like to try as I would want to JPEized GeoShell, but doesn't have to be now. I see you are quite busy, so better next time. Thank you for the offer.

My bad as well. But I am going to try and figure this out. It's a neat idea. It's just going to take some time.


Ahh! A light bulb just went off in my head. You were thinking that JPE works by creating its own entire in-memory registry for use by the app? No, that's not how it works. That would take too much memory and it would also lead to other problems I won't get into. What it does is very simple:

1) an app makes a request to make use of a registry key

2) JPE looks in its own portable registry for that particular app to see if that key exists - that portable registry only has the contents of the .reg file (plus any previous mods to it made by the app that got redirected) - also, this portable registry might exist in the file system or in-memory - it depends upon the in-memory portable .reg usage option in use

3) if the key exists there, then JPE tricks the app into using it so that all subsequent accesses using that key are flagged as "in portable - not system"

4) if the key doesn't exist there, then JPE passes the request on to the system registry api function that will then process the request normally.


No, I'm not that busy. The steps are pretty simple but the amount of work you have to do is potentially not, as you're going to have to edit the .reg twice. I'll get something together and post again.

Thank you, I also I believe this would be very useful.

I'm not clear with what normally means. Doesn't JPE would redirect any registry related from the JPEized application, even the key is not available in the portable reg?
I created this thread for ObjectDock, maybe it would be better to continue our conversation on a special thread that would explain how JauntePE works? As this info will be useful for many to understand JauntePE more.

Also, I was thinking, maybe it would be better to create a new thread about JPE options? I mean regarding [RegistryExclude], [RegistryInclude], etc. Explaining it would do good and it would be easier for people to get.

It seems someone is also curious about the JPE.reg. I believe it would be better to explain the reading portable registry using regedit on that thread, here.

EDIT: Like other software's forum, what about important threads made sticky. And maybe feature requests thread?

Besides just file types & context menu, what about the start menu & desktop icon? So if user run JPEized app, it will virtually create start menu & desktop icon(s). Could be useful for users who are not experienced with XP yet. But again, they might not really care about stealth or clean PC. Not that important tho, the idea was just crossed my mind.
Anyways, good luck. And thank you again.

Nope. Simple requests for info that don't result in changes will go to the portable .reg first. But if the requested info is not found it's sent on to the system registry. Your apps wouldn't work otherwise. There's just way too much registry data that a Window's app must have access to in order to run properly. Almost all of that comes from the system dlls though, not your app's code.


There's already a few of those in this forum. If you ask the questions I'll answer them where ever you post them. I'd actually much prefer "documenting" JPE this way than my sitting down and trying to come up with something cogent. Because I'm really, really, really, bad at that. And I hate it besides.


I think there's one of those as well. crownixx had a lot of questions back when he was still interested in JPE.


Okay. I have good news/bad news about that anyway.


Gotta ask the admins to do that. I don't any of them but Andrew cares about JPE.


You can already get those if you run the app's installer through JPE. We had an idea way back when of creating a virtual desktop for people to run from. But almost everyone wanted/wants to be able to just run the app's individually, but portably. I always thought that a Ceedo-like desktop thingy would be a neat addition to the JPE gui. Maybe as a 020 plugin.

Any suggestions for important threads that we should make sticky?

i'm still here and always be JPE fan
yup, last time i ask about [RegistryIgnore] in the "Best Practice Building JPE app" and Andrew came to give the example. forgot to say thanks last time, so thanks Andrew

_________________
JauntePE the portable maker: <<JauntePE Google Site >>

I see, and if the request makes changes, it will be put in the portable registry.. depends on the runtime settings. If RegistryExclude contains that key, it won't be redirected, right?

Yes, I saw the thread explaining about RegistryExclude & Include. That's why I was thinking to gather the info and put it in one thread with related title, if it's okay with you I don't mind doing it. Can benefit all of us. But I'm actually hoping that Firewrath would do this, like he did on JPE instructions as he has more experience... hope he read this. ^_^
Or maybe only 1 thread contains various topics with links to the related threads. That way no one has to do documentation & others could know what and where to read.
And about crownixx, I do believe crownixx is still interested in JPE.

Thank you for the quick response, Andrew. Maybe "Understanding JauntePE better" created by crownixx, as it has some important information about how JauntePE works. But I guess better wait for redllar about this and I was thinking to create a thread explaining the runtime settings and perhaps also about how JauntePE works.
And, I dunno, maybe make redllar as one of moderators for the "JauntePE Discussion" sub-forum would be nice, as he can decide what conversation is useful and what's not. But depends on redllar tho, maybe he's already busy or not interested.

EDIT: See, I was right about crownixx. Once you hooked up with JPE, you never can get away.

Yep, you got it. The only thing I'll add is to remember that the Registry Exclude, Include, and Ignore keys given are treated as parent keys. So all of the keys below them in the hierarchy are affected as well. Ditto for the file system stuff.

So if you put HKEY_CURRENT_USER\Software into the RegistryExclude list, you're telling JPE to not redirect any mods to that key, and to the HKEY_CURRENT_USER\Software\Microsoft key, and to any other keys "below" HKEY_CURRENT_USER\Software.

Let me just say now that I have no plans on pulling all of this info out and trying to make some sense of it. :) That's too much of a task for anyone, imho. It is a great idea though. I would even be willing to html-ize it once it's done and put it into a new and improved JPE readme.


Yeah, I see he just posted about that. Sorry crownixx. I was trying to make sure you weren't pulled into a discussion that you might not be interested in anymore. And while I'm at it, I'd like to say I'm sorry for my post(s) to you on grannyGeek's thread about that PDF app. God knows JPE can use all the help it can get from you guys. So your work with it is very much appreciated by me and the others.


I'd prefer to stay out of the way of you guys as much as possible. What I wanted to do when I came here was to fix bugs, put in new functionality, put out new releases, and pass on as much info as possible. I can stomach the "off the cuff" questions and answers stuff for as long as you guys can. But I absolutely abhor and am terrible at any organized documentation. I just get bogged down in the specifics and can't find my way out.

Yes, I got it. I even tried to Exclude a parent key, but Include the subkey (child key) of that parent; and it works great (I tested with regedit).
The only thing is that when I run JPEized regedit with that runtime setting, regedit doesn't show that the subkey is available (even though it is in the system registry), until I add a new key via regedit.
I know this probably is the "browse" problem you mentioned, just maybe you would get something from this info for the future.
So, Excluding a key parent and Including the child key, would create browse problem for the child key.

Regarding the jpeCrypto, it's cool & useful for apps that use non-relative path. Would it be able to be used on an available drive? I mean as you know I'm using EWF, which would decrease RAM if something writes to system partition; and you were able to JPEized every process. So, maybe jpeCrypto could actually make EWF-system to run like normal system, while maintaining EWF's features.
Or for live XP CD. As CD is read-only, maybe with jpeCrypto, user and system are able to write to the system-partition where it actualy writes to harddisk.
I know it's not related with portable and I'm not requesting it... yet , just want to know your opinion about this.

EDIT: Sorry, if my last question doesn't make any sense.

The whole thing with the 020 plugin capability is to move JPE away from portablization-only ideas. Anyway, I'm not sure what the answers are as I haven't really thought about doing such things. And I don't know how EWF works so I can't say. I had thoughts along the live CD idea but mine were to use an iso as a fake CD drive, like VMware does.

Basically, what EWF does is redirecting any writes or changes in the protected partition (system partition for me) to RAM. And when I restart, as RAM is cleared, the protected partition will be reverted back like the original state when the EWF is activated.
That's why, JauntePE is perfect for systems that use EWF as JPE prevents any writes to the system. This would be very good for XP on USB.
If somehow you are interested in EWF I would be happy to explain more to you, I have some tricks up my sleeve. Like, I actually set my shell to a script (in non-protected partition) that I create to launch applications, so I can set what application or shell to launch on startup.

Regarding Registry redirection, I believe this key is not important "...\CurrentVersion\Explorer\MountPoints2\E". But, if it is in the JPE-reg, it means that the application tries to make change to that key.
If I put the key to [RegistryExclude], there will be write to registry, right? On some keys, like directx, DirectDraw, ActiveMovie I deny their registry permission to prevent write to system registry and till now my apps work okay without problem.
So my question is, would it be better to put it in [RegistryIgnore]? What do you think about the performance?

EDIT: Maybe option to put redirected file system in RAM, would improve FileSystem redirection's performance. Obviously, this option would be used for application that redirect small size filesystem.
Or, user could put the maximum size, example: 3 Mb. So, if the filesystem that would be changed is bigger than 3 Mb, it will not be put in RAM, just would be redirected normally.

One more question, using JauntePE would make the application to be 100% stealth, right? I didn't check yet as I deny reg permission on unneeded keys & perhaps there are entries that are not from the application but is written when certain condition of system is met by running that application.
Thank you.

Okay. Thanks. I'll PM you if I need more info.


Well, yes and no. Technically that is a key that the explorer shell dll's modify while running within the app's process space, meaning that it was the app trying to make the change but it wasn't one of the app's modules, it was a system module. Those reg entries get updated by the shell dlls every time you use one of their file system "browsing" dialog boxes like the standard Open File and Save As ones.

You should probably take that key out of the .reg because it may potentially cause problems if you try to run the app with that .reg on another system. It being in the .reg means that somewhere along the line of running the app, either the shell dlls registry accesses were redirected completely or the default set of registry exclusions that comes with JPE were not in use, but some subset were. There's probably more in there that shouldn't be. Really, under normal conditions you don't want anything from explorer in your .reg.


If the shell module(s) that write to that key aren't included in redirection. And assuming you're not using the .reg across multiple apps.


As a general rule I'd say that the explorer keys should not be redirected as they are integral to file system browsing. Ditto for the DirectX keys for the same graphics-oriented reason. That's why I had them in the default JPE runtime ini. I don't think that preventing them from being modified in the system reg makes the app more stealthy and all it does is clutter up your portable .reg with potentially portablizing-harmful values. The system already knows you've popped in a removal drive for instance. The system already knows that you're running a DirectX app. There are things "beneath" the level that JPE operates at that go on that you just can't affect unless you write a kernel mode driver. But ultimately, as long as you understand what list is used for what purpose, it's up to you.

Performance-wise, the more stuff you redirect the more work there's to do to see if that "thing" has or has not already been redirected. And the ignore list is only used after it's already been determined that the thing does not exist in the portablized data. So the only time savings for registry keys would be the access to the system registry, which would be an almost unmeasurable value since the system's registry is highly optimized. The overall best performance would be to make sure that the shell dlls are completely excluded from any redirection efforts.


I've already looked into this and there may be a future option that will significantly help with file system redirection performance. It won't be an in-memory file system; to me that's a last resort option as it involves duplicating what the OS already does for you. It will be more like what I'm doing with the registry accesses. Just enough to find out quickly, using an in-memory list, whether or not a directory or file already exists as a portablized directory or file, as that's where most of the time is being spent right now when a request for a potentially redirected file system object is being made.


It depends upon your definition of stealth. It is absolutely impossible for the system to not know certain things. Even if JPE was running in kernel mode and hooked into every running process there would still be registry and file system modifications going on that it could not prevent. The only way to do that would be to write drivers that completely replaced those sub-systems of the OS. And I don't think it's even possible to write a driver to replace the registry.

JPE will capture and redirect a lot of stuff if you completely blank out all of the JPE runtime lists, but not everything. There are also certain modifications that it can't redirect at all because they happen before the api-hooking takes place. There are ways to prevent this but it's not worth the time right now as the app's doing this are minimal and don't really do enough to hurt portability.

I don't mind actually, if the system knows what app I run, as long as the app and the system do not write or leave anything which could lead to system slowdown or for my case, EWF decreases the RAM. That's why I set the registry permission, so there would be no writes. As I want no trace or writes, maybe better to call it clean instead stealth. But unfortunately as you said, it is difficult to achieve.
So, if I don't want my system partition and JPE-reg to be written by system modules (the explorer shell dll's, etc.), what should I do?
I know I can just set as read-only, but I wonder is there another way.

I was thinking, maybe as registry is small, put it in the RAM.. then, there would be an option to discard the changes upon application exit. That way, the portable and system registry are clean from changes.
And this could help in this case:
JPEized OSK keeps the keyboard position in the portable registry. Sometime I move the keyboard around, so on app rerun the keyboard is not in the default position. I put the JPE-reg to read-only so it can't keep the new position. But, if I set the JPE-reg as read only, it would complain "Registry access error". I think, using above suggestion could overcome this problem.
This also can be taken care of by using simple script, that would delete JPE-reg after the OSK exit and restore the original copy. But, it is not good if used on USB as USB's writes is limitted.

Or, maybe new runtime setting, [RegistryDeny] to deny write to that key by the JPEized app.
Use this if user wants to keep the settings for application that not similar to OSK, because OSK will surely complain.
And combine this with [RegistryIgnore] would result like setting registry permission to deny write and read. And I guess, the same as put JPE-reg read-only, but with difference user can set what key specifically.
Just suggestions that are not fully thought through because the lack of knowledge, but hopefully could be useful.. somehow. ^_^

EDIT: I just checked my email. Thank you for the new version, I will test and let you know if there is something.

EDIT2: You already implemented my suggestion before I even thought about it. I tested with OSK using MemRegistry=4 and as usual it works wonderfully. Thank you for this.