How to virtualize CMD and have it be default CMD on system

[lukebal267]

Hey everyone

Ran into an interesting dilemma today. I'm currently thinapping a program called JDA Arthur Planning & OTB. THe app itself is thinapped fine and it can launch on Win7x64 successfully. It was thinapped on XP SP3 as it can not natively install on Win7x64. However the THinapp can launch from Win7x64 successfully.

However once in the app, when a user clicks on a certain function the app executes a "set" command from the cmd prompt and writes a txt file to a secondary parititon. However the OS doesn't see the virtual package. From within the package (via a43.exe as an entry point) I can recreate this action successfully. I can enter the package via a43, go to system32, open up cmd, type and execute "Set > E:\Planning\UserID.txt".

However when the app tries to do it it is calling on the natively installed CMD, which won't see the virtual directory it's trying to write to inside of the package. It produces this error:

Planning Automation Shell: ERROR "An Error occurred when performing 'Execute command.com /c set > E:\Planning\UserID.txt'. Please check the file and path information.

My question is: how can I get this task virtualized? I know how to create cmd entry points, but I essentially need to virtualize the cmd function and have Windows call on it everytime it needs to reference cmd. I tried capturing cmd by renaming it during the pre/post scans and then applinking it to my existing package. I generated an .msi so that windows would know that the app was present. It continues to use the native cmd.exe though.

Any ideas?

Thanks

[admin]

If I understand correctly, you have an a43.exe as a ThinApp entry point. Then you start a43.exe which launches the native cmd as a child process. And the cmd.exe process cannot see the virtual directory.

Please note that typically, even if you start cmd from natively installed cmd.exe, it is supposed to run virtually and able to see virtual directory. Here the problem could be this cmd is a 64-bit process and cannot run virtually (so it runs natively). Can you try launching the 32-bit cmd from "C:\Windows\SysWOW64\cmd.exe"?

[lukebal267]

Thanks for the response.

I'm only using a43 to troubleshoot. The app itself doesn't need or use a43.exe.

Your response about being able to see the thinapp directories from the native cmd is something I haven't heard before. Are you sure that is correct? If it was an entry point created in the package that would make sense. But the native cmd shouldn't know about the virtual directories any more than the OS does.

Regardless, I have tried launching both 32 and 64 bit version of the native CMD but still cannot see the directories.

The trick will be to either

1) have Windows use a virtualized CMD when it calls CMD from other programs or

2) maybe make a customized entry point that starts from the cmd prompt inside the package and then launch the app from the command line. Then perhaps if the cmd could stay open it would be called for any CMD requests instead of the native OS.

I'm sure there are more possibilities, I'm just grasping at straws here.

[admin]

Typically a process tree (parent, child, etc) should all run virtually, unless there are setttings to run child natively or other cases the child cannot run virtually. This is regardless of where the file of the child process is located (in package or in the system). Since a43 runs virtually, I think its child process, cmd.exe in this case, should also run virtually.

If you run notepad from a43 in the same way, can notepad see the virtual directory? You can also run "dll_dump.exe *" from ThinApp installation directory. It will show all the processes running virtually.

[lukebal267]

I see what you're getting at. In this case, yes a43 runs virtually and can see the directories. Inside of a43 if I launch cmd.exe, I can see the virtual directories.

The problem is the app make calls to the OS for CMD and the OS returns the natively installed CMD under the non-virtual system32 directory. I'd like to replace that somehow so that when the OS calls for CMD it returns my virtual CMD entry point into my package.

[admin]

OK, now I see the problem. So if the app invokes cmd.exe in the same way as a43, then things should work. Perhaps you can use Log Monitor or other tool to figure out how the app invokes cmd?