Can someone show me how to use JPE?

[Local]

Slowlearner I hope you don't mind me hijacking your thread for this question.

I'm in pretty much the same boat as you in wanting to learn to code.
I'm starting very basically i C++ because people seem to have high regard for it and I read that it is a good way to make independent applications (Eventually).

All I want to do is make a couple of simple portable applications that I've not seen out there yet and I just enjoy learning things.

Am I going about this the right way or is there a better idea for a true begginer like me?

Until now all I ever learned was hardware so software is completely new to me.

[SlowLearner]

Hi

No - I don't mind at all

I'm sure the posts you get will help us both along the path

[redllar]

I now see why people spend so much time on this, I've only been shown a little and I'm keen to start changing all the settings to see what happens (don't worry - I won't do anything that looks dangerous).

Just fyi. File system redirection is very, very expensive right now. I'm working on an option to keep parts of the file system in-memory to help speed things up. But for now, if you find out you don't need it, don't use it. Also, do whatever you can to exclude as many of those special directories as you can. Hopefully one of these days I'll have a doc that explains all you can do to help speed things up once you find that redirecting everything works but is too slow.

So, are you ready for something new to try out? I thought you might want to take a look at how to use the modules lists.

As far as a language goes - I don't want a change of career, I just want to learn for fun, and to make my computer do something (I'm always aware that it could do useful stuff, but because I don't know how - I end up not doing it).

My background is more towards the physics/mathematics end - but I don't want to learn some theoretical principles that I could never use.

Oh crap. Sorry about that. That's what I get for assuming.

If you're just interested in coding in general, C is a very basic language as well. But it has a very unusual syntax that puts off a lot of people. Most people suggest C++ as well since it's a natural extension of C into object oriented programming. But parts of C++ can be daunting, so beware. Many people new to coding have a hard time with it.

You might also take a look at some Delphi code. It uses a version of Pascal called Object Pascal. But like C++, you don't have to use the object oriented coding features if you don't want to. Pascal was the answer to many people's problem with BASIC, so you might find it a good fit for you. I think Delphi is for Windows only though. But I believe you can get older versions of it for free now. And it's a really nice complete package to develop from.

There's tons more to choose from of course. In the end it really does depend on what you want to code up.

All I want to do is make a couple of simple portable applications that I've not seen out there yet and I just enjoy learning things.

Am I going about this the right way or is there a better idea for a true begginer like me?

Besides the above, many people use a scripting language to do simple things. That's what they're made for. crownixx's build wizard for JPE is a good example. It really does depend on exactly what you want to accomplish. Do you want a gui? Extensive financial calculations? You want to be able to make little tweaks and re-run quickly? Writing a game? Lots of file info to deal with?

[Firewrath]

Have you actually compiled and linked and debugged via a portablized Dev-C++ and made sure no reg entries or file system mods are not getting portablized?

well,
i did compile my old rng and all, which worked, minus the desktop redirection, but yeah, figured that would happen,

i changed it slightly to know i edited it, and it saved it in a redirected desktop folder, but opened the main desktop folder when i told it to 'compile and run'

but it did save everything all right and all,

But, wierd thing, when i tryed to cache the header files,
even with the JPE'd DevCpp in my C drive,
it keep caching old xwDevCpp headers instead of the 'C:\DevCpp' ones,
but after taking the ones i already had done and replacing the file it was ok,

and i honestly cant check if JPE missed anything in the linking, i have the portable DevCpp on all my computers already, and i dont think its all that 'stealthy',
But, i did regshot beforeDevCpp startup and after my compiling test,
i didnt get an changes other then the basic windows stuff,
so i think its ok,
but like i said, i cant be 100% sure,

[crownixx]

I had only ever tried it using the crownixx auto-wizard (because I know it makes the ini and registry files - that scare me a bit).

After reading this, i make a test for the AutoWizard with JauntePE 0.1.3.. suspect that mybe my AutoWizard did wrong in sending the commandline switches to the jauntePE, i make portable launcher (using 0.1.3) using SendTo method as redllar teach me before. I only use "-b" switches.. to control the registry or Filesystem redirection, i use Application-specific inis.

Then, the result came out like this
- redirect registry, switch off Filesystem redirection..Application is JPE'd
-i redirect registry, when i switch on the Filesystem redirection, JauntePE unable to hook the application
- suspect again that mybe 0.1.3 having problem creating the portable launcher, i run the application using JauntePE launchpad. i get the same result as above

i restart my OS,then did a test it still the same.Is this a bug for 0.1.3? here's the video for my testing.its only 994kb
http://mihd.net/5vzcsh

However, I used the "build portable" you suggested...and it worked.
It has a cool red box around it and everything - this is great!!!

need a confirmation from SlowLearner here, i guess you using redirect registry & do not redirect Filesystem right?

i also get 0.1.3 from the thibeaz link before it removed in the topic. i guess i'm using the same version as SlowLearner

[SlowLearner]

Hi

Thank you for the programming advice - I think this is the problem that holds many people like me back...there are so many to choose from, and if you don't have a clear idea of what you want, you just end up unable to decide.
It would be nice if someone could write a new language, that had various levels of difficulty and did everything

need a confirmation from SlowLearner here, i guess you using redirect registry & do not redirect Filesystem right?

I click build - then locate the exe
Click next and next (for the parent folders) = no changes
Registry - redirect to portable = TICK KEEP IN MEMORY (I don't know why, but I think I read it somewhere on the forum)
File - redirect to portable = no changes
Icon - use application = no changes
Application storage - require to be present = no changes
Portable registry - require to be present = no changes
Finish

Also, while I'm here. I have been playing around with JPE, and have a few "new user questions" which I would be grateful if someone could answer.

1) redllar showed me that some folders can be included in / exluded from the portable (although really we should try to exclude all, as this works faster)
What about C: drive - everytime I save there it always excludes it from the portable, is there a way to include it?

2) Why not always exlcude them all - then when using the application, I just save into a folder that I store next to the portable, so they are together anyway?

3) Before "building a portable" is it better to:
3a - install, then copy the program files
3b - add the app to the launcher, launch it, then use these files

My guess is 3b - as this would also include files that aren't placed in the program files folder- but then do I add them all, and if so, does it matter if they are in folders?

4) Some things don't need the ini file - if they do, I can copy JauntePE_jauntePE,ini into the application folder, and alter this. So why rename the ini if we don't need to?

Sorry if some of these questions are a bit basic.

So, are you ready for something new to try out? I thought you might want to take a look at how to use the modules lists.

Yes please - where do I find out about these?

Thank you

[redllar]

Lots of good questions. I'll do this one first as it's the easiest and I'm a bit short on time.

4) Some things don't need the ini file - if they do, I can copy JauntePE_jauntePE,ini into the application folder, and alter this. So why rename the ini if we don't need to?

For flexibility. What if you wanted to run all apps in a directory the same way, but one needed a slightly different config? You create a jpe-jpe ini for all of the "normal" ones and then an app-specific jpe ini for the special one.

Chris actually had a case like this with ObjectDock, so I'll use it as an example. You have OD and you've gone to the trouble of getting it working via JPE. You created an app specific jpe ini for OD to keep it out of the registry and get its file system mods into the app directory.

But you're using OD to launch many of the fine apps found on this site. Apps that are already portable in and of themselves. What do you do? You don't want to use the OD jpe ini for those apps as that will needlessly slow them down. So to be safe you create a jpe-jpe ini that turns off all redirection and you put that in the OD directory as well. So now those OD-launched apps won't be bothered by any of the jpe runtime's overhead caused by the api-hooking and redirection taking place for OD.

It actually can get quite a bit more complicated than this simple example. But that's the reason it was done. To allow for as many configurations as reasonably possible.

[redllar]

but like i said, i cant be 100% sure

Okay. I may give it a go here then since I'm still clean re: Dev-C++. I'll see if I can duplicate your bit about the caching as well and see what pops up in the log.

[redllar]

1) redllar showed me that some folders can be included in / exluded from the portable (although really we should try to exclude all, as this works faster)
What about C: drive - everytime I save there it always excludes it from the portable, is there a way to include it?

Yes, but DON'T. Why? Because doing so will redirect not only c:\ mods but all other c: drive mods as well. The paths you put in the exclude, include, and ignore lists each indicate not only that directory but all of its subdirectories. The same goes for the registry keys specified in the registry exclude, include, and ignore lists.

So, if you do this you'll end up redirecting ALL c: drive file system mods made from within the app, not just the mods made in c:\. So you would get any mods that the system dlls may be making. And if you also happened to be running your JPEized app from c:, I have no idea what would happen. It may loop back on itself and never end.

But this is an interesting idea. I can think of several reasons why you'd want to have a path specifier indicate only that directory and not its subdirectories. Conversely, it might be nice to have the ability to specify that only a certain directory's subdirectories be added to the list but not itself.

So don't do it. Instead, create a subdirectory of c:\ and store your stuff there. You can then safely add that path to the include list. Something like 4=C:\Projects if you get my meaning.

[SlowLearner]

Something like 4=C:\Projects if you get my meaning.

Does this mean that the number (e.g. 4) doesn't mean anything, becasue in the ini file it says 4=Files\Computer\Printers?

Also with my previous question:

3) Before "building a portable" is it better to:
3a - install, then copy the program files
3b - add the app to the launcher, launch it, then use these files

My guess is 3b - as this would also include files that aren't placed in the program files folder- but then do I add them all, and if so, does it matter if they are in folders?

I tested it using Dev CPP, and the 3b method (installing using launcher) does not include the same files as the 3a method (normal install)...I'm not sure that the 3b method realy includes anything other than shortcuts and a reg file (but I could easily be wrong).

If I'm starting to bug you guys with too many quesitons, just say and I'll leave you alone for a while

Thank you

[redllar]

2) Why not always exlcude them all - then when using the application, I just save into a folder that I store next to the portable, so they are together anyway?

If you're sure you've used the app to its fullest, then the next logical step would be to go take a look at the contents of the file system redirection folders and see what's in there. If there's nothing in there then you should be able to safely turn off file system redirection and not even deal with exclusion and inclusion. Just change the [Filesystem]Use=1 setting to [Filesystem]Use=0. You can also safely turn it off if the only files that have been redirected have been due to you saving them to non-portable locations. In other words, the redirected folders only contain your own personal files, not any from the app.

The one reason I can think of right now when you might not want to turn off all file system redirection, even when you can do so safely as far as how the app uses the file system is concerned, has to do with portable paths.

Example: You're running a non-portable app at home and save a file to "F:\mydoc.doc". The app adds that full path to its "most recently used" (MRU) list. But "F:" happens to be a portable drive. You go to work, plug in your portable drive, start the app, and the MRU entry for your doc won't work because that Windows computer is saying the drive is now "P:" instead of "F:".

Now let's say that you JPEize the app and have file system redirection turned on for "My Documents" only. If you always run the app via JPE and you always save everything to "My Documents" the problem mentioned above goes away. Because the JPEized app's "My Documents" will always point back to the redirected folder no matter what the drive letter is. Theoretically this will work even on Windows setups that have completely different paths for the "My Documents" folder, such as having Windows installed on a drive other than C:, other with a non-english version of Windows.

The downside to this is you won't have access to the real "My Documents", nor to any of its sub-folders, including on XP the other "My whatever" folders. Actually you do in a round-about way but that's for another discussion.

Anyway, for this type of scenario you would keep file system redirection turned on but use [FilesystemExclude]1=* to exclude everything from being redirected and then use [FilesystemInclude]1=5 to include "My Documents" redirection only.

[redllar]

So don't do it. Instead, create a subdirectory of c:\ and store your stuff there. You can then safely add that path to the include list. Something like 4=C:\Projects if you get my meaning.

I just tested this and it doesn't work. I found the bug and fixed it but of course you won't be able to use something like this until that release goes out.

Something like 4=C:\Projects if you get my meaning.

Does this mean that the number (e.g. 4) doesn't mean anything, becasue in the ini file it says 4=Files\Computer\Printers?

In each of the sections of the ini that has a numbered list, the numbers to the LEFT of the equal sign just indicate what entry they are. Entry #1, entry #2, etc. The [SpecialFolders] LEFT hand numbers are only related to the file system exclude, include, and ignore lists, and only to the numbers to the RIGHT of the equal sign.

I can give examples if you need them. Once I get the new gui out this will all go away anyway.

[redllar]

Also with my previous question:

Quote:
3) Before "building a portable" is it better to:
3a - install, then copy the program files
3b - add the app to the launcher, launch it, then use these files

My guess is 3b - as this would also include files that aren't placed in the program files folder- but then do I add them all, and if so, does it matter if they are in folders?


I tested it using Dev CPP, and the 3b method (installing using launcher) does not include the same files as the 3a method (normal install)...I'm not sure that the 3b method realy includes anything other than shortcuts and a reg file (but I could easily be wrong).

This is really mostly a personal preference. I prefer to do as much via JPE as possible, because I know that some app installers create registry and/or file system "stuff" that I don't want on my system at all. And I don't trust uninstallers enough to make sure they root it all out. But you'll find that certain types of installers just don't work within JPE so you may not have a choice anyway. You should always at least run RegShot while installing just so you can double check. Or use Universal Extractor so that you don't even have to install.

With Dev C++ you're not really dealing with an app that mucks around with the registry and file system much. So it might not be the best app to base your opinions off of. Just my opinion though.

My guess is 3b - as this would also include files that aren't placed in the program files folder- but then do I add them all, and if so, does it matter if they are in folders?

I'm not quite sure what you're getting at here. You don't really need the startmenu and other such stuff, unless you plan on doing something really fancy portability-wise like JPE-izing a file manager and set of apps in such a way as to create a completely portable desktop. That's way beyond what anyone here's tried yet with JPE though. Sometimes the installers will try and put dlls and ocxs into the system directory though, so you should at least move those files over to the app directory, or if not possible because there are multiple apps to deal with, leave that directory redirected.

It really all depends on how complicated the "app" is. I JPEized an app once for a guy, the app was called Jahashaka or something like that, and it had a controlling app plus 5 or 6 other auxilary apps that it would make use of. And all of those apps had a number of dlls each that they wanted to use. And they all wanted to go into the system directory since they were being shared. The installer was actually just a controlling app as well. I think it installed the main app plus 3 or 4 additional packages, which were by themselves other installers. A real mess. But I got it to work by running all of it through JPE, installers included.

[Local]

Besides the above, many people use a scripting language to do simple things. That's what they're made for. crownixx's build wizard for JPE is a good example. It really does depend on exactly what you want to accomplish. Do you want a gui? Extensive financial calculations? You want to be able to make little tweaks and re-run quickly? Writing a game? Lots of file info to deal with?

Games, I never really thought of, more starting out just automating annoying processes in windows and some simple gui apps.
I'd have liked to try eventually an fully portable (small) word processing software.

Thanks for the info so far, I think I'm going to still carry on with the C++ for now and maybe try basic when I get the hang of this.
You can never know too much can you?

You should always at least run RegShot while installing just so you can double check. Or use Universal Extractor so that you don't even have to install.

If I have no option but to install a program (Including allll the reflexive games out there, loads of useless files) I always install into sandboxie It's much simpler just to delete everything after you take the files you need.

[redllar]

If I have no option but to install a program (Including allll the reflexive games out there, loads of useless files) I always install into sandboxie It's much simpler just to delete everything after you take the files you need.

Yeah, I keep forgetting about sandboxie because I can't run it here. But it's a great tool, as are the more robust virtual machine apps such as VMware Player. I really miss being able to use these types of tools.