Your MAIN.EXE needs to load the 32-bit Matlab DLLs LIBMX.DLL and LIBMAT.DLL, the MKL DLLs, the IFort runtime DLLS and MSVC DLLs.
When running from the command line, you should have all these DLLs available in the execution path. If some of them are not accessible, or you have a 64 bit version of Matlab, you will encounter errors.
On my 32-bit Windows XP your program MAIN.EXE ran and gave the output:
Error opening psave.mat
Make sure the LTS setups directory and files do not contain spaces or funny characters,
and is located in the correct directory within the current setups directory.
As far as the "MSVC DLLs" are you just talking about MSVCR90.DLL and MSVCRT.DLL? I guess i have been assuming these dlls are registered on the users' computers. I can see how it would be a problem if they weren't however.
I believe that the problem is with your PATH environment variable.
Dependency Walker reports the first instance of a DLL by searching along %PATH%. If it finds a 64-bit DLL first, that is the one that it reports. This is something that I established by opening two command windows in Win7 X64, one for IFort-32 and another for IFort-64. From each command window, I called Dependency Walker to open a single 32-bit EXE (your MAIN.EXE). The first instance showed only 32-bit DLLs, and the second showed only 64-bit DLLs.
The standard installation of Intel Fortran configures shortcuts to CMD.EXE with the environment variables suited to the target (32-bit or 64-bit). If the batch file that is run to set up one of these sessions has been corrupted, problems of the type that you reported will arise.
Experiences with such problems lead one to reject the software installer's offer to change the environment. I work with several different compilers, and my set up will not tolerate an installer messing up the environment for compilers other than the one it is installing.
When I was involved with the Intel Cluster Ready project, a requirement was that neither Intel's nor anyone else's software installation would make persistent changes in the environment; each Intel tool had to be set up by sourceing the corresponding environment script when required. This requirement had to be satisfied also by 3rd party applications which were certified under ICR. Needless to say, ICR didn't achieve the hoped for market acceptance.