mystery excel.exe

[keithg1964]

Just for the hell of it, I typed excel(or excel.exe) at the command line and excel started up.
FYI winword.exe does not start.

which /a excel.exe shows:
excel.exe is an external : C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE

Looked at the path and saw nothing that would result in this.
unalias *
Still starts.

Unset path
will not start.
get normal path and Start trimming path and get to last entry that points to an java directory.
Delete the last item in path, and it will not start.
Add that item back to path and it will start.
Edit that path to an invalid path and it starts.

Now It get strange now;
unset path.
will not start.
do an Path 1 ( and invalid path)
and excel starts.
unset *
excel will not start
add any path valid or not,
and excel trys to start, but I get an box saying error unable to start.

summary, no path and excel.exe will not start from command line.
have any path (invalid or valid) and excel.exe will start from command line.



PS I have NOT been drinking....
Excel will NOT start from CMD.EXE.

 

[vefatica]

TCC checks the registry key mentioned below; I don't think CMD does that. I have entries for both excel and winword, and I can start either from the TCC command line.

v:\> regfind "app paths" | egrep -i "winword|excel"
-> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe
-> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe

When I "unset path", neither works. That's a bit odd. It could be TCC's fault ... not checking the registry's "App Paths" when there's no path. I'll mention this thread in a brief message in the support forum.

 

[w_krieger]

It probably isn't TCC that is doing this, and my own experience with AppPath might be enlightening.

AppPath is supposed to make some application that is off-path, to appear to be in the path. Usually, the entry corresponds to the program, such as 'winword.exe' will load 'winword.exe'. Not all programs use AppPath, and you can partly bypass this by using copies of Write, which loads 'wordpad.exe'.
CMD.EXE for example, does not support it, and nor does launching applications from something like File Commander / W (my 'norton commander' clone). So i keep a handy zoo of write.exe modified to launch all sorts of things. The usual way is say, 'TCC.EXE'(write), uses tccu.exe(app path), which loads tcc.exe (jpsoft thing), and updating 'apppath' with the version.

If you want to have a real exe that loads winword, you copy write.exe to 'word.exe', and replace the string 'wordpad.exe' with 'winword.exe'. Typing word will then load winword.exe. If you rename this 'word.exe' to 'winword.exe', starting it up will launch a storm of instances of the small version, because AppPath finds the executable first. You can simply rename winword.exe back to word.exe to quell the storm.

My suspicion here is that the call made is a path like .;%path%;%apppath%. There should be an entry for the image hijack directory there, but i have not gone fishing for that yet. I suspect the call aborts if %path% is not found, leading no path to apppath. However, looking at WRITE.EXE might give some insight here.

[D:\newin\exe]ren tc.exe tc1.exe
D:\newin\exe\tc.exe -> D:\newin\exe\tc1.exe
  1 file renamed

[D:\newin\exe]tc
TCC: (Sys) D:\NEWDOS\exe\tc.exe is not a valid Win32 application.

[D:\newin\exe]cd ..

[D:\newin]tc
TCC: (Sys) D:\NEWDOS\exe\tc.exe is not a valid Win32 application.
:: This is a bound DOS/OS2 app 'tcopy', win7 is balking at the OS/2 chunck.
:: The path includes ...;D:\newin\Exe;D:\NEWDOS\exe;...  

[D:\newin]cd -

[D:\newin\exe]ren tc1.exe tc.exe
D:\newin\exe\tc1.exe -> D:\newin\exe\tc.exe
  1 file renamed

[D:\newin\exe]cd ..

[D:\newin]tc
rem (TC starts jpsoftware tc.exe through Apppath tcu.exe)
[D:\newin]

This means that it searches the path before it looks at AppPath, and if there is no path, then AppPath will not be seen either.