Hi, first of all, please forgive me for asking such a stupid question. I am computer illiterate and my English is very poor (not my native language), so please go easy on me. I have been using JPE to portablized software for a while now and I have to say that it is a great software and it works most of the time. However, there are certain things\behavior about JPE that really annoy me and one of them is the impossibility of it to exclude cmd\bat files. Here is my case: I usually use JPE to build portable packages( or portable suits, i.e. couple of software under one sandbox) and normally I find that it is desirable to include a file manager in those packages. Problems arise when I try to run a cmd\bat under JauntePE-ized file manager; JPE immediately give me an error saying that I am trying to run a non-Win32 applications and it is not supported. What amazed me is that, AFAIK, cmd should be a Win32 application and therefore it should be supported. What puzzled me even more, is that I can actually run those cmd files under JPE if I make a cmdportable launcher and pass those cmd files as a parameter to the launcher. But of course, I am computer illiterate and so I may be seriously wrong here. Anyway, as usual, I thought it should be a piece of cake and I should be able to remedy this problem by editing the ini file. First, I tried to exclude the cmd.exe as a child process (under [ChildExclude], 1=cmd.exe), no go; same error pop up immediately. OK, fine, no big deal; I can do it in another way. So I tried to exclude everythings (under [ChildExclude], 1=*) and ONLY include those applications that I want to run as child process (under [ChildInclude], 1=blah, 2= blah blah, etc...). Theoretically, this should give me what I wanted because JPE should only monitor those processes under [ChildInclude] and should let other process pass through without doing anything. Unfortunately, still no go and the same error still pop up.
OK, TBO, I admit that I haven't finished reading the whole documentation and most of what I have read I don't pretend to understand. Can any experts here help me out on this issue? Did I do anything wrong? I'm currently running the old jauntePE.dll 0.5.x\0.3 under XP SP2. Any help or advice will be greatly appreciated. TIA.
PS. It is weird that most software that I have tried work right out of the box under JPE (kind of, with some tweaking), but this little cmd problem has bugged me for several months. But a portable file manager is USELESS, if it can not run a cmd\bat file, imho.
Is it possible to exclude CMD\BAT file?
-
ComputerIdiot
- Posts: 5
- Joined: Mon Jan 24, 2011 10:11 pm
a question
Are you trying to exclude windows applications (programs)?
Or are you trying to exclude BAT and or CMD files?
Have you tried launching the BAT or CMD files during setup?
If not this (launching the files during setup) might let you better find how to exclude them if you really want to.
(this could make it a matter of editing the ini file)
*********edit below**************
@dmg yes your point is what I was asking about. (I agree)
I asked about files and programs, though I did not provide statements as you did, I just asked leading questions.
Or are you trying to exclude BAT and or CMD files?
Have you tried launching the BAT or CMD files during setup?
If not this (launching the files during setup) might let you better find how to exclude them if you really want to.
(this could make it a matter of editing the ini file)
*********edit below**************
@dmg yes your point is what I was asking about. (I agree)
I asked about files and programs, though I did not provide statements as you did, I just asked leading questions.
Last edited by donald on Wed Mar 30, 2011 8:11 pm, edited 2 times in total.
Re: Is it possible to exclude CMD\BAT file?
Since I have never used JPE I probably have no idea what I am talking about, but aren't CMD and BAT files simply instructions passed to a command interpreter (in Win XP it is WINDOWS\system32\cmd.exe). Logically, does this mean you should set things to allow access to the interpreter from inside your portable environment?
-
ComputerIdiot
- Posts: 5
- Joined: Mon Jan 24, 2011 10:11 pm
Re: Is it possible to exclude CMD\BAT file?
Many thanks to donald and dmg for your replies and I am very sorry that my original question has caused so much confusion. I forgot to type "files" after cmd\bat; so yes, what I meant was to exclude cmd\bat "FILES". This proves once again that my English is worse than I thought, lol.
Though what I meant was to exclude CMD\BAT files in JPE, the difference between excluding a particular application or a particular filetype, at least in this case, isn't that important in JPE, AFAIK. Since the target of JPE (well, more precisely, the jauntePE.dll) has to be a Win32 application (i.e., exe); So, to exclude JPE to run a particular filetype , basically means to exclude JPE to run a particular application, which is responsible to open that particular filetype (I may be seriously wrong here). In fact, if you try to launch a CMD\BAT file or any other file under JPE directly, you'll have to specify the target application(exe) in the launcher's ini file first, and then pass the file as a parameters to the launcher to launch that file. OTOH, in a portable file manager, you can simply launch a file by double clicking the file, because I think the file manager has automatically done that for you.
You statements above are absolutely right. Normally, you absolutely want to run everything INSIDE your portable environment. Unfortunately, my situation here is a little bit different. I am computer illiterate and also an idiot, so you should take my word with a grain of salt. However, I have been a long time Sandboxie user (well, about 3 years now), so I'm not totally new to this application virtualization stuff (actually I learn all my stuff through Sandboxie). AFAIK, JPE\Sandboxie, as well as other similar application virtualization software, work their magic by injecting their dll (eg. jauntePE.dll) into the target application's executable file (exe). After the injection, any requests made by the target process (exe), either file system requests or registry base requests, will be redirected to the designated sandbox instead of the "real" system. The ONLY difference between JPE and Sandboxie is that, according to tzuk (author of Sandboxie), Sandboxie won't allow any process, which has been started by Sandboxie, to start\invoke another process (a child process) outside of the sandbox. In other words, once the process has been sandboxed, any future action by the process will also be sandboxed, that is, everything will be trapped in the sandbox which the original process has been started. The reason behind this, I guess, is that Sandboxie is a security software, and therefore it's main goal is to make sure everything started in the sandbox STAYS inside the sandbox. JPE, OTOH, isn't a security software, so it offers some options (through [ChildInclude] and [ChildExclude] section in the ini) to instruct JPE program whether to inject or not to inject the jauntePE.dll to the child process. And from my experience, those settings do work as expected.
My problem here isn't that I don't want to run the CMD\BAT file inside the portable environment. On the contrary, I do. However, for some strange reasons beyond my comprehension, I can't. Whenever I double click on a CMD\BAT file inside the portable file manager, it gives me an error immediately. OTOH, as I have stated in my first post, I can run the same script file by making a cmdportable launcher and pass the file as a parameter to the launcher. I can even invoke a command interpreter inside the portable file manager without any problem (Double Commander\FreeCommander). So obviously, it isn't the case that JPE can't run a CMD\BAT file; it surely can, but it refuse to run the file (if the file is invoked by double clicking it inside the file manager). It stated that this is not a Win32 application and it is not supported. It isn't unusual for a application virtualization software to refuse to run certain programs, as there are some programs that even Sandboxie can't run (tzuk said those executable files cannot be injected without some serious tweaking of how Sandboxie inject its dll, and he won't bother with them). But in this case, the command interpreter (cmd.exe) runs fine in JPE, and I have no idea why I got that error, and AFAIK, cmd.exe IS a Win32 application to begin with. Since I have no idea what caused the problem, nor do I have any skill to solve any computer problem; So I try to remedy this situation by instructing JPE not to inject its dll into the cmd.exe at all, as an alternate method. ( Actually, the ability of JPE not to inject its dll (unlike Sandboxie) does come in handy in some situations). However, even that doesn't work. So, now I have two questions\problems. The first one is why JPE can't start a CMD\BAT file in a JauntePE-ized file manager even though cmd.exe IS a Win32 application? The second question is, in what order does the JPE program handle its Exclusion? If JPE evaluate its child process Exclusion list first, before whether the process in question is a valid Win32 application, then I shouldn't have the problem that I'm having now. OTOH, if JPE has to evaluate whether the process is a valid Win32 application first, even though it was told not to run under JPE, then it is going to be a problem for portable file manager or portable program launcher. Again, I might be seriously wrong here.
PS. I really have no ideas of what I'm talking about, and I'm very sorry if any (may be all) of my above statements are wrong.
@donald:donald wrote:Are you trying to exclude windows applications (programs)?
Or are you trying to exclude BAT and or CMD files?
Have you tried launching the BAT or CMD files during setup?
Though what I meant was to exclude CMD\BAT files in JPE, the difference between excluding a particular application or a particular filetype, at least in this case, isn't that important in JPE, AFAIK. Since the target of JPE (well, more precisely, the jauntePE.dll) has to be a Win32 application (i.e., exe); So, to exclude JPE to run a particular filetype , basically means to exclude JPE to run a particular application, which is responsible to open that particular filetype (I may be seriously wrong here). In fact, if you try to launch a CMD\BAT file or any other file under JPE directly, you'll have to specify the target application(exe) in the launcher's ini file first, and then pass the file as a parameters to the launcher to launch that file. OTOH, in a portable file manager, you can simply launch a file by double clicking the file, because I think the file manager has automatically done that for you.
@dmg:dmg wrote:
, but aren't CMD and BAT files simply instructions passed to a command interpreter (in Win XP it is WINDOWS\system32\cmd.exe). Logically, does this mean you should set things to allow access to the interpreter from inside your portable environment?
You statements above are absolutely right. Normally, you absolutely want to run everything INSIDE your portable environment. Unfortunately, my situation here is a little bit different. I am computer illiterate and also an idiot, so you should take my word with a grain of salt. However, I have been a long time Sandboxie user (well, about 3 years now), so I'm not totally new to this application virtualization stuff (actually I learn all my stuff through Sandboxie). AFAIK, JPE\Sandboxie, as well as other similar application virtualization software, work their magic by injecting their dll (eg. jauntePE.dll) into the target application's executable file (exe). After the injection, any requests made by the target process (exe), either file system requests or registry base requests, will be redirected to the designated sandbox instead of the "real" system. The ONLY difference between JPE and Sandboxie is that, according to tzuk (author of Sandboxie), Sandboxie won't allow any process, which has been started by Sandboxie, to start\invoke another process (a child process) outside of the sandbox. In other words, once the process has been sandboxed, any future action by the process will also be sandboxed, that is, everything will be trapped in the sandbox which the original process has been started. The reason behind this, I guess, is that Sandboxie is a security software, and therefore it's main goal is to make sure everything started in the sandbox STAYS inside the sandbox. JPE, OTOH, isn't a security software, so it offers some options (through [ChildInclude] and [ChildExclude] section in the ini) to instruct JPE program whether to inject or not to inject the jauntePE.dll to the child process. And from my experience, those settings do work as expected.
My problem here isn't that I don't want to run the CMD\BAT file inside the portable environment. On the contrary, I do. However, for some strange reasons beyond my comprehension, I can't. Whenever I double click on a CMD\BAT file inside the portable file manager, it gives me an error immediately. OTOH, as I have stated in my first post, I can run the same script file by making a cmdportable launcher and pass the file as a parameter to the launcher. I can even invoke a command interpreter inside the portable file manager without any problem (Double Commander\FreeCommander). So obviously, it isn't the case that JPE can't run a CMD\BAT file; it surely can, but it refuse to run the file (if the file is invoked by double clicking it inside the file manager). It stated that this is not a Win32 application and it is not supported. It isn't unusual for a application virtualization software to refuse to run certain programs, as there are some programs that even Sandboxie can't run (tzuk said those executable files cannot be injected without some serious tweaking of how Sandboxie inject its dll, and he won't bother with them). But in this case, the command interpreter (cmd.exe) runs fine in JPE, and I have no idea why I got that error, and AFAIK, cmd.exe IS a Win32 application to begin with. Since I have no idea what caused the problem, nor do I have any skill to solve any computer problem; So I try to remedy this situation by instructing JPE not to inject its dll into the cmd.exe at all, as an alternate method. ( Actually, the ability of JPE not to inject its dll (unlike Sandboxie) does come in handy in some situations). However, even that doesn't work. So, now I have two questions\problems. The first one is why JPE can't start a CMD\BAT file in a JauntePE-ized file manager even though cmd.exe IS a Win32 application? The second question is, in what order does the JPE program handle its Exclusion? If JPE evaluate its child process Exclusion list first, before whether the process in question is a valid Win32 application, then I shouldn't have the problem that I'm having now. OTOH, if JPE has to evaluate whether the process is a valid Win32 application first, even though it was told not to run under JPE, then it is going to be a problem for portable file manager or portable program launcher. Again, I might be seriously wrong here.
PS. I really have no ideas of what I'm talking about, and I'm very sorry if any (may be all) of my above statements are wrong.
Re: Is it possible to exclude CMD\BAT file?
At this moment there is no setting to exclude file types from redirection. But you did the right thing to exclude cmd.exe as a way excluding the *.bat file type from being launch in redirection. That is current solution available for now.
I think more info is required to solve this puzzle. IMO, it will be useful for the JPE developer to know where the Error Message is come from. The error could come from the application (file manager), or Windows, or from JPE. Test the same action that produce the error (if it is double-click *.bat file) on other JauntePE-ized file managers. It might help you identifying further who owns the Error Message. The snapshot of the Error Message can also be very big information to the developer.
Can you give further details the file manager that causing this problem? Can you also give the example of the *.bat file that you used, plus the JPE config settings.
I think more info is required to solve this puzzle. IMO, it will be useful for the JPE developer to know where the Error Message is come from. The error could come from the application (file manager), or Windows, or from JPE. Test the same action that produce the error (if it is double-click *.bat file) on other JauntePE-ized file managers. It might help you identifying further who owns the Error Message. The snapshot of the Error Message can also be very big information to the developer.
Can you give further details the file manager that causing this problem? Can you also give the example of the *.bat file that you used, plus the JPE config settings.
-
ComputerIdiot
- Posts: 5
- Joined: Mon Jan 24, 2011 10:11 pm
Re: Is it possible to exclude CMD\BAT file?
@crownixxThe error could come from the application (file manager), or Windows, or from JPE.
First of all, thanks for your reply.
In regard with your statement above, I have thought about that too. I don't know how to correctly identify which process actually own the error windows\messages. But here are some snapshots of the Error messages, and imho, those pictures do give some important clues.
From JauntePE-ized Explorer (Two Error messages):
From JauntePE-ized FreeCommanderPortable (Same Two Error messages):
I have the same problem with other JauntePE-ized file manager that I have tried, eg. DoubleCommander, tabbyfile, etc...; So I'm pretty sure that this problem isn't an isolated case with just one or two file managers.
Below are some pictures showing that this problem ONLY appears on command line interpreter (cmd.exe, AFAIK), but not with other Windows applications.
Here under [ChildExclude], I have excluded two processes, Notepad.exe and cmd.exe. Notepad opened normally without being redirected (there are no JPE icons on the title bar), but cmd.exe did not.
Here under [ChildExclude], I have excluded everything (1=*). This should instruct JPE not to redirect any child process but apparently it did.
OTOH, if I disable redirecting child processes by setting RedirMisc to 0 (RedirMisc=0), cmd.exe bypass JPE as expected.
In theory, the last two cases above should give identical results. If I exclude every child process under [ChildExclude] ([ChildExclude] 1=*) and have no process under [ChildInclude]; then this should be identical to setting RedirMisc to 0. But my results above said otherwise.
Even though I can make cmd.exe to bypass JPE by setting RedirMisc to 0, this also disable child process redirection altogether and therefore is not what I wanted.
Below are some simple instructions to reproduce my problem:
1. Get the generic JPE launcher (it is much quicker and easier this way) and follow the instructions in this post. (joby_toss is a genius) http://www.portablefreeware.com/forums/ ... 7fe308ed57
2. Use any portable file manager (FreeCommanderPortable, tabbyfile, etc...). Since they are already portable, this should rule out the possibility that they aren't set up correctly under JPE.
3. Create a cmd file. Just type some simple instructions and save it. (eg. just type pause and save it, this should open a command prompt)
4. Run the launcher and then run the cmd file you have just saved earlier. That's it.
I don't think my other settings in the ini file matters much, because we are running a portable file manager here. Since those portable file manager, in theory, should work right out of the box, without any need of JPE (they read their settings in their own ini files and recreate them if needed). Therefore I am not going to post my detailed config settings here.
PS. If you looked at the pictures I have posted above, you'll noticed that I have been running the file manager under Sandboxie (because I normally run everything under Sandboxie, lol). But I can assure you that this problem also appears if I run the launcher without Sandboxie.
This problem may only appears on my computer (because I'm an idiot
). So, in any case, you've already do me a great favor, if you can take some time and see if you can reproduce my problem on your computer. THIS IS A VERY MINOR ISSUE, and that's why I didn't post my questions for months (well, that and also because my English is very poor). I don't want to bother the developer, if Redllar doesn't has time, because I'm also waiting for version 0.6 to be ready. Version 0.5x is nice, but a fully working open source 0.6 is much better. 
Re: Is it possible to exclude CMD\BAT file?
Well done. You're very good in the analysis and testing to the problem. By run test with several file managers, you were able to remove one possibility the error message was from the application itself. From the snapshot, obviously one message was coming from the JauntePE. Goggling "The request is not supported." came out with result the another error message was coming from the Windows.
Then, I did a quick goggling on the "*.bat file association" and found out the path association was to the "%1" %*. It is odd for me because AFAIK the association path is normally to the exe file, eg; for *.txt default path at HKCR\txtfile\shell\open\command regkey is c:\windows\notepad.exe %1".
I also able to produce the problem using my Jaunte-ized 7zip File Manager. I think you have found something. As a user too, i don't have any clue or workaround left and this is the far i can go to help you out. Maybe now is the time to ask help from redllar. It will be great to have another new member in our new jauntePE forum. Can you post your finding in the Bugs Section? Anyway, this is really good finding..
Then, I did a quick goggling on the "*.bat file association" and found out the path association was to the "%1" %*. It is odd for me because AFAIK the association path is normally to the exe file, eg; for *.txt default path at HKCR\txtfile\shell\open\command regkey is c:\windows\notepad.exe %1".
I also able to produce the problem using my Jaunte-ized 7zip File Manager. I think you have found something. As a user too, i don't have any clue or workaround left and this is the far i can go to help you out. Maybe now is the time to ask help from redllar. It will be great to have another new member in our new jauntePE forum. Can you post your finding in the Bugs Section? Anyway, this is really good finding..