OD is working fine for me under JPE, so I know it can be done.

I'm at a loss as to what to suggest next, other than to start over. Once things get to this point it's hard for me to suggest "a fix" without actually being there to make sure things are set up correctly. I think what I need to do is enable some of the logging for you so all you have to do is post the log file contents.


Yes, that's what I meant, the creation of the ObjectDock_portable.exe file.


What's the name of the app and where can I find it? I suspect that that type of app can't be JPEized as it's probably having one of its dlls injected into the processes of all of the windows it's managing, and it's from within that dll that the system registry writes are being made.


I'm getting all of those files redirected properly. The backup file just shows up in the log files but it's always showing up as a redirected path. OD eventually deletes it though.

You are right, I tried to recreate everything from beginning and it works. I did some test drive with it, but sometimes the applications that I run via JPEized OD go hang. Example, Internet Explorer, it happened after I opened some apps, but not when I run it immediately.
I will do some tests again later and also tests by using the AppsName_JauntePE.ini and will report to you.

Here is the application I told you about. JPEized it and try to open few Windows, it would write to Windows Registry.
I believe, it would be a good idea to have log version of JauntePE or as options. I'm hoping that EWF won't be effecting any virtualization of JauntePE on my PC.

EDIT: After some little test, it seems the Internet Explorer works fine now. I didn't know what happened. And one thing I'm sure is JPEized applications run via the JPEized OD couldn't read its JPE reg file.

And I was in a state where I could not re-run ObjectDock_portable.exe. When I run the JPEized OD, in the task manager it shows Objectdock.exe and Objectdock_portable.exe. But then it shows warning dialog saying "Failed to retrieve the application's settings from the launcher process". So, I decided to try to use Unlocker on JPEized OD, it was used by file manager & System. When I tried to unlock it, it shows that many instances of regsvr32 are using it. After unlocking it then I was able run JPEized OD again. I tried but I couldn't recreate that state again. Hope the info could help debuging or something.

Anyway, thank you for helping me solve my OD problem. I got nothing to complain; as regarding me unable to run JPEized apps, I could use OD to JPEized and store the registry settings in the OD reg dir. I will try to do some more tests and if something comes up I will report to you.
Thanks again, redllar.

You're welcome.

I took a look at that window manager. You won't be able to JPEize it as it does as I thought and has Windows hook one of its dlls into every window'd process. To get JPE to handle such a situation would take more coding than it's worth. What you might want to do is look for alternatives. All those Actual Windows guys have done is take ideas created by the freeware devs years ago and copy them and then try to charge you for it.

I understand a bit now. The reason why I said that JPEized app run from JPEized launcher (OD) couldn't read the JPE-reg was because I didn't have the setting.ini in the application folder. So, the application uses JPE-OD ini setting, especially because I use JauntePE_JauntePE.ini in the OD folder.
So, after I create JauntePE_JauntePE.ini in the application setting, I could run and get its JPE setting. But, when I ran it via JPEized OD, the JPEized app doesn't immediately open. The app I did some tests was tightvnc. In the taskman, it shows vncviewer_portable.exe and vncviewer.exe. The vncviewer hang and what I did was run another application from JPEized OD, and the vncviewer opened it's window or resumed from hang. But after doing this, the Internet Explorer will not run if I run it via JPEized OD (the IE is not JPEized).

Then, I tried to run vncviewer.exe (not the JPEexe). It runs good no hang like the JPEexe, but I surprised that it still reads from the vncviewer JPE-reg not from the real Windows Registry. So, I assume that even though I add [ModuleExclude]1=* & [ModuleInclude]1=ObjectDock.exe, JauntePE still tries to redirect another .exe that's being run & has .ini in it.
That is cool as I can redirect any software launched via JPEized OD only by adding setting .ini in the application folder. However, I was thinking maybe it would be a good idea also to have an option to completely ignore all the exe or child process. Dunno if possible, but that way user could choose to use real registry or JPE-reg only by choose what to run & maybe it could increase performance as other exes are not being dlled?
Just a little suggestion, hope it could be useful somehow.

Regarding the Windows Manager (WM), I did a test to actually deny any permission to the registry on the app's key. The result, it works okay, didn't try for long tho. But it could resulting to make another already-running-JPEized-apps to have the WM registry in their JPE-reg. So, you are right, I guess alternative is necessary.

Yeah, I was going to suggest this in my last post, as I suspected that's what you were trying to do via the module lists, but I forgot about it. The option is actually already there in the runtime. I just need to add an ini setting for it and make the changes for the gui.

If you're running an app directly from its exe, I don't see how anything related to JPE could be involved. You have to launch the app via a JPE-built launcher or via the JPE launchpad in order for the JPE runtime to get into another process. Maybe what happened whas the vnc process from the prior JPEized run was still in memory and it just picked up from there. You might want to reboot your system, or at least use Process Explorer to make sure the JPE dlls are not in any other processes before you run anything else though. I'd hate for you to end up with a huge portable .reg with a bunch of useless entries in it. Not to mention the system slowdown you'd experience.

What I'd suggest for now is that you put off this idea of yours until I get the new setting in place. Or you can do as Firewrath does and create app-specific inis for all of the OD-launched apps. Or just toss JPE out the door and get one of the script kiddies to write you an OD launcher.

Of course I will choose JauntePE, I'm not that stupid to use OD launcher when I can use JauntePE. I'm a person who likes clean PC and appreciate very much the beauty of real stealth. And I'm using EWF, so the more things go to the OS, the less RAM I will have.. that's why for me your JauntePE is a Godsend. Please don't think that I would put JauntePE and normal wrapper in the same level.

Sorry, forgot about posting back about this. Did you try my Process Explorer JPE ini I posted here? It seems to have worked for others besides me. It also could be that you're running a newer version than what I have, and that you're running into the same bug that was found when running SysInternal's Process Monitor. So you might want to try turning off the in-memory .reg usage and see if that solves the problem. That's about all I can offer as I don't have any problems with it here and I've been using it for close to a year with JPE.

I have forgot about Process Explorer too. I used it only for testing purpose. I tested again using JauntePE_JauntePE.ini and using ObjectDock_JauntePE.ini, I got no strange behaviour at all. I'm sorry for the false alarm, but I could swear that it did happen. Perhaps it was cleared when I re-do everything from beginning.

I mean I'm running normal exe via JPEized-OD. Each time there is AppName_JauntePE.ini or JauntePE_JauntePE.ini in the same folder with normal exe, the ini will be read and executed.
So example: I run osk.exe via JPEized-OD. If there is no ini file in osk folder, osk.exe will not be redirected. But, if there is osk_JauntePE.ini or JauntePE_JauntePE.ini with setting to redirect osk.exe, the osk will be redirected.
That's why I thought, perhaps completely ignores any exe or child process could be a good idea. So, I could easily choose to run JPEized-osk or normal osk by choosing to run osk.exe or osk_portable.exe only, not editing or renaming the ini file.
So, basically I got no problem at all with OD and the current build, only very curious with the ignores all exe and child process.
Thank you again.

Also, maybe it is a good idea to make it so that JauntePE will create the registry folder automatically. As you know I use in the ini:
as template. If I didn't create "JPE-Registry" folder prior to running the JPE-exe, the JPE-reg will not be available, thus it resulting the same like what I experienced in Process Explorer.
But again, this could be useful to use for applications in public places, so no settings from prior user will be saved. However I noticed that for file system, the folder is automatically created when I exit the JPEized app. I tested this on OD only tho. So perhaps option to discard any registry and file system created from memory, to keep the application runs like the first time being run & preventing disk write on USB.

One more thing that I was wondering, is it possible for JPEized app to be available in the context menu and File Types? Tried to do it with Winamp, but I think I was unable to. I think I did register FileType for JPEized Winamp but I think it needs previous entry, not sure, & will do some more test on this. Perhaps special stealth application for JPEized apps' Context Menu & File Types?

[EDITED]

Sorry, just running through the posts real quick and this caught my eye. I'll try and get to the other points later.

This sounds interesting but I need more info. Whose context menu? The apps? The windows desktop? I think maybe you mean the shell's start menu, since you reference file types, but I'm not sure, since you reference Winamp as well. Are you talking about the open/save as dialogs?

Sorry, I'm old and slow and need specifics to get the idea through my thick skull. Too much head butting when I was younger.

Hmm.. I think, it is shell api. Hopefuly Fast Explorer could give you the idea what I was talking about.

So, basically I was thinking this special stealth application (SSA) could :
1. Handle JPEized apps that register to file types or any file types.
Example:
a. In the Winamp, if someone installs Winamp. User could choose only by double clicking mp3, it will run Winamp automatically.
b. For .avi file types. When I run the SSA, it would link .avi with application I set (ex. MPUI). So when I double click any .avi it will not open Media Player but MPUI.

2. Handle JPEized apps that hooked to shell api (context menu) & also able to create own virtual context menu.
Example:
a. Winamp has option to "Enqueue to Winamp", "Play in Winamp" context menu when I click mp3.
b. Unlocker. I could set whenever I right-click any file, it shows option of unlocker. But when the SSA is closed, the right-click will be gone.
c. Winrar, etc.

I think, with this user could have his or her own environment thingy. So users could just plug the USB on other compy, run the SSA and can easily double click any file types without worries. When done, just turn off or if hang it's okay as it doesn't write anything to host PC.

EDIT: I did some little test regarding the file types and context menu.
I have 2 copy of winamp, call it A & B. I manually registered file types & context menu for Winamp A. And when I run JPEized-Winamp B (with file types & context menu enabled), the file types & context menu that I created for Winamp A will be linked to Winamp B. But without registering manually, running JPEized-Winamp B alone won't show context menu or linked file type. Hope could be useful.

I like this idea. It fits perfectly into the 020 plugins framework. I would have to modify the JPE launching mechanism so that it would inject the requested plugin(s) into existing processes. In this case the explorer processes. The plugin would feed off of the app's .reg that had the HKCR file type info in it and pass that info to explorer so that it would treat them as if they existed in the system reg. You could then build a portable exe and that would be your SSA.

BTW, you can sort of do this now but I'll get back to you as the JPE runtime ini for explorer will need to be specially crafted to make sure it doesn't intefere with explorer's normal operations. I also know that you'll need to change explorer so that it makes use of the "launch folder windows in a separate process" option, if it's not set already.

But I know this is doable since I've alread done it with the jpeCrypto 020 plugin. Try it yourself if you'd like, just make sure that option is set and that all explorer folder windows are closed before you launch explorer from the JPE launchpad. What you should get are the 3 additional jpeCrypto drives listed in the explorer window.

I understand, so for the file manager the .reg would be from JPE.
I was also thinking for global applications. So, it would not only for the applications I set but for all applications that read HKCR. This could be very convenient as not only file manager would read that reg key. I guess, it can be set what applications would be effected by the JPE-HKCR, but.. maybe, if it can effect globally to all applications, it can be good. What do you think? Again, I'm not an OS expert. I can only try to trigger you so you would get ideas or thoughts, as I don't know if what I suggested is efficient or logically possible.

I will also try to start using and learning to use version 020, is there any difference in performance than 0.1.3?

EDIT: About the JPE-reg type. I think I know why you use hex, I did find a character that is not exported correctly to reg file. But I was thinking maybe it would be useful if JauntePE able to read other than hex, can be easier if user wants to edit the reg manually. I mean to read JPE-reg I would have to convert the hex to string first. If it's effecting the performance, better not. Not a biggie tho, it was just on my mind.

Yeah, that's definitely doable too. We had one test last year where every single process was "JPEized." I only had it draw the frame border and icons, but it was kinda neat to be able to start any app and see its window modified, even command prompts from the start menu. The madCHook library is amazingly powerful and stable, which is why virus writers like it so much. Making it work with some processes would require admin privileges though, so there would be limits.


The 020 build is just a play thing to primarily introduce you to the plugins-usage concept. Once I get it released it will have the same performance as the 01* releases. So just unzip it into its own directory for now and play with it. I wouldn't spend too much time with it just yet. But try out the explorer thing if you understood what I was getting at.


The hex is used so that I can put unicode strings into ascii files. If I used the normal .reg syntax for a string I'd need to complicate the code to handle both ascii and unicode .reg files, and that would be dependent upon the OS in use. At one time, and still maybe, I had plans to port JPE to 9x as well. So I wanted any easy way to use a .reg on all Windows versions, which meant either using an ascii file or creating my own virtual registry file structure, which I thought was overkill for an alpha app, or complicate the code with ascii and unicode file handling capabilities. I already have the code for that, I just didn't want to bloat the JPE runtime with it just then.

It's possible to edit the .reg manually via any recent .reg editor. I'm pretty sure there's a few freeware ones available. I made one myself a while back but never released its final version due to lack of testing. I use it daily for viewing the .regs. I'm not sure how comfortable I'd be with using it for editing purposes.

Also, there's a feature in the JPE runtime, that's currently turned off, that allows a standard registry browser, such as regedit, to be used against the .reg as if the .reg was the entire system registry's contents. I hope to one day re-enable that so all you need to do is JPEize regedit and tell it to use the .reg that you want to edit. I'll probably strip that code out and make an 020 plugin out of it.

On second thought, would it decrease the performance if being hooked more than once? I mean hooked by the ContextMenu & FileTypes, and its own redirection. Maybe it would be much efficient to define what process would use ContextMenu & FileTypes than hooked it to all process.


I think I understand the concept, but I encountered problem in the testing. So, here it is:
I put explorer in the JPE launcher. Run the explorer, import file type & context menu .reg. Tried the right click, but it didn't show the menu I registered using the .reg.
And I noticed something. Each time I choose play & media player started, every explorer I started would be in JPE mode with border & icon. I tried to open it via GeoShell menu (I'm not using Explorer as shell) and taskman. The taskman itself has no border, I even try to choose the explorer.exe in Windows folder (not just by typing explorer in the taskman).
If I didn't choose to play or Media Player didn't start, the explorer I opened via task man & GeoShell would be normal.
I was able to reproduce the problem few times: drag explorer.exe to 020 launcher. Launch the explorer via launcher->right click any .mp3->choose play. After Media Player started, close the Media Player & run explorer via taskman.

This surely be very useful for application that stores settings in registry and doesn't have the GUI that covers it. Like Geoshell or Xplorer2.

I did a test with regedit.exe, but using OD JPE-reg. I could not find the OD JPE-reg entries when I rename OD JPE-reg to regedit_JauntePE.reg. So, JPE doesn't import the JPE-reg & FileSystem then start the JPEized app?